Practice — Tool Design & MCP Integration

A company has built three different AI-powered apps, each needing access to the same five internal systems (CRM, ticketing, inventory, calendar, and billing). Historically, each app team wrote its own bespoke integration code for each system it needed.

A developer is building a custom internal chat assistant. They want it to connect to an existing MCP server that exposes their company's ticketing system.

An MCP server exposes a resource representing the contents of a company's onboarding handbook document, alongside a tool called send_welcome_email.

A team's MCP server exposes a prompt called "draft-incident-report" that pre-fills a structured template with placeholders for severity, affected systems, and timeline.

A reviewer is quizzing a candidate: "An MCP server exposes a tool, a resource, and a prompt. For each, who decides when it gets used?"

A developer defines a tool called update_record with an input schema of a single freeform string field called 'instructions,' intended to cover any kind of record update.

Two tools exist on the same server: search_docs, described only as "searches", and search_knowledge_base, described as "Searches the internal knowledge base for articles matching a query string; returns up to 5 titles and short excerpts, ranked by relevance."

A tool called get_weather sometimes returns a plain sentence like "It's sunny and 72 degrees in Austin today," and other times returns a JSON object with temperature and condition fields, depending on which underlying API responded.

A team is deciding between giving Claude one tool called manage_database that accepts arbitrary SQL statements, versus three narrow tools: get_customer_by_id, get_recent_orders, and update_shipping_address.

A support agent has one tool, run_admin_action, that accepts a string 'action' parameter and can create, modify, or delete any record in the company's systems. During a session, a piece of retrieved document content contains hidden text instructing the model to delete a customer's account.

A team gives their Claude-based assistant access to 60 tools spanning nearly every internal system, reasoning that more tools available means the assistant can handle more requests well.

A team is standing up an MCP server that connects to an internal ticketing API. They're deciding between a static API key baked into the server's configuration and an OAuth-based flow where each user authorizes access to their own ticketing account.

A developer is worried that giving Claude a tool that calls an authenticated internal API means the model itself will need to know or handle the API credentials.

A tool's implementation currently just throws a generic exception with the message "Error" whenever the underlying API call fails, for any reason — invalid input, not found, rate limiting, or an outage.

A submit_expense tool returns a structured error of {isError: true, code: "invalid_input", message: "amount must be a positive number"} when called with a negative amount.

A reviewer is evaluating a proposed MCP integration for a company's internal HR system, meant to let an assistant answer employee questions about PTO balances and submit PTO requests.

A developer says: "We don't need MCP — we can just write direct API integration code inside each of our AI apps for each tool we want."

A proposed tool named file_operation has this input schema: { operation: string, path: string, content?: string }, where 'operation' can be any of "read", "write", "delete", or "list", applied to any path on the server's filesystem.

A host application lets a user attach a specific project's design document to the conversation via a UI button, backed by an MCP resource exposed by that project's MCP server. Separately, the same server exposes a create_task tool.

A logistics company wants Claude, used from both an internal support console and an internal Slack bot, to answer questions using their shipment-tracking system and carrier-rates database, and to submit a shipment reroute request when a delivery is delayed.