Tools and agents quiz

Choose one answer.

• The model has called the weather API over the network and is now waiting for the data to come back to it.
• The model has proposed a tool call by name and arguments; nothing runs until your own application executes it.
• The provider has already run get_weather on its servers, because you listed the function in the tools parameter.

Choose one answer.

• Your application runs both, because a model can never run anything and the provider only relays requests.
• The provider runs both, because both appear in the same tools parameter of the same API request.
• You run get_weather in your own code, while the provider runs web search on its infrastructure for you.

Choose one answer.

• The result did not reference the call it answers, because the call id was either missing or was wrong.
• The result text was shorter than the tool's description, so the model treated it as incomplete.
• The tool schema did not enable strict mode, so the provider refuses results for non-strict tools.

Choose one answer.

• Name: data. Description: "Gets data from our systems." One free-text string parameter called query.
• Name: lookup_order_status. Description: existing orders only, not refunds. Parameter order_id: required string, described.
• Name: lookup_order_status. No description, since the name explains it. Every parameter optional so nothing blocks it.

Choose one answer.

• As a free string, with a sentence in the system prompt asking for only those three values.
• As an enum of the three values in the JSON schema, with a short description of what each value means.
• Leave status out of the schema and map whatever text the model sends to the nearest valid value in code.

Choose one answer.

• Split it into move_item, open_item and sign_item, so each narrow tool gets its own authorization and approval rule in the executor.
• Keep one tool and add a confirmed boolean that the model sets to true once it is sure, with the executor trusting that flag for signing.
• Keep one tool and note in its description that sign needs approval, so the model asks the user before it chooses that action.
• Keep one tool and make action a free string, so the model can describe each request in its own words and the executor parses it.

Choose one answer.

• Remove both, since strict mode guarantees the arguments are valid and the checks become redundant.
• Remove authorization but keep ownership, since strict mode already restricts who is able to call the tool.
• Keep both of them, because strict mode checks the format of arguments and says nothing about who may act.

Choose one answer.

• In the system prompt, with a firm rule such as "never refund orders for other users".
• In the executor, which takes identity from the session and rejects calls aimed at another user.
• In the tool description, by telling the model that user_id must equal the id of the person it is talking to.

Choose one answer.

• A longer timeout, so the first call would always have finished before the retry started.
• Strict mode on the charge_card schema, so a repeated call would have been rejected as a duplicate.
• An idempotency key sent with the call, so the service treats the retry as the same operation.

Choose one answer.

• The model's private reasoning about what to try next, written before it chooses which tool to call.
• The result returned by the tool that the Action step called, fed back in for the next thought.
• The user's follow-up message after the final answer, which is what starts the next cycle of the loop.

Choose one answer.

• Nothing; the provider keeps the whole conversation, so each step only processes the new tokens it adds.
• Tool calls are billed at a flat fee, so total cost depends only on how many tools the agent has.
• Every step is another model call over the growing history, so token cost and latency rise with steps.

Choose one answer.

• The plan carries on with stale assumptions; add checkpoints so the agent can replan on surprises.
• Nothing fails; plan-then-execute re-reads each observation and rewrites the remaining steps by design.
• The agent runs out of context for the remaining steps; moving the plan into long-term memory fixes it.

Choose one answer.

• Reactive ReAct, because it usually needs the fewest model calls of the two designs in practice.
• Reactive ReAct, because the exact sequence of steps it will take is known before it starts running.
• Plan-then-execute, because the plan can be reviewed first; the cost is brittleness when reality deviates.

Choose one answer.

• Loop detection plus a step cap in the loop code, then a partial result or a question to the user.
• A longer system prompt that tells the agent in several different ways not to repeat the same search twice.
• A larger context window, so the agent has room to remember every search it has already tried.

Choose all that apply.

• A step cap and a cost budget enforced in the loop code.
• Letting the model decide when it is finished, with no other limits, since it can see the whole history.
• Escalating to a human when the next action is unclear or irreversible.
• Turning off tracing in production to cut latency, since traces are only useful while debugging.

Choose one answer.

• Raise the step cap so the agent has enough room to reach the last two steps before its budget runs out on a long task.
• Add a long-term memory store, so the agent can look up what it did in earlier runs before it reports a result to anyone.
• Tell the model in the prompt to be thorough and to double-check that every step is complete before it gives its final answer.
• Define done as a checkable condition, such as all five records existing, and verify it in code before accepting a finish.

Choose one answer.

• Latency and cost: vector lookups are too slow for a chat agent and always cost more than they save.
• Privacy of stored personal data, and staleness of remembered facts that later stop being true over time.
• Determinism and licensing: memory makes outputs identical every time, and stored chats become copyrighted.

Choose one answer.

• Short-term memory lives in a vector database for fast lookup; long-term memory is whatever sits in the context window.
• Both are the context window; long-term memory just means a longer window that keeps more of the past.
• Short-term is the current context window; long-term is stored outside the model and retrieved when relevant.

Choose one answer.

• From about 150 integrations to about 25 pieces: ten clients and fifteen servers, each written once.
• It removes the need for integration code, because servers and clients discover each other.
• From 150 integrations to 15, because only the fifteen tools need a server and the apps need nothing new at all.

Choose one answer.

• Nothing; MCP is the newer standard and replaces the model API's tool-calling feature entirely, so nothing is lost.
• Function calling is for local tools and MCP is for remote tools, so a real system needs both.
• They are different layers: the model asks through function calling, and the host reaches tools via MCP.

Choose one answer.

• A tool, because tools are the only primitive a server can offer and a user's pick can trigger one.
• A resource, because resources are listed in the UI for the user to choose between them.
• A prompt, because prompts are user-controlled templates that are often shown as slash commands.

Choose one answer.

• The server talks to the model directly, so approvals and logging belong in the server.
• The host mediates every call, so controls belong there, and the text a server sends is untrusted.
• MCP replaces the model API's tool calling, so the host is not involved once a server is connected.

Choose one answer.

• Use Mcp-Session-Id, because sessions are a permanent part of Streamable HTTP in every revision.
• Keep the cart in server memory and rely on the same instance answering every request from that client.
• Return a cart handle from a tool, accept it as an argument, and check ownership on every single call.

Choose one answer.

• Use it freely; Sampling is the standard, supported way for a server to get a model response today.
• Avoid it for new work: it still works for now, but the suggested path is the provider's API.
• It was already removed in this revision, so any server that uses it fails on connection.

Choose one answer.

• A harmless comment; models only follow instructions in the system prompt, so no action is needed at all.
• A transport error; moving the server from stdio to Streamable HTTP keeps the text out of context.
• Injection via a description: treat it as untrusted, show inputs, require approval, sandbox the server.

Choose one answer.

• It is the recommended design, because it avoids issuing and storing extra tokens downstream.
• It breaks audience boundaries, hides who did what, and bypasses controls tied to its audience.
• It only matters for stdio servers, because HTTP servers cannot receive tokens from clients at all.

Choose one answer.

• Treat each server as its own trust decision: pin its version, allow-list it, give it narrow credentials and require approval for writes.
• Rely on the standard shape, since a server that speaks MCP correctly has already met the security requirements the spec sets for hosts.
• Add one system-prompt line telling the model to ignore odd instructions from servers, then enable all thirty at once to save time.
• Install them for local use only, since a local server runs sandboxed and cannot change its tool list after it has been approved.