ai llm mcp - ghdrako/doc_snipets GitHub Wiki

tags:

  • ai
  • llm
  • rag

Ai llm mcp

MCP

  • “USB-C for AI.”
  • is an open protocol that standardizes how AI applications connect to external data sources and tools. It was introduced by Anthropic in November 2024.
  • the standard for providing context to LLMs and AI agents, allowing them to function at a high level in real world, operational scenarios
  • MCP defines a complete protocol for three types of capabilities that a server can expose to an AI application:
  • tools (actions the AI can take),
  • resources (data the AI can read), and
  • prompts (templates that guide the AI’s behavior).

MCP as defining a contract between two parties: the AI application that wants to use external capabilities and the server that provides those capabilities. The protocol covers three main areas:

  • Tools as a function that the AI model can call when it needs to do something in the real world. Checking the weather, querying a database, sending an email, creating a calendar event. Each tool has a name, a description (so the AI knows when to use it; it’s still powered by a large language model), and a schema that defines its input parameters and output format. AI application discovers these tools automatically. You do not need to hardcode anything on the client side. The server announces what it can do, and the client figures out the rest.
  • Resources - represent data that the AI can read for context. While tools are about taking actions, resources are about providing information. A resource might be a file, a database record, a configuration setting, or any other piece of data that helps the AI understand the current context. Resources can be static (a fixed piece of data) or dynamic (generated on demand based on a template). They have URIs for identification and can include metadata that helps the AI understand what it is looking at.
  • Prompts - are reusable templates that guide the AI’s behavior. They allow the server to provide structured instructions that the AI can follow. Think of them as recipes: a prompt might define a specific workflow, like “analyze this code and suggest improvements” or “translate this document while preserving technical terminology.”Prompts can include parameters, making them dynamic and adaptable to different situations. They are a powerful way to encapsulate domain expertise and make it available to AI applications without requiring the client to know the details. You get to define the what and the how, and the AI takes care of the rest

Architecture

MCP organizes every interaction into three distinct layers: the host, the client, and the server. Application (the host) does not talk directly to the external service. Instead, it uses a client layer that knows how to open connections, send requests, and translate responses back into something your code understands. MCP follows the same separation of concerns, and each layer has a clear, well-defined job.

JSON-RPC 2.0 message

Every message that flows between an MCP client and server is a JSON-RPC 2.0 message. Unlike REST, which is built around resources and HTTP verbs, JSON-RPC is built around method calls. You send a JSON object that says, “Please call this method with these parameters,” and you get back a JSON object with the result. There are no URLs to design, no status codes to memorize, and no content negotiation to worry about.JSON-RPC defines three kinds of messages: requests, responses, and notifications.

Request

A request is a message that expects a response. It contains four fields: the JSON-RPC version string (always “2.0”, at least for now), an id that the sender chooses, the method name, and an optional params object. The id can be a string or a number, and the receiver must echo it back in the response so the sender can match them up. This is how MCP supports multiple in-flight requests without getting confused about which answer belongs to which question.

A JSON-RPC request message calling the tools/list method:

{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/list",
    "params": {}
}

Responses

A response is the answer to a request. It always includes the same id that was sent in the request, plus either a result field on success or an error field on failure. You will never see both result and error in the same response. This either-or rule makes it easy to handle responses in code: check for an error first, and if there is none, process the result.

{
    "jsonrpc": "2.0",
    "id": 1,
    "result": {
        "tools": [
            {
                "name": "get_weather",
                "description":
                "Returns the current weather"
                + " for a city",
                "inputSchema": {
                    "type": "object",
                    "properties": {
                        "city": {
                            "type": "string"
                        }
                    },
                    "required": ["city"]
                }
            }
        ]
    }  
}

Notifications

Notifications are fire-and-forget messages. They look like requests but they have no id field, which signals that the sender does not expect a response. MCP uses notifications for events like progress updates and cancellation signals. Because notifications do not require a round trip, they keep the protocol efficient for situations where an acknowledgment is not needed.

{
    "jsonrpc": "2.0",
    "method":
    "notifications/initialized"
}

DBT MCP

FastMCP

Something that makes it easy to define tools (decorators for Python functions)
A runtime to start the MCP Server
A basic MCP Client to interface with the server
  • Define a tool Python
from mcp.server.fastmcp import FastMCP

mcp = FastMCP("Demo")

@mcp.tool()
def get_weather(location: str) -> str:
    """Fetch the weather forecast for a given location."""
    ...

  • Framework PydanticAI

  • Start a local MCP server:‍ Shell

mcp dev ... path.to.your.module