MCP tools and tool discovery

Overview

• A tool is a named executable capability with argument metadata and a schema.
• Discovery lets a client obtain the server's available tool descriptions.
• A tool description helps the model choose a capability; it is not proof that the server or tool is trustworthy.

Why this matters

The host can discover integrations without hardcoding a prompt for every operation.

An everyday example

A service desk publishes a menu of tasks with required forms.

A technical example

Discover customer_lookup, order_lookup, ticket_create, and knowledge_search, then expose only authorized ones to the model.

How it works

1. Client discovers tools
2. Host filters trusted/allowed capabilities
3. Model selects name/arguments
4. Client invokes
5. Server checks schema and policy
6. Result returns.

Architecture and flow

Discover → trust/permission filter → model selection → server validation → tool result.

The insurance assistant example

A customer assistant sees read-only claim tools and draft creation; a staff assistant may have additional approved capabilities.

When to use it

Reusable capability catalogs and multi-host tool integration.

When to avoid it

Do not expose every tool from an arbitrary server or trust “read-only” annotations from an untrusted provider.

Interview answer

“Discovery gives tool contracts, not permission. I trust and scope servers, validate calls, and enforce authorization on the server.”

Benefits, trade-offs, and production considerations

• Pin/review tool definitions and detect unexpected changes.
• Schema size affects model context and cost.
• A server can return business errors without a network failure; preserve that distinction.
• MCP tools specification.