Introduction

Connecting MCP to an AI agent means giving the agent a controlled way to discover and use capabilities that live outside the model. The model does not directly execute a database query, read a private file, or call a business API. Instead, an MCP client inside the agent connects to an MCP server, obtains the server’s tool definitions, sends those definitions to the model as available capabilities, and executes the tool call selected by the model.

This separation creates an important boundary. The model is responsible for interpreting the user’s request and proposing a tool name with structured arguments. The MCP client is responsible for maintaining the protocol session, invoking the selected tool, returning the result, and reporting errors. A reliable workflow therefore has three distinct stages: discovery, selection, and invocation. The same pattern works whether the model is hosted by a commercial API, a self-hosted model, or an internal agent framework.

MCP does not remove the need for application-level security. An agent should connect only to trusted servers, apply authentication where required, validate user permissions, and avoid automatically approving dangerous operations. A tool description helps the model choose a capability, but it is not a security policy.

The Agent Workflow

At startup, the MCP client opens a transport connection to the server and initializes an MCP session. The client then calls the protocol’s tool-discovery operation. The response contains tool names, descriptions, and input schemas. These schemas describe the arguments that a tool accepts, so the agent can provide the model with structured information rather than an informal paragraph.

The model uses the discovered definitions together with the user’s request. For example, if the server exposes a search_documents tool and a create_ticket tool, a request to find an incident report should normally produce a call to search_documents, not create_ticket. The model’s output should be treated as a proposed tool call containing a name and arguments. The host application must still verify that the name was discovered and that the arguments meet local policy before invoking it.

After validation, the MCP client calls the selected tool and receives structured content, text, or an error. The host application can return that result to the model for a final natural-language response. A multi-step agent repeats the cycle when the first tool result provides information needed by a second tool. The application should impose limits on the number of steps, execution time, and sensitive operations to prevent uncontrolled loops.

A Minimal MCP Client

The following Python program demonstrates discovery, selection, and invocation over Streamable HTTP. It uses the official MCP Python client interfaces for a client session and transport. Install the MCP Python package in the environment that runs the agent, and replace the URL with an MCP server that is already running and configured to accept this transport.

import argparse
import asyncio
import json

from mcp import ClientSession
from mcp.client.streamable_http import streamable_http_client


async def run(url: str, tool_name: str, arguments: dict) -> None:
    async with streamable_http_client(url) as streams:
        read_stream, write_stream, _ = streams

        async with ClientSession(read_stream, write_stream) as session:
            await session.initialize()
            discovered = await session.list_tools()

            print("Discovered tools:")
            for tool in discovered.tools:
                description = tool.description or "No description"
                print(f"- {tool.name}: {description}")

            selected = next(
                (tool for tool in discovered.tools if tool.name == tool_name),
                None,
            )
            if selected is None:
                available = ", ".join(tool.name for tool in discovered.tools)
                raise ValueError(
                    f"Unknown tool '{tool_name}'. Available tools: {available}"
                )

            print(f"Invoking {selected.name} with {json.dumps(arguments)}")
            result = await session.call_tool(
                selected.name,
                arguments=arguments,
            )
            print("Tool result:")
            if hasattr(result, "model_dump_json"):
                print(result.model_dump_json(indent=2))
            else:
                print(result)


def main() -> None:
    parser = argparse.ArgumentParser()
    parser.add_argument("url", help="MCP Streamable HTTP endpoint")
    parser.add_argument("tool", help="Discovered tool name to invoke")
    parser.add_argument(
        "--arguments",
        default="{}",
        help="JSON object containing tool arguments",
    )
    args = parser.parse_args()

    try:
        arguments = json.loads(args.arguments)
    except json.JSONDecodeError as error:
        raise SystemExit(f"Arguments must be valid JSON: {error}") from error

    if not isinstance(arguments, dict):
        raise SystemExit("Arguments must be a JSON object")

    try:
        asyncio.run(run(args.url, args.tool, arguments))
    except Exception as error:
        raise SystemExit(f"MCP request failed: {error}") from error


if __name__ == "__main__":
    main()

The input consists of an MCP endpoint, a tool name, and a JSON object of arguments. The program first prints the tools returned by discovery, then checks that the requested name is actually present. This check is important because a model can invent a tool name or retain a stale name from an earlier session. The output includes the server’s result, which the surrounding agent can pass back to the model for interpretation.

Connecting Discovery to Model Selection

A production agent places a model adapter between discovery and invocation. After list_tools returns, the host converts each tool’s name, description, and input schema into the model provider’s tool-calling format. The exact request format depends on the model API, so the MCP client should not assume that every provider uses the same message structure. The agent receives the model response, extracts the proposed name and JSON arguments, and performs local validation before calling session.call_tool.

The host should reject a tool call when the name is absent from the current discovery response, the arguments are not an object, required fields are missing, or a value violates application policy. Schema validation is useful, but authorization checks must happen separately. For example, a valid delete_record call can still be forbidden for a read-only user. Confirmation is also appropriate for irreversible actions, financial operations, external messages, or changes to production data.

After invocation, the result can be appended to the model conversation as a tool-result message. The model can then summarize the result or decide whether another permitted tool is needed. Keep the raw result available for logging, but redact credentials, personal data, and internal diagnostics before sending content to a third-party model.

Common Failures and Reliable Practices

A connection failure usually means that the endpoint is wrong, the server is unavailable, the transport is mismatched, or authentication is missing. Confirm that the server supports the selected transport and that network, proxy, and TLS settings permit the connection. Do not solve a transport problem by silently falling back to an unknown protocol; make the configured transport explicit and report the original error.

An unknown tool error occurs when the agent invokes a name that was not returned during the current discovery step. Refresh discovery when sessions or server capabilities can change, and always compare the requested name with the current tool set. Invalid arguments commonly result from missing required properties, incorrect types, or a model returning JSON encoded as a string instead of an object. Validate and normalize arguments before invocation, then preserve the server’s useful error message for debugging.

Another common mistake is exposing every connected server’s tools to every user. Tool names and descriptions can overlap, and a malicious or poorly configured server may present an unsafe capability. Use an explicit server allowlist, isolate credentials, apply per-tool authorization, set timeouts, cap repeated calls, and record which user, model decision, server, and tool were involved. These controls make the agent’s behavior observable and easier to review.

Summary

An MCP-enabled agent is best understood as a host application with two cooperating components. The model reasons about the user’s intent and proposes a structured call, while the MCP client discovers capabilities and performs protocol-compliant execution. The client must never assume that a tool exists merely because the model mentioned it; it should discover the current tools, validate the selection and arguments, and enforce local policy before invocation.

The practical workflow is initialize, list tools, present schemas to the model, validate the model’s proposed call, invoke the selected tool, and return the result for final reasoning. Once this loop works for one server, it can be extended to multiple servers and multi-step tasks without changing the core boundary. The most important implementation choices remain explicit transport configuration, strict validation, safe authorization, bounded execution, and useful error reporting.