Tool Provider

The Tool Provider formally declares the tools it exposes to MCP clients. Each Tool Definition must include:

• A unique name for the tool.
• A clear description of its purpose for the LLM.
• A JSON Schema object that strictly defines the structure, data types, and validation rules for all required and optional input parameters.

This schema is published during the initial capability negotiation handshake, allowing the client to understand how to construct valid invocation requests.

When an MCP client sends a Tool Invocation request, the Tool Provider's core duty is to execute the corresponding Tool Handler function. This involves:

• Receiving and parsing the JSON-RPC request.
• Performing schema validation on the provided input arguments against the published definition.
• Running the handler's business logic, which typically involves calling an external API, executing a database query, or running a local script.
• Managing the execution lifecycle, including timeouts and resource limits.

Tool Providers are responsible for the secure management of credentials required to interact with backend services. This is a critical security boundary, ensuring AI agents never handle raw secrets. Responsibilities include:

• Integrating with secure secret stores (e.g., HashiCorp Vault, AWS Secrets Manager).
• Managing OAuth token refresh flows or API key rotation.
• Applying the principle of least privilege, where the tool's execution identity has only the permissions necessary for its specific function.

After execution, the Tool Provider must format and return the result or error to the client. This requires:

• Serializing the handler's output (often an object or list) into a JSON-serializable format.
• For successful execution, returning a structured result within a JSON-RPC response.
• For failures, providing clear, actionable error messages and codes (e.g., INVALID_ARGUMENT, RESOURCE_NOT_FOUND, PERMISSION_DENIED).
• Ensuring errors do not leak sensitive internal system details.

To ensure compliance and debuggability, a Tool Provider must implement comprehensive logging for all tool use. Each invocation generates an immutable audit record containing:

• A timestamp and unique request ID.
• The tool name and the validated input parameters (with secrets redacted).
• The execution result or error state.
• Performance metrics like latency.

These logs feed into Agentic Observability and Telemetry systems for monitoring and alerting.

A Tool Provider rarely contains all logic internally. Its primary role is to integrate with and orchestrate External System Connectors. This involves:

• Instantiating and managing clients for specific protocols (REST, gRPC, GraphQL).
• Translating the standardized MCP tool input into the native request format of the target system (e.g., constructing an HTTP request for a REST API).
• Parsing the external system's response back into the MCP result format.
• Implementing robust error handling and retry logic (e.g., exponential backoff) for transient network or service failures.

An MCP Tool is the executable function itself, defined by a name, description, and an input JSON Schema. It represents the contract between the client and server. The Tool Provider is responsible for hosting and executing these tools.

• Definition: The formal interface for an action.
• Example: A tool named query_database with a schema requiring a sql_query string parameter.
• Contrast: The Tool is the specification; the Tool Provider is the runtime that fulfills it.

A Tool Handler is the concrete server-side function containing the business logic that executes when a tool is invoked. Each tool exposed by a Tool Provider has a corresponding handler.

• Implementation: Contains code to call an API, run a script, or query a database.
• Execution Flow: The Tool Provider receives an invocation request, validates the input against the tool's schema, and passes the arguments to the registered handler.
• Responsibility: Handlers are where security checks, external service calls, and data transformations occur.

Tool Invocation is the event where an MCP client sends a request to execute a specific tool, providing the required arguments. This request is routed to the appropriate Tool Provider.

• Protocol: A JSON-RPC request (e.g., tools/call).
• Payload: Includes the tool name and an arguments object conforming to the tool's input schema.
• Lifecycle: The Provider validates the schema, executes the handler, and returns a result or error response to the client.

An MCP Server is the overarching process that hosts one or more Tool Providers (and Resource/Prompt Providers). It implements the MCP protocol and manages client connections.

• Container: A Tool Provider is a component within an MCP server.
• Role: The server handles transport (stdio/SSE), JSON-RPC messaging, and dispatches requests to the correct provider.
• Architecture: A single server can expose tools for multiple domains (e.g., database tools, CRM tools) via different internal providers.

Schema Validation is the critical process performed by the Tool Provider to ensure the arguments in a Tool Invocation request match the expected JSON Schema defined for that tool.

• Purpose: Prevents malformed or malicious inputs from reaching the handler.
• Enforcement: Validates data types, required fields, and value constraints.
• Error Handling: If validation fails, the Provider returns a structured error without executing the handler, ensuring safety and correctness.

An External System Connector is a pre-built adapter or client library that a Tool Provider's handler uses to interface with a specific external service (e.g., a REST API, gRPC service, or database).

• Implementation Detail: While the Tool Provider defines the interface, the handler often uses a connector for the actual communication.
• Examples: A PostgreSQL client, a Salesforce SDK, or a custom internal API wrapper.
• Separation of Concerns: The connector handles protocol-specific details (authentication, serialization), allowing the handler to focus on business logic.