Instructor note: the answer key below is hidden from students in the published Canvas quiz.
Your team supports a mid-size logistics company that wants an internal tool: employees type a natural-language question about shipment status ("where is order #48213?") and get back a synthesized answer that may require calling an internal REST API, checking a vector store of policy documents, and possibly summarizing a long PDF manifest. The company already has a container platform and cloud deployment pipeline from earlier coursework, and wants the system exposed as a standard, reusable interface so it isn't locked into one particular agent framework or chat client. Using what you've learned across Weeks 1–7 (REST APIs, containers, cloud deployment, prompt design, tool-calling fundamentals, and MCP), describe:
→ A strong answer: (1) Wrap each capability (shipment lookup, policy search, PDF summarize) as an MCP tool exposed by a single MCP server, so the server is the reusable interface — any MCP client (Claude Desktop, an agent framework, a custom app) can discover and call these tools without custom integration code per client. (2) Containerize the MCP server (Docker image, standard REST/stdio or HTTP transport for MCP), push to a registry, and deploy it on the team's existing container platform (e.g., a managed container service) behind a stable endpoint with health checks and logging, following the deployment practices from earlier weeks. (3) A client-side agent loop would: connect to the MCP server and call its tool-discovery/list endpoint, select the relevant tool(s) based on the user's natural-language request (possibly via an LLM function-calling step), invoke the tool with structured arguments, and pass the tool's result back into the model to produce a final synthesized answer for the employee.
→ b
→ False — the LLM requests a tool call; the application/runtime executes it and returns the result.
→ Predictable, consistent resource paths/verbs and clear, self-describing responses (e.g., consistent status codes and JSON shapes) — accept any reasonable pair such as versioning and idempotency.
→ b
→ True
→ A tool is an action/function the client can invoke (with side effects or computation); a resource is data/content the client can read (context to load), not something you "call" to perform an action.
→ b
→ False — a single client can connect to multiple MCP servers simultaneously, aggregating their tools/resources.
→ Clear description of available tools/when to use them, and explicit constraints/guardrails on behavior (e.g., when to ask for clarification, output format expectations). Accept reasonable equivalents.
→ b
→ True
→ Risk: the agent could take destructive or unintended actions (e.g., deleting/modifying data it shouldn't) due to a misinterpreted instruction or prompt injection. Mitigation: scope the tool's credentials/permissions to the minimum needed (least privilege), or require human confirmation for destructive operations.