What are we doing? Defining the tools and resources an MCP server makes available. Why? A server's whole value is exposing a capability once, through a standard protocol, to any client that connects — rather than each consuming application writing its own integration.

{
  "tools": [
    { "name": "search_repository", "description": "Search the connected code repository", "inputSchema": { "type": "object", "properties": { "query": { "type": "string" } }, "required": ["query"] } }
  ],
  "resources": [
    { "uri": "repo://readme", "description": "The repository's README file" }
  ]
}

What are we doing? Having the client ask a connected server what it offers. Why? This is what lets an agent gain new capability just by connecting to a new server, instead of being reconfigured with hardcoded tool definitions.

What are we doing? Translating the model's decision to use a discovered tool into an actual protocol call. Why? The model just decides what it wants to do — the client is responsible for actually executing that as a real request to the server.

def call_mcp_tool(client, server, tool_name, arguments):
    tool = server.get_tool(tool_name)
    validate(arguments, tool.input_schema)
    result = client.invoke(server, tool_name, arguments)
    return mark_as_untrusted_data(result)  # still external content

What are we doing? Pulling read-only content from the server into the agent's context. Why? Not everything the agent needs is an action — resources let it read reference content directly, similar in spirit to retrieval in a RAG system but sourced through MCP.

What are we doing? Deciding what a given client is actually allowed to do on a server. Why? Not every connecting client should necessarily have the same access — this is enforced server-side, not assumed from the client.

• Trusting MCP tool results by default

  A tool result from an MCP server is still external content and should be treated as untrusted data.

• Exposing more server capability than a use case requires

  The same least-privilege principle from agent architecture applies to what a server chooses to expose.

• Assuming every connecting client deserves the same access

  A server may need to authorize and scope access differently depending on which client connects.

• Writing vague tool descriptions on the server

  A poorly described tool is just as hard for a connecting model to use correctly as anywhere else.