diff --git a/.gitignore b/.gitignore index 7f106e9..b5e3d14 100644 --- a/.gitignore +++ b/.gitignore @@ -1,4 +1,36 @@ +# Dependencies node_modules/ +.pnp/ +.pnp.js + +# Build output build/ +dist/ +*.tsbuildinfo + +# Environment variables +.env +.env.local +.env.development.local +.env.test.local +.env.production.local + +# Logs +logs/ *.log -.env* \ No newline at end of file +npm-debug.log* +yarn-debug.log* +yarn-error.log* + +# Editor directories and files +.idea/ +.vscode/ +*.swp +*.swo +.DS_Store + +# Qdrant storage +qdrant_storage/ + +# Test coverage +coverage/ diff --git a/LICENSE b/LICENSE new file mode 100644 index 0000000..0b27b6d --- /dev/null +++ b/LICENSE @@ -0,0 +1,21 @@ +MIT License + +Copyright (c) 2024 qpd-v + +Permission is hereby granted, free of charge, to any person obtaining a copy +of this software and associated documentation files (the "Software"), to deal +in the Software without restriction, including without limitation the rights +to use, copy, modify, merge, publish, distribute, sublicense, and/or sell +copies of the Software, and to permit persons to whom the Software is +furnished to do so, subject to the following conditions: + +The above copyright notice and this permission notice shall be included in all +copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, +OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE +SOFTWARE. diff --git a/MCPguide.txt b/MCPguide.txt new file mode 100644 index 0000000..81ea536 --- /dev/null +++ b/MCPguide.txt @@ -0,0 +1,2901 @@ + Model Context Protocol +An open protocol that enables seamless integration between LLM applications and external data sources and tools. + + Verified + +3k followers + + https://modelcontextprotocol.io + +README.md +Model Context Protocol + +MCP Logo + +A protocol for seamless integration between LLM applications and external data sources + +Documentation | Specification | Discussions + +The Model Context Protocol (MCP) is an open protocol that enables seamless integration between LLM applications and external data sources and tools. Whether you're building an AI-powered IDE, enhancing a chat interface, or creating custom AI workflows, MCP provides a standardized way to connect LLMs with the context they need. +Getting Started + + 📚 Read the Documentation for guides and tutorials + 🔍 Review the Specification for protocol details + 💻 Use our SDKs to start building: + TypeScript SDK + Python SDK + +Project Structure + + specification - Protocol specification and documentation + typescript-sdk - TypeScript implementation + python-sdk - Python implementation + docs - User documentation and guides + create-python-server - Python server template + create-typescript-server - TypeScript server template + servers - List of maintained servers + +Contributing + +We welcome contributions of all kinds! Whether you want to fix bugs, improve documentation, or propose new features, please see our contributing guide to get started. + +Have questions? Join the discussion in our community forum. +About +The Model Context Protocol is an open source project run by Anthropic, PBC. and open to contributions from the entire community. + +Get Started +Introduction + +Get started with the Model Context Protocol (MCP) + +MCP is an open protocol that standardizes how applications provide context to LLMs. Think of MCP like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect your devices to various peripherals and accessories, MCP provides a standardized way to connect AI models to different data sources and tools. +​ +Why MCP? + +MCP helps you build agents and complex workflows on top of LLMs. LLMs frequently need to integrate with data and tools, and MCP provides: + + A growing list of pre-built integrations that your LLM can directly plug into + The flexibility to switch between LLM providers and vendors + Best practices for securing your data within your infrastructure + +​ +General architecture + +At its core, MCP follows a client-server architecture where a host application can connect to multiple servers: +Internet +Your Computer +MCP Protocol +MCP Protocol +MCP Protocol +Web APIs +Remote +Service C +MCP Host +(Claude, IDEs, Tools) +MCP Server A +MCP Server B +MCP Server C +Local +Data Source A +Local +Data Source B + + MCP Hosts: Programs like Claude Desktop, IDEs, or AI tools that want to access data through MCP + MCP Clients: Protocol clients that maintain 1:1 connections with servers + MCP Servers: Lightweight programs that each expose specific capabilities through the standardized Model Context Protocol + Local Data Sources: Your computer’s files, databases, and services that MCP servers can securely access + Remote Services: External systems available over the internet (e.g., through APIs) that MCP servers can connect to + +Quickstart + +Get started with building your first MCP server and connecting it to a host + +In this tutorial, we’ll build a simple MCP weather server and connect it to a host, Claude for Desktop. We’ll start with a basic setup, and then progress to more complex use cases. +​ +What we’ll be building + +Many LLMs (including Claude) do not currently have the ability to fetch the forecast and severe weather alerts. Let’s use MCP to solve that! + +We’ll build a server that exposes two tools: get-alerts and get-forecast. Then we’ll connect the server to an MCP host (in this case, Claude for Desktop): + +Servers can connect to any client. We’ve chosen Claude for Desktop here for simplicity, but we also have guides on building your own client as well as a list of other clients here. +​ +Core MCP Concepts + +MCP servers can provide three main types of capabilities: + + Resources: File-like data that can be read by clients (like API responses or file contents) + Tools: Functions that can be called by the LLM (with user approval) + Prompts: Pre-written templates that help users accomplish specific tasks + +This tutorial will primarily focus on tools. + +Let’s get started with building our weather server! You can find the complete code for what we’ll be building here. +Prerequisite knowledge + +This quickstart assumes you have familiarity with: + + Python + LLMs like Claude + +System requirements + +For Python, make sure you have Python 3.9 or higher installed. +Set up your environment + +First, let’s install uv and set up our Python project and environment: +mac/osx: +curl -LsSf https://astral.sh/uv/install.sh | sh + +windows: +powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex" + +Make sure to restart your terminal afterwards to ensure that the uv command gets picked up. + +Now, let’s create and set up our project: + +mac/osx: +# Create a new directory for our project +uv init weather +cd weather + +# Create virtual environment and activate it +uv venv +source .venv/bin/activate + +# Install dependencies +uv add mcp httpx + +# Remove template file +rm hello.py + +# Create our files +mkdir -p src/weather +touch src/weather/__init__.py +touch src/weather/server.py + +windows: +# Create a new directory for our project +uv init weather +cd weather + +# Create virtual environment and activate it +uv venv +.venv\Scripts\activate + +# Install dependencies +uv add mcp httpx + +# Clean up boilerplate code +rm hello.py + +# Create our files +md src +md src\weather +new-item src\weather\__init__.py +new-item src\weather\server.py + +Add this code to pyproject.toml: + +...rest of config + +[build-system] +requires = [ "hatchling",] +build-backend = "hatchling.build" + +[project.scripts] +weather = "weather:main" + +Add this code to __init__.py: +src/weather/__init__.py + +from . import server +import asyncio + +def main(): + """Main entry point for the package.""" + asyncio.run(server.main()) + +# Optionally expose other important items at package level +__all__ = ['main', 'server'] + +Now let’s dive into building your server. +Building your server +Importing packages + +Add these to the top of your server.py: + +from typing import Any +import asyncio +import httpx +from mcp.server.models import InitializationOptions +import mcp.types as types +from mcp.server import NotificationOptions, Server +import mcp.server.stdio + +Setting up the instance + +Then initialize the server instance and the base URL for the NWS API: + +NWS_API_BASE = "https://api.weather.gov" +USER_AGENT = "weather-app/1.0" + +server = Server("weather") + +Implementing tool listing + +We need to tell clients what tools are available. The list_tools() decorator registers this handler: + +@server.list_tools() +async def handle_list_tools() -> list[types.Tool]: + """ + List available tools. + Each tool specifies its arguments using JSON Schema validation. + """ + return [ + types.Tool( + name="get-alerts", + description="Get weather alerts for a state", + inputSchema={ + "type": "object", + "properties": { + "state": { + "type": "string", + "description": "Two-letter state code (e.g. CA, NY)", + }, + }, + "required": ["state"], + }, + ), + types.Tool( + name="get-forecast", + description="Get weather forecast for a location", + inputSchema={ + "type": "object", + "properties": { + "latitude": { + "type": "number", + "description": "Latitude of the location", + }, + "longitude": { + "type": "number", + "description": "Longitude of the location", + }, + }, + "required": ["latitude", "longitude"], + }, + ), + ] + +This defines our two tools: get-alerts and get-forecast. +Helper functions + +Next, let’s add our helper functions for querying and formatting the data from the National Weather Service API: + +async def make_nws_request(client: httpx.AsyncClient, url: str) -> dict[str, Any] | None: + """Make a request to the NWS API with proper error handling.""" + headers = { + "User-Agent": USER_AGENT, + "Accept": "application/geo+json" + } + + try: + response = await client.get(url, headers=headers, timeout=30.0) + response.raise_for_status() + return response.json() + except Exception: + return None + +def format_alert(feature: dict) -> str: + """Format an alert feature into a concise string.""" + props = feature["properties"] + return ( + f"Event: {props.get('event', 'Unknown')}\n" + f"Area: {props.get('areaDesc', 'Unknown')}\n" + f"Severity: {props.get('severity', 'Unknown')}\n" + f"Status: {props.get('status', 'Unknown')}\n" + f"Headline: {props.get('headline', 'No headline')}\n" + "---" + ) + +Implementing tool execution + +The tool execution handler is responsible for actually executing the logic of each tool. Let’s add it: + +@server.call_tool() +async def handle_call_tool( + name: str, arguments: dict | None +) -> list[types.TextContent | types.ImageContent | types.EmbeddedResource]: + """ + Handle tool execution requests. + Tools can fetch weather data and notify clients of changes. + """ + if not arguments: + raise ValueError("Missing arguments") + + if name == "get-alerts": + state = arguments.get("state") + if not state: + raise ValueError("Missing state parameter") + + # Convert state to uppercase to ensure consistent format + state = state.upper() + if len(state) != 2: + raise ValueError("State must be a two-letter code (e.g. CA, NY)") + + async with httpx.AsyncClient() as client: + alerts_url = f"{NWS_API_BASE}/alerts?area={state}" + alerts_data = await make_nws_request(client, alerts_url) + + if not alerts_data: + return [types.TextContent(type="text", text="Failed to retrieve alerts data")] + + features = alerts_data.get("features", []) + if not features: + return [types.TextContent(type="text", text=f"No active alerts for {state}")] + + # Format each alert into a concise string + formatted_alerts = [format_alert(feature) for feature in features[:20]] # only take the first 20 alerts + alerts_text = f"Active alerts for {state}:\n\n" + "\n".join(formatted_alerts) + + return [ + types.TextContent( + type="text", + text=alerts_text + ) + ] + elif name == "get-forecast": + try: + latitude = float(arguments.get("latitude")) + longitude = float(arguments.get("longitude")) + except (TypeError, ValueError): + return [types.TextContent( + type="text", + text="Invalid coordinates. Please provide valid numbers for latitude and longitude." + )] + + # Basic coordinate validation + if not (-90 <= latitude <= 90) or not (-180 <= longitude <= 180): + return [types.TextContent( + type="text", + text="Invalid coordinates. Latitude must be between -90 and 90, longitude between -180 and 180." + )] + + async with httpx.AsyncClient() as client: + # First get the grid point + lat_str = f"{latitude}" + lon_str = f"{longitude}" + points_url = f"{NWS_API_BASE}/points/{lat_str},{lon_str}" + points_data = await make_nws_request(client, points_url) + + if not points_data: + return [types.TextContent(type="text", text=f"Failed to retrieve grid point data for coordinates: {latitude}, {longitude}. This location may not be supported by the NWS API (only US locations are supported).")] + + # Extract forecast URL from the response + properties = points_data.get("properties", {}) + forecast_url = properties.get("forecast") + + if not forecast_url: + return [types.TextContent(type="text", text="Failed to get forecast URL from grid point data")] + + # Get the forecast + forecast_data = await make_nws_request(client, forecast_url) + + if not forecast_data: + return [types.TextContent(type="text", text="Failed to retrieve forecast data")] + + # Format the forecast periods + periods = forecast_data.get("properties", {}).get("periods", []) + if not periods: + return [types.TextContent(type="text", text="No forecast periods available")] + + # Format each period into a concise string + formatted_forecast = [] + for period in periods: + forecast_text = ( + f"{period.get('name', 'Unknown')}:\n" + f"Temperature: {period.get('temperature', 'Unknown')}°{period.get('temperatureUnit', 'F')}\n" + f"Wind: {period.get('windSpeed', 'Unknown')} {period.get('windDirection', '')}\n" + f"{period.get('shortForecast', 'No forecast available')}\n" + "---" + ) + formatted_forecast.append(forecast_text) + + forecast_text = f"Forecast for {latitude}, {longitude}:\n\n" + "\n".join(formatted_forecast) + + return [types.TextContent( + type="text", + text=forecast_text + )] + else: + raise ValueError(f"Unknown tool: {name}") + +Running the server + +Finally, implement the main function to run the server: + +async def main(): + # Run the server using stdin/stdout streams + async with mcp.server.stdio.stdio_server() as (read_stream, write_stream): + await server.run( + read_stream, + write_stream, + InitializationOptions( + server_name="weather", + server_version="0.1.0", + capabilities=server.get_capabilities( + notification_options=NotificationOptions(), + experimental_capabilities={}, + ), + ), + ) + +# This is needed if you'd like to connect to a custom client +if __name__ == "__main__": + asyncio.run(main()) + +Your server is complete! Run uv run src/weather/server.py to confirm that everything’s working. + +Let’s now test your server from an existing MCP host, Claude for Desktop. +Testing your server with Claude for Desktop + +Claude for Desktop is not yet available on Linux. Linux users can proceed to the Building a client tutorial to build an MCP client that connects to the server we just built. + +First, make sure you have Claude for Desktop installed. You can install the latest version here. If you already have Claude for Desktop, make sure it’s updated to the latest version. + +We’ll need to configure Claude for Desktop for whichever MCP servers you want to use. To do this, open your Claude for Desktop App configuration at ~/Library/Application Support/Claude/claude_desktop_config.json in a text editor. Make sure to create the file if it doesn’t exist. + +For example, if you have VS Code installed: +mac/osx: +code ~/Library/Application\ Support/Claude/claude_desktop_config.json + +windows: +code $env:AppData\Claude\claude_desktop_config.json + +You’ll then add your servers in the mcpServers key. The MCP UI elements will only show up in Claude for Desktop if at least one server is properly configured. + +In this case, we’ll add our single weather server like so: + + +mac/osx (python): + +{ + "mcpServers": { + "weather": { + "command": "uv", + "args": [ + "--directory", + "/ABSOLUTE/PATH/TO/PARENT/FOLDER/weather", + "run", + "weather" + ] + } + } +} + +windows (python): + +{ + "mcpServers": { + "weather": { + "command": "uv", + "args": [ + "--directory", + "C:\\ABSOLUTE\PATH\TO\PARENT\FOLDER\weather", + "run", + "weather" + ] + } + } +} + + +Make sure you pass in the absolute path to your server. + +This tells Claude for Desktop: + + There’s an MCP server named “weather” + To launch it by running uv --directory /ABSOLUTE/PATH/TO/PARENT/FOLDER/weather run weather + +Save the file, and restart Claude for Desktop. +​ +Test with commands + +Let’s make sure Claude for Desktop is picking up the two tools we’ve exposed in our weather server. You can do this by looking for the hammer icon: + +After clicking on the hammer icon, you should see two tools listed: + +If your server isn’t being picked up by Claude for Desktop, proceed to the Troubleshooting section for debugging tips. + +If the hammer icon has shown up, you can now test your server by running the following commands in Claude for Desktop: + + What’s the weather in Sacramento? + What are the active weather alerts in Texas? + +Since this is the US National Weather service, the queries will only work for US locations. +​ +What’s happening under the hood + +When you ask a question: + + The client sends your question to Claude + Claude analyzes the available tools and decides which one(s) to use + The client executes the chosen tool(s) through the MCP server + The results are sent back to Claude + Claude formulates a natural language response + The response is displayed to you! + +Get Started +Examples + +A list of example servers and implementations + +This page showcases various Model Context Protocol (MCP) servers that demonstrate the protocol’s capabilities and versatility. These servers enable Large Language Models (LLMs) to securely access tools and data sources. +​ +Reference implementations + +These official reference servers demonstrate core MCP features and SDK usage: +​ +Data and file systems + + Filesystem - Secure file operations with configurable access controls + PostgreSQL - Read-only database access with schema inspection capabilities + SQLite - Database interaction and business intelligence features + Google Drive - File access and search capabilities for Google Drive + +​ +Development tools + + Git - Tools to read, search, and manipulate Git repositories + GitHub - Repository management, file operations, and GitHub API integration + GitLab - GitLab API integration enabling project management + Sentry - Retrieving and analyzing issues from Sentry.io + +​ +Web and browser automation + + Brave Search - Web and local search using Brave’s Search API + Fetch - Web content fetching and conversion optimized for LLM usage + Puppeteer - Browser automation and web scraping capabilities + +​ +Productivity and communication + + Slack - Channel management and messaging capabilities + Google Maps - Location services, directions, and place details + Memory - Knowledge graph-based persistent memory system + +​ +AI and specialized tools + + EverArt - AI image generation using various models + Sequential Thinking - Dynamic problem-solving through thought sequences + AWS KB Retrieval - Retrieval from AWS Knowledge Base using Bedrock Agent Runtime + +​ +Official integrations + +These MCP servers are maintained by companies for their platforms: + + Axiom - Query and analyze logs, traces, and event data using natural language + Browserbase - Automate browser interactions in the cloud + Cloudflare - Deploy and manage resources on the Cloudflare developer platform + E2B - Execute code in secure cloud sandboxes + Neon - Interact with the Neon serverless Postgres platform + Obsidian Markdown Notes - Read and search through Markdown notes in Obsidian vaults + Qdrant - Implement semantic memory using the Qdrant vector search engine + Raygun - Access crash reporting and monitoring data + Search1API - Unified API for search, crawling, and sitemaps + Tinybird - Interface with the Tinybird serverless ClickHouse platform + +​ +Community highlights + +A growing ecosystem of community-developed servers extends MCP’s capabilities: + + Docker - Manage containers, images, volumes, and networks + Kubernetes - Manage pods, deployments, and services + Linear - Project management and issue tracking + Snowflake - Interact with Snowflake databases + Spotify - Control Spotify playback and manage playlists + Todoist - Task management integration + + Note: Community servers are untested and should be used at your own risk. They are not affiliated with or endorsed by Anthropic. + +For a complete list of community servers, visit the MCP Servers Repository. +​ +Getting started +​ +Using reference servers + +TypeScript-based servers can be used directly with npx: + +npx -y @modelcontextprotocol/server-memory + +Python-based servers can be used with uvx (recommended) or pip: + +# Using uvx +uvx mcp-server-git + +# Using pip +pip install mcp-server-git +python -m mcp_server_git + +​ +Configuring with Claude + +To use an MCP server with Claude, add it to your configuration: + +{ + "mcpServers": { + "memory": { + "command": "npx", + "args": ["-y", "@modelcontextprotocol/server-memory"] + }, + "filesystem": { + "command": "npx", + "args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/allowed/files"] + }, + "github": { + "command": "npx", + "args": ["-y", "@modelcontextprotocol/server-github"], + "env": { + "GITHUB_PERSONAL_ACCESS_TOKEN": "" + } + } + } +} + +​ +Additional resources + + MCP Servers Repository - Complete collection of reference implementations and community servers + Awesome MCP Servers - Curated list of MCP servers + MCP CLI - Command-line inspector for testing MCP servers + MCP Get - Tool for installing and managing MCP servers + +Visit our GitHub Discussions to engage with the MCP community. + +Was this page helpful? + +Get Started +Clients + +A list of applications that support MCP integrations + +This page provides an overview of applications that support the Model Context Protocol (MCP). Each client may support different MCP features, allowing for varying levels of integration with MCP servers. +​ +Feature support matrix +Client Resources Prompts Tools Sampling Roots Notes +Claude Desktop App ✅ ✅ ✅ ❌ ❌ Full support for all MCP features +Zed ❌ ✅ ❌ ❌ ❌ Prompts appear as slash commands +Sourcegraph Cody ✅ ❌ ❌ ❌ ❌ Supports resources through OpenCTX +Firebase Genkit ⚠️ ✅ ✅ ❌ ❌ Supports resource list and lookup through tools. +Continue ✅ ✅ ✅ ❌ ❌ Full support for all MCP features +GenAIScript ❌ ❌ ✅ ❌ ❌ Supports tools. +​ +Client details +​ +Claude Desktop App + +The Claude desktop application provides comprehensive support for MCP, enabling deep integration with local tools and data sources. + +Key features: + + Full support for resources, allowing attachment of local files and data + Support for prompt templates + Tool integration for executing commands and scripts + Local server connections for enhanced privacy and security + + ⓘ Note: The Claude.ai web application does not currently support MCP. MCP features are only available in the desktop application. + +​ +Zed + +Zed is a high-performance code editor with built-in MCP support, focusing on prompt templates and tool integration. + +Key features: + + Prompt templates surface as slash commands in the editor + Tool integration for enhanced coding workflows + Tight integration with editor features and workspace context + Does not support MCP resources + +​ +Sourcegraph Cody + +Cody is Sourcegraph’s AI coding assistant, which implements MCP through OpenCTX. + +Key features: + + Support for MCP resources + Integration with Sourcegraph’s code intelligence + Uses OpenCTX as an abstraction layer + Future support planned for additional MCP features + +​ +Firebase Genkit + +Genkit is Firebase’s SDK for building and integrating GenAI features into applications. The genkitx-mcp plugin enables consuming MCP servers as a client or creating MCP servers from Genkit tools and prompts. + +Key features: + + Client support for tools and prompts (resources partially supported) + Rich discovery with support in Genkit’s Dev UI playground + Seamless interoperability with Genkit’s existing tools and prompts + Works across a wide variety of GenAI models from top providers + +​ +Continue + +Continue is an open-source AI code assistant, with built-in support for all MCP features. + +Key features + + Type ”@” to mention MCP resources + Prompt templates surface as slash commands + Use both built-in and MCP tools directly in chat + Supports VS Code and JetBrains IDEs, with any LLM + +​ +GenAIScript + +Programmatically assemble prompts for LLMs using GenAIScript (in JavaScript). Orchestrate LLMs, tools, and data in JavaScript. + +Key features: + + JavaScript toolbox to work with prompts + Abstraction to make it easy and productive + Seamless Visual Studio Code integration + +​ +Adding MCP support to your application + +If you’ve added MCP support to your application, we encourage you to submit a pull request to add it to this list. MCP integration can provide your users with powerful contextual AI capabilities and make your application part of the growing MCP ecosystem. + +Benefits of adding MCP support: + + Enable users to bring their own context and tools + Join a growing ecosystem of interoperable AI applications + Provide users with flexible integration options + Support local-first AI workflows + +To get started with implementing MCP in your application, check out our Python or TypeScript SDK Documentation +​ +Tutorials +Building MCP clients + +Learn how to build your first client in MCP + +In this tutorial, you’ll learn how to build a LLM-powered chatbot client that connects to MCP servers. It helps to have gone through the Quickstart tutorial that guides you through the basic of building your first server. + +You can find the complete code for this tutorial here. +System Requirements + +Before starting, ensure your system meets these requirements: + + Mac or Windows computer + Latest Python version installed + Latest version of uv installed + +Setting Up Your Environment + +First, create a new Python project with uv: + +# Create project directory +uv init mcp-client +cd mcp-client + +# Create virtual environment +uv venv + +# Activate virtual environment +# On Windows: +.venv\Scripts\activate +# On Unix or MacOS: +source .venv/bin/activate + +# Install required packages +uv add mcp anthropic python-dotenv + +# Remove boilerplate files +rm hello.py + +# Create our main file +touch client.py + +Setting Up Your API Key + +You’ll need an Anthropic API key from the Anthropic Console. + +Create a .env file to store it: + +# Create .env file +touch .env + +Add your key to the .env file: + +ANTHROPIC_API_KEY= + +Add .env to your .gitignore: + +echo ".env" >> .gitignore + +Make sure you keep your ANTHROPIC_API_KEY secure! +Creating the Client +Basic Client Structure + +First, let’s set up our imports and create the basic client class: + +import asyncio +from typing import Optional +from contextlib import AsyncExitStack + +from mcp import ClientSession, StdioServerParameters +from mcp.client.stdio import stdio_client + +from anthropic import Anthropic +from dotenv import load_dotenv + +load_dotenv() # load environment variables from .env + +class MCPClient: + def __init__(self): + # Initialize session and client objects + self.session: Optional[ClientSession] = None + self.exit_stack = AsyncExitStack() + self.anthropic = Anthropic() + # methods will go here + +Server Connection Management + +Next, we’ll implement the method to connect to an MCP server: + +async def connect_to_server(self, server_script_path: str): + """Connect to an MCP server + + Args: + server_script_path: Path to the server script (.py or .js) + """ + is_python = server_script_path.endswith('.py') + is_js = server_script_path.endswith('.js') + if not (is_python or is_js): + raise ValueError("Server script must be a .py or .js file") + + command = "python" if is_python else "node" + server_params = StdioServerParameters( + command=command, + args=[server_script_path], + env=None + ) + + stdio_transport = await self.exit_stack.enter_async_context(stdio_client(server_params)) + self.stdio, self.write = stdio_transport + self.session = await self.exit_stack.enter_async_context(ClientSession(self.stdio, self.write)) + + await self.session.initialize() + + # List available tools + response = await self.session.list_tools() + tools = response.tools + print("\nConnected to server with tools:", [tool.name for tool in tools]) + +Query Processing Logic + +Now let’s add the core functionality for processing queries and handling tool calls: + +async def process_query(self, query: str) -> str: + """Process a query using Claude and available tools""" + messages = [ + { + "role": "user", + "content": query + } + ] + + response = await self.session.list_tools() + available_tools = [{ + "name": tool.name, + "description": tool.description, + "input_schema": tool.inputSchema + } for tool in response.tools] + + # Initial Claude API call + response = self.anthropic.messages.create( + model="claude-3-5-sonnet-20241022", + max_tokens=1000, + messages=messages, + tools=available_tools + ) + + # Process response and handle tool calls + tool_results = [] + final_text = [] + + for content in response.content: + if content.type == 'text': + final_text.append(content.text) + elif content.type == 'tool_use': + tool_name = content.name + tool_args = content.input + + # Execute tool call + result = await self.session.call_tool(tool_name, tool_args) + tool_results.append({"call": tool_name, "result": result}) + final_text.append(f"[Calling tool {tool_name} with args {tool_args}]") + + # Continue conversation with tool results + if hasattr(content, 'text') and content.text: + messages.append({ + "role": "assistant", + "content": content.text + }) + messages.append({ + "role": "user", + "content": result.content + }) + + # Get next response from Claude + response = self.anthropic.messages.create( + model="claude-3-5-sonnet-20241022", + max_tokens=1000, + messages=messages, + ) + + final_text.append(response.content[0].text) + + return "\n".join(final_text) + +Interactive Chat Interface + +Now we’ll add the chat loop and cleanup functionality: + +async def chat_loop(self): + """Run an interactive chat loop""" + print("\nMCP Client Started!") + print("Type your queries or 'quit' to exit.") + + while True: + try: + query = input("\nQuery: ").strip() + + if query.lower() == 'quit': + break + + response = await self.process_query(query) + print("\n" + response) + + except Exception as e: + print(f"\nError: {str(e)}") + +async def cleanup(self): + """Clean up resources""" + await self.exit_stack.aclose() + +Main Entry Point + +Finally, we’ll add the main execution logic: + +async def main(): + if len(sys.argv) < 2: + print("Usage: python client.py ") + sys.exit(1) + + client = MCPClient() + try: + await client.connect_to_server(sys.argv[1]) + await client.chat_loop() + finally: + await client.cleanup() + +if __name__ == "__main__": + import sys + asyncio.run(main()) + +You can find the complete client.py file here. +Key Components Explained +1. Client Initialization + + The MCPClient class initializes with session management and API clients + Uses AsyncExitStack for proper resource management + Configures the Anthropic client for Claude interactions + +2. Server Connection + + Supports both Python and Node.js servers + Validates server script type + Sets up proper communication channels + Initializes the session and lists available tools + +3. Query Processing + + Maintains conversation context + Handles Claude’s responses and tool calls + Manages the message flow between Claude and tools + Combines results into a coherent response + +4. Interactive Interface + + Provides a simple command-line interface + Handles user input and displays responses + Includes basic error handling + Allows graceful exit + +5. Resource Management + + Proper cleanup of resources + Error handling for connection issues + Graceful shutdown procedures + +Common Customization Points + + Tool Handling + Modify process_query() to handle specific tool types + Add custom error handling for tool calls + Implement tool-specific response formatting + + Response Processing + Customize how tool results are formatted + Add response filtering or transformation + Implement custom logging + + User Interface + Add a GUI or web interface + Implement rich console output + Add command history or auto-completion + +Running the Client + +To run your client with any MCP server: + +uv run client.py path/to/server.py # python server +uv run client.py path/to/build/index.js # node server + +If you’re continuing the weather tutorial from the quickstart, your command might look something like this: python client.py .../weather/src/weather/server.py + +The client will: + + Connect to the specified server + List available tools + Start an interactive chat session where you can: + Enter queries + See tool executions + Get responses from Claude + +Here’s an example of what it should look like if connected to the weather server from the quickstart: +How It Works + +When you submit a query: + + The client gets the list of available tools from the server + Your query is sent to Claude along with tool descriptions + Claude decides which tools (if any) to use + The client executes any requested tool calls through the server + Results are sent back to Claude + Claude provides a natural language response + The response is displayed to you + +Best practices + + Error Handling + Always wrap tool calls in try-catch blocks + Provide meaningful error messages + Gracefully handle connection issues + + Resource Management + Use AsyncExitStack for proper cleanup + Close connections when done + Handle server disconnections + + Security + Store API keys securely in .env + Validate server responses + Be cautious with tool permissions + +Troubleshooting +Server Path Issues + + Double-check the path to your server script is correct + Use the absolute path if the relative path isn’t working + For Windows users, make sure to use forward slashes (/) or escaped backslashes (\) in the path + Verify the server file has the correct extension (.py for Python or .js for Node.js) + +Example of correct path usage: + +# Relative path +uv run client.py ./server/weather.py + +# Absolute path +uv run client.py /Users/username/projects/mcp-server/weather.py + +# Windows path (either format works) +uv run client.py C:/projects/mcp-server/weather.py +uv run client.py C:\\projects\\mcp-server\\weather.py + +Response Timing + + The first response might take up to 30 seconds to return + This is normal and happens while: + The server initializes + Claude processes the query + Tools are being executed + Subsequent responses are typically faster + Don’t interrupt the process during this initial waiting period + +Common Error Messages + +If you see: + + FileNotFoundError: Check your server path + Connection refused: Ensure the server is running and the path is correct + Tool execution failed: Verify the tool’s required environment variables are set + Timeout error: Consider increasing the timeout in your client configuration + +​ +Next steps +Example servers + +Check out our gallery of official MCP servers and implementations +Clients + +View the list of clients that support MCP integrations +Building MCP with LLMs + +Learn how to use LLMs like Claude to speed up your MCP development +Core architecture + +Understand how MCP connects clients, servers, and LLMs + +Tutorials +Building MCP with LLMs + +Speed up your MCP development using LLMs such as Claude! + +This guide will help you use LLMs to help you build custom Model Context Protocol (MCP) servers and clients. We’ll be focusing on Claude for this tutorial, but you can do this with any frontier LLM. +​ +Preparing the documentation + +Before starting, gather the necessary documentation to help Claude understand MCP: + + Visit https://modelcontextprotocol.io/llms-full.txt and copy the full documentation text + Navigate to either the MCP TypeScript SDK or Python SDK repository + Copy the README files and other relevant documentation + Paste these documents into your conversation with Claude + +​ +Describing your server + +Once you’ve provided the documentation, clearly describe to Claude what kind of server you want to build. Be specific about: + + What resources your server will expose + What tools it will provide + Any prompts it should offer + What external systems it needs to interact with + +For example: + +Build an MCP server that: +- Connects to my company's PostgreSQL database +- Exposes table schemas as resources +- Provides tools for running read-only SQL queries +- Includes prompts for common data analysis tasks + +​ +Working with Claude + +When working with Claude on MCP servers: + + Start with the core functionality first, then iterate to add more features + Ask Claude to explain any parts of the code you don’t understand + Request modifications or improvements as needed + Have Claude help you test the server and handle edge cases + +Claude can help implement all the key MCP features: + + Resource management and exposure + Tool definitions and implementations + Prompt templates and handlers + Error handling and logging + Connection and transport setup + +​ +Best practices + +When building MCP servers with Claude: + + Break down complex servers into smaller pieces + Test each component thoroughly before moving on + Keep security in mind - validate inputs and limit access appropriately + Document your code well for future maintenance + Follow MCP protocol specifications carefully + +​ +Next steps + +After Claude helps you build your server: + + Review the generated code carefully + Test the server with the MCP Inspector tool + Connect it to Claude.app or other MCP clients + Iterate based on real usage and feedback + +Remember that Claude can help you modify and improve your server as requirements change over time. + +Need more guidance? Just ask Claude specific questions about implementing MCP features or troubleshooting issues that arise. + + +Tutorials +Debugging + +A comprehensive guide to debugging Model Context Protocol (MCP) integrations + +Effective debugging is essential when developing MCP servers or integrating them with applications. This guide covers the debugging tools and approaches available in the MCP ecosystem. + +This guide is for macOS. Guides for other platforms are coming soon. +​ +Debugging tools overview + +MCP provides several tools for debugging at different levels: + + MCP Inspector + Interactive debugging interface + Direct server testing + See the Inspector guide for details + + Claude Desktop Developer Tools + Integration testing + Log collection + Chrome DevTools integration + + Server Logging + Custom logging implementations + Error tracking + Performance monitoring + +​ +Debugging in Claude Desktop +​ +Checking server status + +The Claude.app interface provides basic server status information: + + Click the icon to view: + Connected servers + Available prompts and resources + + Click the icon to view: + Tools made available to the model + +​ +Viewing logs + +Review detailed MCP logs from Claude Desktop: + +# Follow logs in real-time +tail -n 20 -f ~/Library/Logs/Claude/mcp*.log + +The logs capture: + + Server connection events + Configuration issues + Runtime errors + Message exchanges + +​ +Using Chrome DevTools + +Access Chrome’s developer tools inside Claude Desktop to investigate client-side errors: + + Enable DevTools: + +jq '.allowDevTools = true' ~/Library/Application\ Support/Claude/developer_settings.json > tmp.json \ + && mv tmp.json ~/Library/Application\ Support/Claude/developer_settings.json + + Open DevTools: Command-Option-Shift-i + +Note: You’ll see two DevTools windows: + + Main content window + App title bar window + +Use the Console panel to inspect client-side errors. + +Use the Network panel to inspect: + + Message payloads + Connection timing + +​ +Common issues +​ +Environment variables + +MCP servers inherit only a subset of environment variables automatically, like USER, HOME, and PATH. + +To override the default variables or provide your own, you can specify an env key in claude_desktop_config.json: + +{ + "myserver": { + "command": "mcp-server-myapp", + "env": { + "MYAPP_API_KEY": "some_key", + } + } +} + +​ +Server initialization + +Common initialization problems: + + Path Issues + Incorrect server executable path + Missing required files + Permission problems + + Configuration Errors + Invalid JSON syntax + Missing required fields + Type mismatches + + Environment Problems + Missing environment variables + Incorrect variable values + Permission restrictions + +​ +Connection problems + +When servers fail to connect: + + Check Claude Desktop logs + Verify server process is running + Test standalone with Inspector + Verify protocol compatibility + +​ +Implementing logging +​ +Server-side logging + +When building a server that uses the local stdio transport, all messages logged to stderr (standard error) will be captured by the host application (e.g., Claude Desktop) automatically. + +Local MCP servers should not log messages to stdout (standard out), as this will interfere with protocol operation. + +For all transports, you can also provide logging to the client by sending a log message notification: + +typescript: + +server.sendLoggingMessage({ + level: "info", + data: "Server started successfully", +}); + + +python: + +server.request_context.session.send_log_message( + level="info", + data="Server started successfully", +) + +Important events to log: + + Initialization steps + Resource access + Tool execution + Error conditions + Performance metrics + +​ +Client-side logging + +In client applications: + + Enable debug logging + Monitor network traffic + Track message exchanges + Record error states + +​ +Debugging workflow +​ +Development cycle + + Initial Development + Use Inspector for basic testing + Implement core functionality + Add logging points + + Integration Testing + Test in Claude Desktop + Monitor logs + Check error handling + +​ +Testing changes + +To test changes efficiently: + + Configuration changes: Restart Claude Desktop + Server code changes: Use Command-R to reload + Quick iteration: Use Inspector during development + +​ +Best practices +​ +Logging strategy + + Structured Logging + Use consistent formats + Include context + Add timestamps + Track request IDs + + Error Handling + Log stack traces + Include error context + Track error patterns + Monitor recovery + + Performance Tracking + Log operation timing + Monitor resource usage + Track message sizes + Measure latency + +​ +Security considerations + +When debugging: + + Sensitive Data + Sanitize logs + Protect credentials + Mask personal information + + Access Control + Verify permissions + Check authentication + Monitor access patterns + +​ +Getting help + +When encountering issues: + + First Steps + Check server logs + Test with Inspector + Review configuration + Verify environment + + Support Channels + GitHub issues + GitHub discussions + + Providing Information + Log excerpts + Configuration files + Steps to reproduce + Environment details + +​ +Next steps +MCP Inspector + +Learn to use the MCP Inspector +Tutorials +Inspector + +In-depth guide to using the MCP Inspector for testing and debugging Model Context Protocol servers + +The MCP Inspector is an interactive developer tool for testing and debugging MCP servers. While the Debugging Guide covers the Inspector as part of the overall debugging toolkit, this document provides a detailed exploration of the Inspector’s features and capabilities. +​ +Getting started +​ +Installation and basic usage + +The Inspector runs directly through npx without requiring installation: + +npx @modelcontextprotocol/inspector + +npx @modelcontextprotocol/inspector + +​ +Inspecting servers from NPM or PyPi + +A common way to start server packages from NPM or PyPi. + +npx -y @modelcontextprotocol/inspector npx +# For example +npx -y @modelcontextprotocol/inspector npx server-postgres postgres://127.0.0.1/testdb + +​ +Inspecting locally developed servers + +To inspect servers locally developed or downloaded as a repository, the most common way is: + +npx @modelcontextprotocol/inspector node path/to/server/index.js args... + +Please carefully read any attached README for the most accurate instructions. +​ +Feature overview + +The MCP Inspector interface + +The Inspector provides several features for interacting with your MCP server: +​ +Server connection pane + + Allows selecting the transport for connecting to the server + For local servers, supports customizing the command-line arguments and environment + +​ +Resources tab + + Lists all available resources + Shows resource metadata (MIME types, descriptions) + Allows resource content inspection + Supports subscription testing + +​ +Prompts tab + + Displays available prompt templates + Shows prompt arguments and descriptions + Enables prompt testing with custom arguments + Previews generated messages + +​ +Tools tab + + Lists available tools + Shows tool schemas and descriptions + Enables tool testing with custom inputs + Displays tool execution results + +​ +Notifications pane + + Presents all logs recorded from the server + Shows notifications received from the server + +​ +Best practices +​ +Development workflow + + Start Development + Launch Inspector with your server + Verify basic connectivity + Check capability negotiation + + Iterative testing + Make server changes + Rebuild the server + Reconnect the Inspector + Test affected features + Monitor messages + + Test edge cases + Invalid inputs + Missing prompt arguments + Concurrent operations + Verify error handling and error responses + +​ +Next steps +Inspector Repository + +Check out the MCP Inspector source code +Debugging Guide + +Learn about broader debugging strategies + +Was this page helpful? +Concepts +Core architecture + +Understand how MCP connects clients, servers, and LLMs + +The Model Context Protocol (MCP) is built on a flexible, extensible architecture that enables seamless communication between LLM applications and integrations. This document covers the core architectural components and concepts. +​ +Overview + +MCP follows a client-server architecture where: + + Hosts are LLM applications (like Claude Desktop or IDEs) that initiate connections + Clients maintain 1:1 connections with servers, inside the host application + Servers provide context, tools, and prompts to clients + +Server Process +Server Process + Host (e.g., Claude Desktop) +Transport Layer +Transport Layer +MCP Server +MCP Server +MCP Client +MCP Client +​ +Core components +​ +Protocol layer + +The protocol layer handles message framing, request/response linking, and high-level communication patterns. + +class Protocol { + // Handle incoming requests + setRequestHandler(schema: T, handler: (request: T, extra: RequestHandlerExtra) => Promise): void + + // Handle incoming notifications + setNotificationHandler(schema: T, handler: (notification: T) => Promise): void + + // Send requests and await responses + request(request: Request, schema: T, options?: RequestOptions): Promise + + // Send one-way notifications + notification(notification: Notification): Promise +} + +Key classes include: + + Protocol + Client + Server + +​ +Transport layer + +The transport layer handles the actual communication between clients and servers. MCP supports multiple transport mechanisms: + + Stdio transport + Uses standard input/output for communication + Ideal for local processes + + HTTP with SSE transport + Uses Server-Sent Events for server-to-client messages + HTTP POST for client-to-server messages + +All transports use JSON-RPC 2.0 to exchange messages. See the specification for detailed information about the Model Context Protocol message format. +​ +Message types + +MCP has these main types of messages: + + Requests expect a response from the other side: + +interface Request { + method: string; + params?: { ... }; +} + +Notifications are one-way messages that don’t expect a response: + +interface Notification { + method: string; + params?: { ... }; +} + +Results are successful responses to requests: + +interface Result { + [key: string]: unknown; +} + +Errors indicate that a request failed: + + interface Error { + code: number; + message: string; + data?: unknown; + } + +​ +Connection lifecycle +​ +1. Initialization +ServerClientServerClientConnection ready for useinitialize requestinitialize responseinitialized notification + + Client sends initialize request with protocol version and capabilities + Server responds with its protocol version and capabilities + Client sends initialized notification as acknowledgment + Normal message exchange begins + +​ +2. Message exchange + +After initialization, the following patterns are supported: + + Request-Response: Client or server sends requests, the other responds + Notifications: Either party sends one-way messages + +​ +3. Termination + +Either party can terminate the connection: + + Clean shutdown via close() + Transport disconnection + Error conditions + +​ +Error handling + +MCP defines these standard error codes: + +enum ErrorCode { + // Standard JSON-RPC error codes + ParseError = -32700, + InvalidRequest = -32600, + MethodNotFound = -32601, + InvalidParams = -32602, + InternalError = -32603 +} + +SDKs and applications can define their own error codes above -32000. + +Errors are propagated through: + + Error responses to requests + Error events on transports + Protocol-level error handlers + +​ +Implementation example + +Here’s a basic example of implementing an MCP server: +typescript: + +import { Server } from "@modelcontextprotocol/sdk/server/index.js"; +import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js"; + +const server = new Server({ + name: "example-server", + version: "1.0.0" +}, { + capabilities: { + resources: {} + } +}); + +// Handle requests +server.setRequestHandler(ListResourcesRequestSchema, async () => { + return { + resources: [ + { + uri: "example://resource", + name: "Example Resource" + } + ] + }; +}); + +// Connect transport +const transport = new StdioServerTransport(); +await server.connect(transport); + +​python: + +import asyncio +import mcp.types as types +from mcp.server import Server +from mcp.server.stdio import stdio_server + +app = Server("example-server") + +@app.list_resources() +async def list_resources() -> list[types.Resource]: + return [ + types.Resource( + uri="example://resource", + name="Example Resource" + ) + ] + +async def main(): + async with stdio_server() as streams: + await app.run( + streams[0], + streams[1], + app.create_initialization_options() + ) + +if __name__ == "__main__": + asyncio.run(main) + + +Best practices +​ +Transport selection + + Local communication + Use stdio transport for local processes + Efficient for same-machine communication + Simple process management + + Remote communication + Use SSE for scenarios requiring HTTP compatibility + Consider security implications including authentication and authorization + +​ +Message handling + + Request processing + Validate inputs thoroughly + Use type-safe schemas + Handle errors gracefully + Implement timeouts + + Progress reporting + Use progress tokens for long operations + Report progress incrementally + Include total progress when known + + Error management + Use appropriate error codes + Include helpful error messages + Clean up resources on errors + +​ +Security considerations + + Transport security + Use TLS for remote connections + Validate connection origins + Implement authentication when needed + + Message validation + Validate all incoming messages + Sanitize inputs + Check message size limits + Verify JSON-RPC format + + Resource protection + Implement access controls + Validate resource paths + Monitor resource usage + Rate limit requests + + Error handling + Don’t leak sensitive information + Log security-relevant errors + Implement proper cleanup + Handle DoS scenarios + +​ +Debugging and monitoring + + Logging + Log protocol events + Track message flow + Monitor performance + Record errors + + Diagnostics + Implement health checks + Monitor connection state + Track resource usage + Profile performance + + Testing + Test different transports + Verify error handling + Check edge cases + Load test servers + + +Concepts +Resources + +Expose data and content from your servers to LLMs + +Resources are a core primitive in the Model Context Protocol (MCP) that allow servers to expose data and content that can be read by clients and used as context for LLM interactions. + +Resources are designed to be application-controlled, meaning that the client application can decide how and when they should be used. Different MCP clients may handle resources differently. For example: + + Claude Desktop currently requires users to explicitly select resources before they can be used + Other clients might automatically select resources based on heuristics + Some implementations may even allow the AI model itself to determine which resources to use + +Server authors should be prepared to handle any of these interaction patterns when implementing resource support. In order to expose data to models automatically, server authors should use a model-controlled primitive such as Tools. +​ +Overview + +Resources represent any kind of data that an MCP server wants to make available to clients. This can include: + + File contents + Database records + API responses + Live system data + Screenshots and images + Log files + And more + +Each resource is identified by a unique URI and can contain either text or binary data. +​ +Resource URIs + +Resources are identified using URIs that follow this format: + +[protocol]://[host]/[path] + +For example: + + file:///home/user/documents/report.pdf + postgres://database/customers/schema + screen://localhost/display1 + +The protocol and path structure is defined by the MCP server implementation. Servers can define their own custom URI schemes. +​ +Resource types + +Resources can contain two types of content: +​ +Text resources + +Text resources contain UTF-8 encoded text data. These are suitable for: + + Source code + Configuration files + Log files + JSON/XML data + Plain text + +​ +Binary resources + +Binary resources contain raw binary data encoded in base64. These are suitable for: + + Images + PDFs + Audio files + Video files + Other non-text formats + +​ +Resource discovery + +Clients can discover available resources through two main methods: +​ +Direct resources + +Servers expose a list of concrete resources via the resources/list endpoint. Each resource includes: + +{ + uri: string; // Unique identifier for the resource + name: string; // Human-readable name + description?: string; // Optional description + mimeType?: string; // Optional MIME type +} + +​ +Resource templates + +For dynamic resources, servers can expose URI templates that clients can use to construct valid resource URIs: + +{ + uriTemplate: string; // URI template following RFC 6570 + name: string; // Human-readable name for this type + description?: string; // Optional description + mimeType?: string; // Optional MIME type for all matching resources +} + +​ +Reading resources + +To read a resource, clients make a resources/read request with the resource URI. + +The server responds with a list of resource contents: + +{ + contents: [ + { + uri: string; // The URI of the resource + mimeType?: string; // Optional MIME type + + // One of: + text?: string; // For text resources + blob?: string; // For binary resources (base64 encoded) + } + ] +} + +Servers may return multiple resources in response to one resources/read request. This could be used, for example, to return a list of files inside a directory when the directory is read. +​ +Resource updates + +MCP supports real-time updates for resources through two mechanisms: +​ +List changes + +Servers can notify clients when their list of available resources changes via the notifications/resources/list_changed notification. +​ +Content changes + +Clients can subscribe to updates for specific resources: + + Client sends resources/subscribe with resource URI + Server sends notifications/resources/updated when the resource changes + Client can fetch latest content with resources/read + Client can unsubscribe with resources/unsubscribe + +​ +Example implementation + +Here’s a simple example of implementing resource support in an MCP server: +typescript: + +const server = new Server({ + name: "example-server", + version: "1.0.0" +}, { + capabilities: { + resources: {} + } +}); + +// List available resources +server.setRequestHandler(ListResourcesRequestSchema, async () => { + return { + resources: [ + { + uri: "file:///logs/app.log", + name: "Application Logs", + mimeType: "text/plain" + } + ] + }; +}); + +// Read resource contents +server.setRequestHandler(ReadResourceRequestSchema, async (request) => { + const uri = request.params.uri; + + if (uri === "file:///logs/app.log") { + const logContents = await readLogFile(); + return { + contents: [ + { + uri, + mimeType: "text/plain", + text: logContents + } + ] + }; + } + + throw new Error("Resource not found"); +}); + +python: + +app = Server("example-server") + +@app.list_resources() +async def list_resources() -> list[types.Resource]: + return [ + types.Resource( + uri="file:///logs/app.log", + name="Application Logs", + mimeType="text/plain" + ) + ] + +@app.read_resource() +async def read_resource(uri: AnyUrl) -> str: + if str(uri) == "file:///logs/app.log": + log_contents = await read_log_file() + return log_contents + + raise ValueError("Resource not found") + +# Start server +async with stdio_server() as streams: + await app.run( + streams[0], + streams[1], + app.create_initialization_options() + ) + + +​ +Best practices + +When implementing resource support: + + Use clear, descriptive resource names and URIs + Include helpful descriptions to guide LLM understanding + Set appropriate MIME types when known + Implement resource templates for dynamic content + Use subscriptions for frequently changing resources + Handle errors gracefully with clear error messages + Consider pagination for large resource lists + Cache resource contents when appropriate + Validate URIs before processing + Document your custom URI schemes + +​ +Security considerations + +When exposing resources: + + Validate all resource URIs + Implement appropriate access controls + Sanitize file paths to prevent directory traversal + Be cautious with binary data handling + Consider rate limiting for resource reads + Audit resource access + Encrypt sensitive data in transit + Validate MIME types + Implement timeouts for long-running reads + Handle resource cleanup appropriately + + +Concepts +Prompts + +Create reusable prompt templates and workflows + +Prompts enable servers to define reusable prompt templates and workflows that clients can easily surface to users and LLMs. They provide a powerful way to standardize and share common LLM interactions. + +Prompts are designed to be user-controlled, meaning they are exposed from servers to clients with the intention of the user being able to explicitly select them for use. +​ +Overview + +Prompts in MCP are predefined templates that can: + + Accept dynamic arguments + Include context from resources + Chain multiple interactions + Guide specific workflows + Surface as UI elements (like slash commands) + +​ +Prompt structure + +Each prompt is defined with: + +{ + name: string; // Unique identifier for the prompt + description?: string; // Human-readable description + arguments?: [ // Optional list of arguments + { + name: string; // Argument identifier + description?: string; // Argument description + required?: boolean; // Whether argument is required + } + ] +} + +​ +Discovering prompts + +Clients can discover available prompts through the prompts/list endpoint: + +// Request +{ + method: "prompts/list" +} + +// Response +{ + prompts: [ + { + name: "analyze-code", + description: "Analyze code for potential improvements", + arguments: [ + { + name: "language", + description: "Programming language", + required: true + } + ] + } + ] +} + +​ +Using prompts + +To use a prompt, clients make a prompts/get request: + +// Request +{ + method: "prompts/get", + params: { + name: "analyze-code", + arguments: { + language: "python" + } + } +} + +// Response +{ + description: "Analyze Python code for potential improvements", + messages: [ + { + role: "user", + content: { + type: "text", + text: "Please analyze the following Python code for potential improvements:\n\n```python\ndef calculate_sum(numbers):\n total = 0\n for num in numbers:\n total = total + num\n return total\n\nresult = calculate_sum([1, 2, 3, 4, 5])\nprint(result)\n```" + } + } + ] +} + +​ +Dynamic prompts + +Prompts can be dynamic and include: +​ +Embedded resource context + +{ + "name": "analyze-project", + "description": "Analyze project logs and code", + "arguments": [ + { + "name": "timeframe", + "description": "Time period to analyze logs", + "required": true + }, + { + "name": "fileUri", + "description": "URI of code file to review", + "required": true + } + ] +} + +When handling the prompts/get request: + +{ + "messages": [ + { + "role": "user", + "content": { + "type": "text", + "text": "Analyze these system logs and the code file for any issues:" + } + }, + { + "role": "user", + "content": { + "type": "resource", + "resource": { + "uri": "logs://recent?timeframe=1h", + "text": "[2024-03-14 15:32:11] ERROR: Connection timeout in network.py:127\n[2024-03-14 15:32:15] WARN: Retrying connection (attempt 2/3)\n[2024-03-14 15:32:20] ERROR: Max retries exceeded", + "mimeType": "text/plain" + } + } + }, + { + "role": "user", + "content": { + "type": "resource", + "resource": { + "uri": "file:///path/to/code.py", + "text": "def connect_to_service(timeout=30):\n retries = 3\n for attempt in range(retries):\n try:\n return establish_connection(timeout)\n except TimeoutError:\n if attempt == retries - 1:\n raise\n time.sleep(5)\n\ndef establish_connection(timeout):\n # Connection implementation\n pass", + "mimeType": "text/x-python" + } + } + } + ] +} + +​ +Multi-step workflows + +const debugWorkflow = { + name: "debug-error", + async getMessages(error: string) { + return [ + { + role: "user", + content: { + type: "text", + text: `Here's an error I'm seeing: ${error}` + } + }, + { + role: "assistant", + content: { + type: "text", + text: "I'll help analyze this error. What have you tried so far?" + } + }, + { + role: "user", + content: { + type: "text", + text: "I've tried restarting the service, but the error persists." + } + } + ]; + } +}; + +​ +Example implementation + +Here’s a complete example of implementing prompts in an MCP server: +typescript: + +import { Server } from "@modelcontextprotocol/sdk/server"; +import { + ListPromptsRequestSchema, + GetPromptRequestSchema +} from "@modelcontextprotocol/sdk/types"; + +const PROMPTS = { + "git-commit": { + name: "git-commit", + description: "Generate a Git commit message", + arguments: [ + { + name: "changes", + description: "Git diff or description of changes", + required: true + } + ] + }, + "explain-code": { + name: "explain-code", + description: "Explain how code works", + arguments: [ + { + name: "code", + description: "Code to explain", + required: true + }, + { + name: "language", + description: "Programming language", + required: false + } + ] + } +}; + +const server = new Server({ + name: "example-prompts-server", + version: "1.0.0" +}, { + capabilities: { + prompts: {} + } +}); + +// List available prompts +server.setRequestHandler(ListPromptsRequestSchema, async () => { + return { + prompts: Object.values(PROMPTS) + }; +}); + +// Get specific prompt +server.setRequestHandler(GetPromptRequestSchema, async (request) => { + const prompt = PROMPTS[request.params.name]; + if (!prompt) { + throw new Error(`Prompt not found: ${request.params.name}`); + } + + if (request.params.name === "git-commit") { + return { + messages: [ + { + role: "user", + content: { + type: "text", + text: `Generate a concise but descriptive commit message for these changes:\n\n${request.params.arguments?.changes}` + } + } + ] + }; + } + + if (request.params.name === "explain-code") { + const language = request.params.arguments?.language || "Unknown"; + return { + messages: [ + { + role: "user", + content: { + type: "text", + text: `Explain how this ${language} code works:\n\n${request.params.arguments?.code}` + } + } + ] + }; + } + + throw new Error("Prompt implementation not found"); +}); + +​python: + +from mcp.server import Server +import mcp.types as types + +# Define available prompts +PROMPTS = { + "git-commit": types.Prompt( + name="git-commit", + description="Generate a Git commit message", + arguments=[ + types.PromptArgument( + name="changes", + description="Git diff or description of changes", + required=True + ) + ], + ), + "explain-code": types.Prompt( + name="explain-code", + description="Explain how code works", + arguments=[ + types.PromptArgument( + name="code", + description="Code to explain", + required=True + ), + types.PromptArgument( + name="language", + description="Programming language", + required=False + ) + ], + ) +} + +# Initialize server +app = Server("example-prompts-server") + +@app.list_prompts() +async def list_prompts() -> list[types.Prompt]: + return list(PROMPTS.values()) + +@app.get_prompt() +async def get_prompt( + name: str, arguments: dict[str, str] | None = None +) -> types.GetPromptResult: + if name not in PROMPTS: + raise ValueError(f"Prompt not found: {name}") + + if name == "git-commit": + changes = arguments.get("changes") if arguments else "" + return types.GetPromptResult( + messages=[ + types.PromptMessage( + role="user", + content=types.TextContent( + type="text", + text=f"Generate a concise but descriptive commit Here’s a simple example of implementing resource support in an MCP server " + f"for these changes:\n\n{changes}" + ) + ) + ] + ) + + if name == "explain-code": + code = arguments.get("code") if arguments else "" + language = arguments.get("language", "Unknown") if arguments else "Unknown" + return types.GetPromptResult( + messages=[ + types.PromptMessage( + role="user", + content=types.TextContent( + type="text", + text=f"Explain how this {language} code works:\n\n{code}" + ) + ) + ] + ) + + raise ValueError("Prompt implementation not found") + + +Best practices + +When implementing prompts: + + Use clear, descriptive prompt names + Provide detailed descriptions for prompts and arguments + Validate all required arguments + Handle missing arguments gracefully + Consider versioning for prompt templates + Cache dynamic content when appropriate + Implement error handling + Document expected argument formats + Consider prompt composability + Test prompts with various inputs + +​ +UI integration + +Prompts can be surfaced in client UIs as: + + Slash commands + Quick actions + Context menu items + Command palette entries + Guided workflows + Interactive forms +Updates and changes + +Servers can notify clients about prompt changes: + + Server capability: prompts.listChanged + Notification: notifications/prompts/list_changed + Client re-fetches prompt list + +​ +Security considerations + +When implementing prompts: + + Validate all arguments + Sanitize user input + Consider rate limiting + Implement access controls + Audit prompt usage + Handle sensitive data appropriately + Validate generated content + Implement timeouts + Consider prompt injection risks + Document security requirements + +Concepts +Tools + +Enable LLMs to perform actions through your server + +Tools are a powerful primitive in the Model Context Protocol (MCP) that enable servers to expose executable functionality to clients. Through tools, LLMs can interact with external systems, perform computations, and take actions in the real world. + +Tools are designed to be model-controlled, meaning that tools are exposed from servers to clients with the intention of the AI model being able to automatically invoke them (with a human in the loop to grant approval). +​ +Overview + +Tools in MCP allow servers to expose executable functions that can be invoked by clients and used by LLMs to perform actions. Key aspects of tools include: + + Discovery: Clients can list available tools through the tools/list endpoint + Invocation: Tools are called using the tools/call endpoint, where servers perform the requested operation and return results + Flexibility: Tools can range from simple calculations to complex API interactions + +Like resources, tools are identified by unique names and can include descriptions to guide their usage. However, unlike resources, tools represent dynamic operations that can modify state or interact with external systems. +​ +Tool definition structure + +Each tool is defined with the following structure: + +{ + name: string; // Unique identifier for the tool + description?: string; // Human-readable description + inputSchema: { // JSON Schema for the tool's parameters + type: "object", + properties: { ... } // Tool-specific parameters + } +} + +​ +Implementing tools + +Here’s an example of implementing a basic tool in an MCP server: + +typescript: + +const server = new Server({ + name: "example-server", + version: "1.0.0" +}, { + capabilities: { + tools: {} + } +}); + +// Define available tools +server.setRequestHandler(ListToolsRequestSchema, async () => { + return { + tools: [{ + name: "calculate_sum", + description: "Add two numbers together", + inputSchema: { + type: "object", + properties: { + a: { type: "number" }, + b: { type: "number" } + }, + required: ["a", "b"] + } + }] + }; +}); + +// Handle tool execution +server.setRequestHandler(CallToolRequestSchema, async (request) => { + if (request.params.name === "calculate_sum") { + const { a, b } = request.params.arguments; + return { + toolResult: a + b + }; + } + throw new Error("Tool not found"); +}); + +​python: + +app = Server("example-server") + +@app.list_tools() +async def list_tools() -> list[types.Tool]: + return [ + types.Tool( + name="calculate_sum", + description="Add two numbers together", + inputSchema={ + "type": "object", + "properties": { + "a": {"type": "number"}, + "b": {"type": "number"} + }, + "required": ["a", "b"] + } + ) + ] + +@app.call_tool() +async def call_tool( + name: str, + arguments: dict +) -> list[types.TextContent | types.ImageContent | types.EmbeddedResource]: + if name == "calculate_sum": + a = arguments["a"] + b = arguments["b"] + result = a + b + return [types.TextContent(type="text", text=str(result))] + raise ValueError(f"Tool not found: {name}") + + + +Example tool patterns + +Here are some examples of types of tools that a server could provide: +​ +System operations + +Tools that interact with the local system: + +{ + name: "execute_command", + description: "Run a shell command", + inputSchema: { + type: "object", + properties: { + command: { type: "string" }, + args: { type: "array", items: { type: "string" } } + } + } +} + +​ +API integrations + +Tools that wrap external APIs: + +{ + name: "github_create_issue", + description: "Create a GitHub issue", + inputSchema: { + type: "object", + properties: { + title: { type: "string" }, + body: { type: "string" }, + labels: { type: "array", items: { type: "string" } } + } + } +} + +​ +Data processing + +Tools that transform or analyze data: + +{ + name: "analyze_csv", + description: "Analyze a CSV file", + inputSchema: { + type: "object", + properties: { + filepath: { type: "string" }, + operations: { + type: "array", + items: { + enum: ["sum", "average", "count"] + } + } + } + } +} + +​ +Best practices + +When implementing tools: + + Provide clear, descriptive names and descriptions + Use detailed JSON Schema definitions for parameters + Include examples in tool descriptions to demonstrate how the model should use them + Implement proper error handling and validation + Use progress reporting for long operations + Keep tool operations focused and atomic + Document expected return value structures + Implement proper timeouts + Consider rate limiting for resource-intensive operations + Log tool usage for debugging and monitoring + +​ +Security considerations + +When exposing tools: +​ +Input validation + + Validate all parameters against the schema + Sanitize file paths and system commands + Validate URLs and external identifiers + Check parameter sizes and ranges + Prevent command injection + +​ +Access control + + Implement authentication where needed + Use appropriate authorization checks + Audit tool usage + Rate limit requests + Monitor for abuse + +​ +Error handling + + Don’t expose internal errors to clients + Log security-relevant errors + Handle timeouts appropriately + Clean up resources after errors + Validate return values + +​ +Tool discovery and updates + +MCP supports dynamic tool discovery: + + Clients can list available tools at any time + Servers can notify clients when tools change using notifications/tools/list_changed + Tools can be added or removed during runtime + Tool definitions can be updated (though this should be done carefully) + +​ +Error handling + +Tool errors should be reported within the result object, not as MCP protocol-level errors. This allows the LLM to see and potentially handle the error. When a tool encounters an error: + + Set isError to true in the result + Include error details in the content array + +Here’s an example of proper error handling for tools: + +typescript: + +try { + // Tool operation + const result = performOperation(); + return { + content: [ + { + type: "text", + text: `Operation successful: ${result}` + } + ] + }; +} catch (error) { + return { + isError: true, + content: [ + { + type: "text", + text: `Error: ${error.message}` + } + ] + }; +} + +python: +try: + # Tool operation + result = perform_operation() + return types.CallToolResult( + content=[ + types.TextContent( + type="text", + text=f"Operation successful: {result}" + ) + ] + ) +except Exception as error: + return types.CallToolResult( + isError=True, + content=[ + types.TextContent( + type="text", + text=f"Error: {str(error)}" + ) + ] + ) + + +This approach allows the LLM to see that an error occurred and potentially take corrective action or request human intervention. +​ +Testing tools + +A comprehensive testing strategy for MCP tools should cover: + + Functional testing: Verify tools execute correctly with valid inputs and handle invalid inputs appropriately + Integration testing: Test tool interaction with external systems using both real and mocked dependencies + Security testing: Validate authentication, authorization, input sanitization, and rate limiting + Performance testing: Check behavior under load, timeout handling, and resource cleanup + Error handling: Ensure tools properly report errors through the MCP protocol and clean up resources + +Troubleshooting + +Getting logs from Claude for Desktop + +Claude.app logging related to MCP is written to log files in ~/Library/Logs/Claude: + + mcp.log will contain general logging about MCP connections and connection failures. + Files named mcp-server-SERVERNAME.log will contain error (stderr) logging from the named server. + +You can run the following command to list recent logs and follow along with any new ones: + +# Check Claude's logs for errors +tail -n 20 -f ~/Library/Logs/Claude/mcp*.log + +Server not showing up in Claude + + Check your desktop_config.json file syntax + Make sure the path to your project is absolute and not relative + Restart Claude for Desktop completely + +Tool calls failing silently + +If Claude attempts to use the tools but they fail: + + Check Claude’s logs for errors + Verify your server builds and runs without errors + Try restarting Claude for Desktop + +None of this is working. What do I do? + +Please refer to our debugging guide for better debugging tools and more detailed guidance. + +Error: Failed to retrieve grid point data + +This usually means either: + + The coordinates are outside the US + The NWS API is having issues + You’re being rate limited + +Fix: + + Verify you’re using US coordinates + Add a small delay between requests + Check the NWS API status page + +Error: No active alerts for [STATE] + +This isn’t an error - it just means there are no current weather alerts for that state. Try a different state or check during severe weather. + + diff --git a/MCPspecification.txt b/MCPspecification.txt new file mode 100644 index 0000000..f9fa47b --- /dev/null +++ b/MCPspecification.txt @@ -0,0 +1,2301 @@ +Specification +Architecture +Architecture + +The Model Context Protocol (MCP) follows a client-host-server architecture where each host can run multiple client instances. This architecture enables users to integrate AI capabilities across applications while maintaining clear security boundaries and isolating concerns. Built on JSON-RPC, MCP provides a stateful session protocol focused on context exchange and sampling coordination between clients and servers. +Core Components + +Internet + +Local machine + +Application Host Process + +Server 3 +External APIs + +Remote +Resource C + +Server 1 +Files & Git + +Server 2 +Database + +Local +Resource A + +Local +Resource B + +Host + +Client 1 + +Client 2 + +Client 3 + +Host + +The host process acts as the container and coordinator: + + Creates and manages multiple client instances + Controls client connection permissions and lifecycle + Enforces security policies and consent requirements + Handles user authorization decisions + Coordinates AI/LLM integration and sampling + Manages context aggregation across clients + +Clients + +Each client is created by the host and maintains an isolated server connection: + + Establishes one stateful session per server + Handles protocol negotiation and capability exchange + Routes protocol messages bidirectionally + Manages subscriptions and notifications + Maintains security boundaries between servers + +A host application creates and manages multiple clients, with each client having a 1:1 relationship with a particular server. +Servers + +Servers provide specialized context and capabilities: + + Expose resources, tools and prompts via MCP primitives + Operate independently with focused responsibilities + Request sampling through client interfaces + Must respect security constraints + Can be local processes or remote services + +Design Principles + +MCP is built on several key design principles that inform its architecture and implementation: + + Servers should be extremely easy to build + Host applications handle complex orchestration responsibilities + Servers focus on specific, well-defined capabilities + Simple interfaces minimize implementation overhead + Clear separation enables maintainable code + + Servers should be highly composable + Each server provides focused functionality in isolation + Multiple servers can be combined seamlessly + Shared protocol enables interoperability + Modular design supports extensibility + + Servers should not be able to read the whole conversation, nor “see into” other servers + Servers receive only necessary contextual information + Full conversation history stays with the host + Each server connection maintains isolation + Cross-server interactions are controlled by the host + Host process enforces security boundaries + + Features can be added to servers and clients progressively + Core protocol provides minimal required functionality + Additional capabilities can be negotiated as needed + Servers and clients evolve independently + Protocol designed for future extensibility + Backwards compatibility is maintained + +Message Types + +MCP defines three core message types based on JSON-RPC 2.0: + + Requests: Bidirectional messages with method and parameters expecting a response + Responses: Successful results or errors matching specific request IDs + Notifications: One-way messages requiring no response + +Each message type follows the JSON-RPC 2.0 specification for structure and delivery semantics. +Capability Negotiation + +The Model Context Protocol uses a capability-based negotiation system where clients and servers explicitly declare their supported features during initialization. Capabilities determine which protocol features and primitives are available during a session. + + Servers declare capabilities like resource subscriptions, tool support, and prompt templates + Clients declare capabilities like sampling support and notification handling + Both parties must respect declared capabilities throughout the session + Additional capabilities can be negotiated through extensions to the protocol + +Server + +Client + +Host + +Server + +Client + +Host + +Active Session with Negotiated Features + +loop[Client Requests] + +loop[Server Requests] + +loop[Notifications]Initialize client + +Initialize session with capabilities + +Respond with supported capabilities + +User- or model-initiated action + +Request (tools/resources) + +Response + +Update UI or respond to model + +Request (sampling) + +Forward to AI + +AI response + +Response + +Resource updates + +Status changes + +Terminate + +End session + +Each capability unlocks specific protocol features for use during the session. For example: + + Implemented server features must be advertised in the server’s capabilities + Emitting resource subscription notifications requires the server to declare subscription support + Tool invocation requires the server to declare tool capabilities + Sampling requires the client to declare support in its capabilities + +This capability negotiation ensures clients and servers have a clear understanding of supported functionality while maintaining protocol extensibility. + +Base Protocol +Protocol Revision: 2024-11-05 + +All messages between MCP clients and servers MUST follow the JSON-RPC 2.0 specification. The protocol defines three fundamental types of messages: +Type Description Requirements +Requests Messages sent to initiate an operation Must include unique ID and method name +Responses Messages sent in reply to requests Must include same ID as request +Notifications One-way messages with no reply Must not include an ID + +Responses are further sub-categorized as either successful results or errors. Results can follow any JSON object structure, while errors must include an error code and message at minimum. +Protocol Layers + +The Model Context Protocol consists of several key components that work together: + + Base Protocol: Core JSON-RPC message types + Lifecycle Management: Connection initialization, capability negotiation, and session control + Server Features: Resources, prompts, and tools exposed by servers + Client Features: Sampling and root directory lists provided by clients + Utilities: Cross-cutting concerns like logging and argument completion + +All implementations MUST support the base protocol and lifecycle management components. Other components MAY be implemented based on the specific needs of the application. + +These protocol layers establish clear separation of concerns while enabling rich interactions between clients and servers. The modular design allows implementations to support exactly the features they need. + +See the following pages for more details on the different components: +Lifecycle +Resources +Prompts +Tools +Logging +Sampling +Auth + +Authentication and authorization are not currently part of the core MCP specification, but we are considering ways to introduce them in future. Join us in GitHub Discussions to help shape the future of the protocol! + +Clients and servers MAY negotiate their own custom authentication and authorization strategies. +Schema + +The full specification of the protocol is defined as a TypeScript schema. This is the source of truth for all protocol messages and structures. + +There is also a JSON Schema, which is automatically generated from the TypeScript source of truth, for use with various automated tooling. + +Specification +Base Protocol +Base Protocol +Protocol Revision: 2024-11-05 + +All messages between MCP clients and servers MUST follow the JSON-RPC 2.0 specification. The protocol defines three fundamental types of messages: +Type Description Requirements +Requests Messages sent to initiate an operation Must include unique ID and method name +Responses Messages sent in reply to requests Must include same ID as request +Notifications One-way messages with no reply Must not include an ID + +Responses are further sub-categorized as either successful results or errors. Results can follow any JSON object structure, while errors must include an error code and message at minimum. +Protocol Layers + +The Model Context Protocol consists of several key components that work together: + + Base Protocol: Core JSON-RPC message types + Lifecycle Management: Connection initialization, capability negotiation, and session control + Server Features: Resources, prompts, and tools exposed by servers + Client Features: Sampling and root directory lists provided by clients + Utilities: Cross-cutting concerns like logging and argument completion + +All implementations MUST support the base protocol and lifecycle management components. Other components MAY be implemented based on the specific needs of the application. + +These protocol layers establish clear separation of concerns while enabling rich interactions between clients and servers. The modular design allows implementations to support exactly the features they need. + +See the following pages for more details on the different components: +Lifecycle +Resources +Prompts +Tools +Logging +Sampling +Auth + +Authentication and authorization are not currently part of the core MCP specification, but we are considering ways to introduce them in future. Join us in GitHub Discussions to help shape the future of the protocol! + +Clients and servers MAY negotiate their own custom authentication and authorization strategies. +Schema + +The full specification of the protocol is defined as a TypeScript schema. This is the source of truth for all protocol messages and structures. + +There is also a JSON Schema, which is automatically generated from the TypeScript source of truth, for use with various automated tooling. + +Specification +Base Protocol +Messages +Messages +Protocol Revision: 2024-11-05 + +All messages in MCP MUST follow the JSON-RPC 2.0 specification. The protocol defines three types of messages: +Requests + +Requests are sent from the client to the server or vice versa. + +{ + jsonrpc: "2.0"; + id: string | number; + method: string; + params?: { + [key: string]: unknown; + }; +} + + Requests MUST include a string or integer ID. + Unlike base JSON-RPC, the ID MUST NOT be null. + The request ID MUST NOT have been previously used by the requestor within the same session. + +Responses + +Responses are sent in reply to requests. + +{ + jsonrpc: "2.0"; + id: string | number; + result?: { + [key: string]: unknown; + } + error?: { + code: number; + message: string; + data?: unknown; + } +} + + Responses MUST include the same ID as the request they correspond to. + Either a result or an error MUST be set. A response MUST NOT set both. + Error codes MUST be integers. + +Notifications + +Notifications are sent from the client to the server or vice versa. They do not expect a response. + +{ + jsonrpc: "2.0"; + method: string; + params?: { + [key: string]: unknown; + }; +} + + Notifications MUST NOT include an ID. + + Specification +Base Protocol +Lifecycle +Lifecycle +Protocol Revision: 2024-11-05 + +The Model Context Protocol (MCP) defines a rigorous lifecycle for client-server connections that ensures proper capability negotiation and state management. + + Initialization: Capability negotiation and protocol version agreement + Operation: Normal protocol communication + Shutdown: Graceful termination of the connection + +Server + +Client + +Server + +Client + +Initialization Phase + +Operation Phase + +Normal protocol operations + +Shutdown + +Connection closedinitialize request + +initialize response + +initialized notification + +Disconnect + +Lifecycle Phases +Initialization + +The initialization phase MUST be the first interaction between client and server. During this phase, the client and server: + + Establish protocol version compatibility + Exchange and negotiate capabilities + Share implementation details + +The client MUST initiate this phase by sending an initialize request containing: + + Protocol version supported + Client capabilities + Client implementation information + +{ + "jsonrpc": "2.0", + "id": 1, + "method": "initialize", + "params": { + "protocolVersion": "2024-11-05", + "capabilities": { + "roots": { + "listChanged": true + }, + "sampling": {} + }, + "clientInfo": { + "name": "ExampleClient", + "version": "1.0.0" + } + } +} + +The server MUST respond with its own capabilities and information: + +{ + "jsonrpc": "2.0", + "id": 1, + "result": { + "protocolVersion": "2024-11-05", + "capabilities": { + "logging": {}, + "prompts": { + "listChanged": true + }, + "resources": { + "subscribe": true, + "listChanged": true + }, + "tools": { + "listChanged": true + } + }, + "serverInfo": { + "name": "ExampleServer", + "version": "1.0.0" + } + } +} + +After successful initialization, the client MUST send an initialized notification to indicate it is ready to begin normal operations: + +{ + "jsonrpc": "2.0", + "method": "notifications/initialized" +} + + The client SHOULD NOT send requests other than pings before the server has responded to the initialize request. + The server SHOULD NOT send requests other than pings and logging before receiving the initialized notification. + +Version Negotiation + +In the initialize request, the client MUST send a protocol version it supports. This SHOULD be the latest version supported by the client. + +If the server supports the requested protocol version, it MUST respond with the same version. Otherwise, the server MUST respond with another protocol version it supports. This SHOULD be the latest version supported by the server. + +If the client does not support the version in the server’s response, it SHOULD disconnect. +Capability Negotiation + +Client and server capabilities establish which optional protocol features will be available during the session. + +Key capabilities include: +Category Capability Description +Client roots Ability to provide filesystem roots +Client sampling Support for LLM sampling requests +Client experimental Describes support for non-standard experimental features +Server prompts Offers prompt templates +Server resources Provides readable resources +Server tools Exposes callable tools +Server logging Emits structured log messages +Server experimental Describes support for non-standard experimental features + +Capability objects can describe sub-capabilities like: + + listChanged: Support for list change notifications (for prompts, resources, and tools) + subscribe: Support for subscribing to individual items’ changes (resources only) + +Operation + +During the operation phase, the client and server exchange messages according to the negotiated capabilities. + +Both parties SHOULD: + + Respect the negotiated protocol version + Only use capabilities that were successfully negotiated + +Shutdown + +During the shutdown phase, one side (usually the client) cleanly terminates the protocol connection. No specific shutdown messages are defined—instead, the underlying transport mechanism should be used to signal connection termination: +stdio + +For the stdio transport, the client SHOULD initiate shutdown by: + + First, closing the input stream to the child process (the server) + Waiting for the server to exit, or sending SIGTERM if the server does not exit within a reasonable time + Sending SIGKILL if the server does not exit within a reasonable time after SIGTERM + +The server MAY initiate shutdown by closing its output stream to the client and exiting. +HTTP + +For HTTP transports, shutdown is indicated by closing the associated HTTP connection(s). +Error Handling + +Implementations SHOULD be prepared to handle these error cases: + + Protocol version mismatch + Failure to negotiate required capabilities + Initialize request timeout + Shutdown timeout + +Implementations SHOULD implement appropriate timeouts for all requests, to prevent hung connections and resource exhaustion. + +Example initialization error: + +{ + "jsonrpc": "2.0", + "id": 1, + "error": { + "code": -32602, + "message": "Unsupported protocol version", + "data": { + "supported": ["2024-11-05"], + "requested": "1.0.0" + } + } +} + +Transports +Protocol Revision: 2024-11-05 + +MCP currently defines two standard transport mechanisms for client-server communication: + + stdio, communication over standard in and standard out + HTTP with Server-Sent Events (SSE) + +Clients SHOULD support stdio whenever possible. + +It is also possible for clients and servers to implement custom transports in a pluggable fashion. +stdio + +In the stdio transport: + + The client launches the MCP server as a subprocess. + The server receives JSON-RPC messages on its standard input (stdin) and writes responses to its standard output (stdout). + Messages are delimited by newlines, and MUST NOT contain embedded newlines. + The server MAY write UTF-8 strings to its standard error (stderr) for logging purposes. Clients MAY capture, forward, or ignore this logging. + The server MUST NOT write anything to its stdout that is not a valid MCP message. + The client MUST NOT write anything to the server’s stdin that is not a valid MCP message. + +Server Process + +Client + +Server Process + +Client + +loop[Message Exchange]Launch subprocess + +Write to stdin + +Write to stdout + +Optional logs on stderr + +Close stdin, terminate subprocess + +HTTP with SSE + +In the SSE transport, the server operates as an independent process that can handle multiple client connections. + +The server MUST provide two endpoints: + + An SSE endpoint, for clients to establish a connection and receive messages from the server + A regular HTTP POST endpoint for clients to send messages to the server + +When a client connects, the server MUST send an endpoint event containing a URI for the client to use for sending messages. All subsequent client messages MUST be sent as HTTP POST requests to this endpoint. + +Server messages are sent as SSE message events, with the message content encoded as JSON in the event data. + +Server + +Client + +Server + +Client + +loop[Message Exchange]Open SSE connection + +endpoint event + +HTTP POST messages + +SSE message events + +Close SSE connection + +Custom Transports + +Clients and servers MAY implement additional custom transport mechanisms to suit their specific needs. The protocol is transport-agnostic and can be implemented over any communication channel that supports bidirectional message exchange. + +Implementers who choose to support custom transports MUST ensure they preserve the JSON-RPC message format and lifecycle requirements defined by MCP. Custom transports SHOULD document their specific connection establishment and message exchange patterns to aid interoperability. + +Versioning + +The Model Context Protocol uses string-based version identifiers following the format YYYY-MM-DD, to indicate the last date backwards incompatible changes were made. + +The current protocol version is 2024-11-05. See all revisions. +The protocol version will not be incremented when the protocol is updated, as long as the changes maintain backwards compatibility. This allows for incremental improvements while preserving interoperability. + +Version negotiation happens during initialization. Clients and servers MAY support multiple protocol versions simultaneously, but they MUST agree on a single version to use for the session. + +The protocol provides appropriate error handling if version negotiation fails, allowing clients to gracefully terminate connections when they cannot find a version compatible with the server. + +Utilities +Protocol Revision: 2024-11-05 + +These optional features enhance the base protocol functionality with various utilities. +Ping +Cancellation +Progress + +Ping +Protocol Revision: 2024-11-05 + +The Model Context Protocol includes an optional ping mechanism that allows either party to verify that their counterpart is still responsive and the connection is alive. +Overview + +The ping functionality is implemented through a simple request/response pattern. Either the client or server can initiate a ping by sending a ping request. +Message Format + +A ping request is a standard JSON-RPC request with no parameters: + +{ + "jsonrpc": "2.0", + "id": "123", + "method": "ping" +} + +Behavior Requirements + + The receiver MUST respond promptly with an empty response: + +{ + "jsonrpc": "2.0", + "id": "123", + "result": {} +} + + If no response is received within a reasonable timeout period, the sender MAY: + Consider the connection stale + Terminate the connection + Attempt reconnection procedures + +Usage Patterns + +Receiver + +Sender + +Receiver + +Sender + +ping request + +empty response + +Implementation Considerations + + Implementations SHOULD periodically issue pings to detect connection health + The frequency of pings SHOULD be configurable + Timeouts SHOULD be appropriate for the network environment + Excessive pinging SHOULD be avoided to reduce network overhead + +Error Handling + + Timeouts SHOULD be treated as connection failures + Multiple failed pings MAY trigger connection reset + Implementations SHOULD log ping failures for diagnostics + + Cancellation +Protocol Revision: 2024-11-05 + +The Model Context Protocol (MCP) supports optional cancellation of in-progress requests through notification messages. Either side can send a cancellation notification to indicate that a previously-issued request should be terminated. +Cancellation Flow + +When a party wants to cancel an in-progress request, it sends a notifications/cancelled notification containing: + + The ID of the request to cancel + An optional reason string that can be logged or displayed + +{ + "jsonrpc": "2.0", + "method": "notifications/cancelled", + "params": { + "requestId": "123", + "reason": "User requested cancellation" + } +} + +Behavior Requirements + + Cancellation notifications MUST only reference requests that: + Were previously issued in the same direction + Are believed to still be in-progress + The initialize request MUST NOT be cancelled by clients + Receivers of cancellation notifications SHOULD: + Stop processing the cancelled request + Free associated resources + Not send a response for the cancelled request + Receivers MAY ignore cancellation notifications if: + The referenced request is unknown + Processing has already completed + The request cannot be cancelled + The sender of the cancellation notification SHOULD ignore any response to the request that arrives afterward + +Timing Considerations + +Due to network latency, cancellation notifications may arrive after request processing has completed, and potentially after a response has already been sent. + +Both parties MUST handle these race conditions gracefully: + +Server + +Client + +Server + +Client + +Processing starts + +Processing may havecompleted beforecancellation arrives + +Stop processing + +alt​[If notcompleted]Request (ID: 123) + +notifications/cancelled (ID: 123) + +Implementation Notes + + Both parties SHOULD log cancellation reasons for debugging + Application UIs SHOULD indicate when cancellation is requested + +Error Handling + +Invalid cancellation notifications SHOULD be ignored: + + Unknown request IDs + Already completed requests + Malformed notifications + +This maintains the “fire and forget” nature of notifications while allowing for race conditions in asynchronous communication. + +Progress +Protocol Revision: 2024-11-05 + +The Model Context Protocol (MCP) supports optional progress tracking for long-running operations through notification messages. Either side can send progress notifications to provide updates about operation status. +Progress Flow + +When a party wants to receive progress updates for a request, it includes a progressToken in the request metadata. + + Progress tokens MUST be a string or integer value + Progress tokens can be chosen by the sender using any means, but MUST be unique across all active requests. + +{ + "jsonrpc": "2.0", + "id": 1, + "method": "some_method", + "params": { + "_meta": { + "progressToken": "abc123" + } + } +} + +The receiver MAY then send progress notifications containing: + + The original progress token + The current progress value so far + An optional “total” value + +{ + "jsonrpc": "2.0", + "method": "notifications/progress", + "params": { + "progressToken": "abc123", + "progress": 50, + "total": 100 + } +} + + The progress value MUST increase with each notification, even if the total is unknown. + The progress and the total values MAY be floating point. + +Behavior Requirements + + Progress notifications MUST only reference tokens that: + Were provided in an active request + Are associated with an in-progress operation + + Receivers of progress requests MAY: + Choose not to send any progress notifications + Send notifications at whatever frequency they deem appropriate + Omit the total value if unknown + +Receiver + +Sender + +Receiver + +Sender + +Request with progress token + +Progress updates + +loop[Progress Updates] + +Operation completeMethod request with progressToken + +Progress notification (0.2/1.0) + +Progress notification (0.6/1.0) + +Progress notification (1.0/1.0) + +Method response + +Implementation Notes + + Senders and receivers SHOULD track active progress tokens + Both parties SHOULD implement rate limiting to prevent flooding + Progress notifications MUST stop after completion + + Server Features +Protocol Revision: 2024-11-05 + +Servers provide the fundamental building blocks for adding context to language models via MCP. These primitives enable rich interactions between clients, servers, and language models: + + Prompts: Pre-defined templates or instructions that guide language model interactions + Resources: Structured data or content that provides additional context to the model + Tools: Executable functions that allow models to perform actions or retrieve information + +Each primitive can be summarized in the following control hierarchy: +Primitive Control Description Example +Prompts User-controlled Interactive templates invoked by user choice Slash commands, menu options +Resources Application-controlled Contextual data attached and managed by the client File contents, git history +Tools Model-controlled Functions exposed to the LLM to take actions API POST requests, file writing + +Explore these key primitives in more detail below: +Prompts +Resources +Tools + +Prompts +Protocol Revision: 2024-11-05 + +The Model Context Protocol (MCP) provides a standardized way for servers to expose prompt templates to clients. Prompts allow servers to provide structured messages and instructions for interacting with language models. Clients can discover available prompts, retrieve their contents, and provide arguments to customize them. +User Interaction Model + +Prompts are designed to be user-controlled, meaning they are exposed from servers to clients with the intention of the user being able to explicitly select them for use. + +Typically, prompts would be triggered through user-initiated commands in the user interface, which allows users to naturally discover and invoke available prompts. + +For example, as slash commands: + +Example of prompt exposed as slash command + +However, implementors are free to expose prompts through any interface pattern that suits their needs—the protocol itself does not mandate any specific user interaction model. +Capabilities + +Servers that support prompts MUST declare the prompts capability during initialization: + +{ + "capabilities": { + "prompts": { + "listChanged": true + } + } +} + +listChanged indicates whether the server will emit notifications when the list of available prompts changes. +Protocol Messages +Listing Prompts + +To retrieve available prompts, clients send a prompts/list request. This operation supports pagination. + +Request: + +{ + "jsonrpc": "2.0", + "id": 1, + "method": "prompts/list", + "params": { + "cursor": "optional-cursor-value" + } +} + +Response: + +{ + "jsonrpc": "2.0", + "id": 1, + "result": { + "prompts": [ + { + "name": "code_review", + "description": "Asks the LLM to analyze code quality and suggest improvements", + "arguments": [ + { + "name": "code", + "description": "The code to review", + "required": true + } + ] + } + ], + "nextCursor": "next-page-cursor" + } +} + +Getting a Prompt + +To retrieve a specific prompt, clients send a prompts/get request. Arguments may be auto-completed through the completion API. + +Request: + +{ + "jsonrpc": "2.0", + "id": 2, + "method": "prompts/get", + "params": { + "name": "code_review", + "arguments": { + "code": "def hello():\n print('world')" + } + } +} + +Response: + +{ + "jsonrpc": "2.0", + "id": 2, + "result": { + "description": "Code review prompt", + "messages": [ + { + "role": "user", + "content": { + "type": "text", + "text": "Please review this Python code:\ndef hello():\n print('world')" + } + } + ] + } +} + +List Changed Notification + +When the list of available prompts changes, servers that declared the listChanged capability SHOULD send a notification: + +{ + "jsonrpc": "2.0", + "method": "notifications/prompts/list_changed" +} + +Message Flow + +Server + +Client + +Server + +Client + +Discovery + +Usage + +Changes + +opt[listChanged]prompts/list + +List of prompts + +prompts/get + +Prompt content + +prompts/list_changed + +prompts/list + +Updated prompts + +Data Types +Prompt + +A prompt definition includes: + + name: Unique identifier for the prompt + description: Optional human-readable description + arguments: Optional list of arguments for customization + +PromptMessage + +Messages in a prompt can contain: + + role: Either “user” or “assistant” to indicate the speaker + content: One of the following content types: + +Text Content + +Text content represents plain text messages: + +{ + "type": "text", + "text": "The text content of the message" +} + +This is the most common content type used for natural language interactions. +Image Content + +Image content allows including visual information in messages: + +{ + "type": "image", + "data": "base64-encoded-image-data", + "mimeType": "image/png" +} + +The image data MUST be base64-encoded and include a valid MIME type. This enables multi-modal interactions where visual context is important. +Embedded Resources + +Embedded resources allow referencing server-side resources directly in messages: + +{ + "type": "resource", + "resource": { + "uri": "resource://example", + "mimeType": "text/plain", + "text": "Resource content" + } +} + +Resources can contain either text or binary (blob) data and MUST include: + + A valid resource URI + The appropriate MIME type + Either text content or base64-encoded blob data + +Embedded resources enable prompts to seamlessly incorporate server-managed content like documentation, code samples, or other reference materials directly into the conversation flow. +Error Handling + +Servers SHOULD return standard JSON-RPC errors for common failure cases: + + Invalid prompt name: -32602 (Invalid params) + Missing required arguments: -32602 (Invalid params) + Internal errors: -32603 (Internal error) + +Implementation Considerations + + Servers SHOULD validate prompt arguments before processing + Clients SHOULD handle pagination for large prompt lists + Both parties SHOULD respect capability negotiation + +Security + +Implementations MUST carefully validate all prompt inputs and outputs to prevent injection attacks or unauthorized access to resources. + + +Resources +Protocol Revision: 2024-11-05 + +The Model Context Protocol (MCP) provides a standardized way for servers to expose resources to clients. Resources allow servers to share data that provides context to language models, such as files, database schemas, or application-specific information. Each resource is uniquely identified by a URI. +User Interaction Model + +Resources in MCP are designed to be application-driven, with host applications determining how to incorporate context based on their needs. + +For example, applications could: + + Expose resources through UI elements for explicit selection, in a tree or list view + Allow the user to search through and filter available resources + Implement automatic context inclusion, based on heuristics or the AI model’s selection + +Example of resource context picker + +However, implementations are free to expose resources through any interface pattern that suits their needs—the protocol itself does not mandate any specific user interaction model. +Capabilities + +Servers that support resources MUST declare the resources capability: + +{ + "capabilities": { + "resources": { + "subscribe": true, + "listChanged": true + } + } +} + +The capability supports two optional features: + + subscribe: whether the client can subscribe to be notified of changes to individual resources. + listChanged: whether the server will emit notifications when the list of available resources changes. + +Both subscribe and listChanged are optional—servers can support neither, either, or both: + +{ + "capabilities": { + "resources": {} // Neither feature supported + } +} + +{ + "capabilities": { + "resources": { + "subscribe": true // Only subscriptions supported + } + } +} + +{ + "capabilities": { + "resources": { + "listChanged": true // Only list change notifications supported + } + } +} + +Protocol Messages +Listing Resources + +To discover available resources, clients send a resources/list request. This operation supports pagination. + +Request: + +{ + "jsonrpc": "2.0", + "id": 1, + "method": "resources/list", + "params": { + "cursor": "optional-cursor-value" + } +} + +Response: + +{ + "jsonrpc": "2.0", + "id": 1, + "result": { + "resources": [ + { + "uri": "file:///project/src/main.rs", + "name": "main.rs", + "description": "Primary application entry point", + "mimeType": "text/x-rust" + } + ], + "nextCursor": "next-page-cursor" + } +} + +Reading Resources + +To retrieve resource contents, clients send a resources/read request: + +Request: + +{ + "jsonrpc": "2.0", + "id": 2, + "method": "resources/read", + "params": { + "uri": "file:///project/src/main.rs" + } +} + +Response: + +{ + "jsonrpc": "2.0", + "id": 2, + "result": { + "contents": [ + { + "uri": "file:///project/src/main.rs", + "mimeType": "text/x-rust", + "text": "fn main() {\n println!(\"Hello world!\");\n}" + } + ] + } +} + +Resource Templates + +Resource templates allow servers to expose parameterized resources using URI templates. Arguments may be auto-completed through the completion API. + +Request: + +{ + "jsonrpc": "2.0", + "id": 3, + "method": "resources/templates/list" +} + +Response: + +{ + "jsonrpc": "2.0", + "id": 3, + "result": { + "resourceTemplates": [ + { + "uriTemplate": "file:///{path}", + "name": "Project Files", + "description": "Access files in the project directory", + "mimeType": "application/octet-stream" + } + ] + } +} + +List Changed Notification + +When the list of available resources changes, servers that declared the listChanged capability SHOULD send a notification: + +{ + "jsonrpc": "2.0", + "method": "notifications/resources/list_changed" +} + +Subscriptions + +The protocol supports optional subscriptions to resource changes. Clients can subscribe to specific resources and receive notifications when they change: + +Subscribe Request: + +{ + "jsonrpc": "2.0", + "id": 4, + "method": "resources/subscribe", + "params": { + "uri": "file:///project/src/main.rs" + } +} + +Update Notification: + +{ + "jsonrpc": "2.0", + "method": "notifications/resources/updated", + "params": { + "uri": "file:///project/src/main.rs" + } +} + +Message Flow + +Server + +Client + +Server + +Client + +Resource Discovery + +Resource Access + +Subscriptions + +Updatesresources/list + +List of resources + +resources/read + +Resource contents + +resources/subscribe + +Subscription confirmed + +notifications/resources/updated + +resources/read + +Updated contents + +Data Types +Resource + +A resource definition includes: + + uri: Unique identifier for the resource + name: Human-readable name + description: Optional description + mimeType: Optional MIME type + +Resource Contents + +Resources can contain either text or binary data: +Text Content + +{ + "uri": "file:///example.txt", + "mimeType": "text/plain", + "text": "Resource content" +} + +Binary Content + +{ + "uri": "file:///example.png", + "mimeType": "image/png", + "blob": "base64-encoded-data" +} + +Common URI Schemes + +The protocol defines several standard URI schemes. This list not exhaustive—implementations are always free to use additional, custom URI schemes. +https:// + +Used to represent a resource available on the web. + +Servers SHOULD use this scheme only when the client is able to fetch and load the resource directly from the web on its own—that is, it doesn’t need to read the resource via the MCP server. + +For other use cases, servers SHOULD prefer to use another URI scheme, or define a custom one, even if the server will itself be downloading resource contents over the internet. +file:// + +Used to identify resources that behave like a filesystem. However, the resources do not need to map to an actual physical filesystem. + +MCP servers MAY identify file:// resources with an XDG MIME type, like inode/directory, to represent non-regular files (such as directories) that don’t otherwise have a standard MIME type. +git:// + +Git version control integration. +Error Handling + +Servers SHOULD return standard JSON-RPC errors for common failure cases: + + Resource not found: -32002 + Internal errors: -32603 + +Example error: + +{ + "jsonrpc": "2.0", + "id": 5, + "error": { + "code": -32002, + "message": "Resource not found", + "data": { + "uri": "file:///nonexistent.txt" + } + } +} + +Security Considerations + + Servers MUST validate all resource URIs + Access controls SHOULD be implemented for sensitive resources + Binary data MUST be properly encoded + Resource permissions SHOULD be checked before operations + + Tools +Protocol Revision: 2024-11-05 + +The Model Context Protocol (MCP) allows servers to expose tools that can be invoked by language models. Tools enable models to interact with external systems, such as querying databases, calling APIs, or performing computations. Each tool is uniquely identified by a name and includes metadata describing its schema. +User Interaction Model + +Tools in MCP are designed to be model-controlled, meaning that the language model can discover and invoke tools automatically based on its contextual understanding and the user’s prompts. + +However, implementations are free to expose tools through any interface pattern that suits their needs—the protocol itself does not mandate any specific user interaction model. + +For trust & safety and security, there SHOULD always be a human in the loop with the ability to deny tool invocations. + +Applications SHOULD: + + Provide UI that makes clear which tools are being exposed to the AI model + Insert clear visual indicators when tools are invoked + Present confirmation prompts to the user for operations, to ensure a human is in the loop + +Capabilities + +Servers that support tools MUST declare the tools capability: + +{ + "capabilities": { + "tools": { + "listChanged": true + } + } +} + +listChanged indicates whether the server will emit notifications when the list of available tools changes. +Protocol Messages +Listing Tools + +To discover available tools, clients send a tools/list request. This operation supports pagination. + +Request: + +{ + "jsonrpc": "2.0", + "id": 1, + "method": "tools/list", + "params": { + "cursor": "optional-cursor-value" + } +} + +Response: + +{ + "jsonrpc": "2.0", + "id": 1, + "result": { + "tools": [ + { + "name": "get_weather", + "description": "Get current weather information for a location", + "inputSchema": { + "type": "object", + "properties": { + "location": { + "type": "string", + "description": "City name or zip code" + } + }, + "required": ["location"] + } + } + ], + "nextCursor": "next-page-cursor" + } +} + +Calling Tools + +To invoke a tool, clients send a tools/call request: + +Request: + +{ + "jsonrpc": "2.0", + "id": 2, + "method": "tools/call", + "params": { + "name": "get_weather", + "arguments": { + "location": "New York" + } + } +} + +Response: + +{ + "jsonrpc": "2.0", + "id": 2, + "result": { + "content": [{ + "type": "text", + "text": "Current weather in New York:\nTemperature: 72°F\nConditions: Partly cloudy" + }], + "isError": false + } +} + +List Changed Notification + +When the list of available tools changes, servers that declared the listChanged capability SHOULD send a notification: + +{ + "jsonrpc": "2.0", + "method": "notifications/tools/list_changed" +} + +Message Flow + +Server + +Client + +LLM + +Server + +Client + +LLM + +Discovery + +Tool Selection + +Invocation + +Updatestools/list + +List of tools + +Select tool to use + +tools/call + +Tool result + +Process result + +tools/list_changed + +tools/list + +Updated tools + +Data Types +Tool + +A tool definition includes: + + name: Unique identifier for the tool + description: Human-readable description of functionality + inputSchema: JSON Schema defining expected parameters + +Tool Result + +Tool results can contain multiple content items of different types: +Text Content + +{ + "type": "text", + "text": "Tool result text" +} + +Image Content + +{ + "type": "image", + "data": "base64-encoded-data", + "mimeType": "image/png" +} + +Embedded Resources + +Resources MAY be embedded, to provide additional context or data, behind a URI that can be subscribed to or fetched again by the client later: + +{ + "type": "resource", + "resource": { + "uri": "resource://example", + "mimeType": "text/plain", + "text": "Resource content" + } +} + +Error Handling + +Tools use two error reporting mechanisms: + + Protocol Errors: Standard JSON-RPC errors for issues like: + Unknown tools + Invalid arguments + Server errors + + Tool Execution Errors: Reported in tool results with isError: true: + API failures + Invalid input data + Business logic errors + +Example protocol error: + +{ + "jsonrpc": "2.0", + "id": 3, + "error": { + "code": -32602, + "message": "Unknown tool: invalid_tool_name" + } +} + +Example tool execution error: + +{ + "jsonrpc": "2.0", + "id": 4, + "result": { + "content": [{ + "type": "text", + "text": "Failed to fetch weather data: API rate limit exceeded" + }], + "isError": true + } +} + +Security Considerations + + Servers MUST: + Validate all tool inputs + Implement proper access controls + Rate limit tool invocations + Sanitize tool outputs + + Clients SHOULD: + Prompt for user confirmation on sensitive operations + Show tool inputs to the user before calling the server, to avoid malicious or accidental data exfiltration + Validate tool results before passing to LLM + Implement timeouts for tool calls + Log tool usage for audit purposes + + +Completion +Protocol Revision: 2024-11-05 + +The Model Context Protocol (MCP) provides a standardized way for servers to offer argument autocompletion suggestions for prompts and resource URIs. This enables rich, IDE-like experiences where users receive contextual suggestions while entering argument values. +User Interaction Model + +Completion in MCP is designed to support interactive user experiences similar to IDE code completion. + +For example, applications may show completion suggestions in a dropdown or popup menu as users type, with the ability to filter and select from available options. + +However, implementations are free to expose completion through any interface pattern that suits their needs—the protocol itself does not mandate any specific user interaction model. +Protocol Messages +Requesting Completions + +To get completion suggestions, clients send a completion/complete request specifying what is being completed through a reference type: + +Request: + +{ + "jsonrpc": "2.0", + "id": 1, + "method": "completion/complete", + "params": { + "ref": { + "type": "ref/prompt", + "name": "code_review" + }, + "argument": { + "name": "language", + "value": "py" + } + } +} + +Response: + +{ + "jsonrpc": "2.0", + "id": 1, + "result": { + "completion": { + "values": ["python", "pytorch", "pyside"], + "total": 10, + "hasMore": true + } + } +} + +Reference Types + +The protocol supports two types of completion references: +Type Description Example +ref/prompt References a prompt by name {"type": "ref/prompt", "name": "code_review"} +ref/resource References a resource URI {"type": "ref/resource", "uri": "file:///{path}"} +Completion Results + +Servers return an array of completion values ranked by relevance, with: + + Maximum 100 items per response + Optional total number of available matches + Boolean indicating if additional results exist + +Message Flow + +Server + +Client + +Server + +Client + +User types argument + +User continues typingcompletion/complete + +Completion suggestions + +completion/complete + +Refined suggestions + +Data Types +CompleteRequest + + ref: A PromptReference or ResourceReference + argument: Object containing: + name: Argument name + value: Current value + +CompleteResult + + completion: Object containing: + values: Array of suggestions (max 100) + total: Optional total matches + hasMore: Additional results flag + +Implementation Considerations + + Servers SHOULD: + Return suggestions sorted by relevance + Implement fuzzy matching where appropriate + Rate limit completion requests + Validate all inputs + + Clients SHOULD: + Debounce rapid completion requests + Cache completion results where appropriate + Handle missing or partial results gracefully + +Security + +Implementations MUST: + + Validate all completion inputs + Implement appropriate rate limiting + Control access to sensitive suggestions + Prevent completion-based information disclosure + +Logging + + +Logging +Protocol Revision: 2024-11-05 + +The Model Context Protocol (MCP) provides a standardized way for servers to send structured log messages to clients. Clients can control logging verbosity by setting minimum log levels, with servers sending notifications containing severity levels, optional logger names, and arbitrary JSON-serializable data. +User Interaction Model + +Implementations are free to expose logging through any interface pattern that suits their needs—the protocol itself does not mandate any specific user interaction model. +Capabilities + +Servers that emit log message notifications MUST declare the logging capability: + +{ + "capabilities": { + "logging": {} + } +} + +Log Levels + +The protocol follows the standard syslog severity levels specified in RFC 5424: +Level Description Example Use Case +debug Detailed debugging information Function entry/exit points +info General informational messages Operation progress updates +notice Normal but significant events Configuration changes +warning Warning conditions Deprecated feature usage +error Error conditions Operation failures +critical Critical conditions System component failures +alert Action must be taken immediately Data corruption detected +emergency System is unusable Complete system failure +Protocol Messages +Setting Log Level + +To configure the minimum log level, clients MAY send a logging/setLevel request: + +Request: + +{ + "jsonrpc": "2.0", + "id": 1, + "method": "logging/setLevel", + "params": { + "level": "info" + } +} + +Log Message Notifications + +Servers send log messages using notifications/message notifications: + +{ + "jsonrpc": "2.0", + "method": "notifications/message", + "params": { + "level": "error", + "logger": "database", + "data": { + "error": "Connection failed", + "details": { + "host": "localhost", + "port": 5432 + } + } + } +} + +Message Flow + +Server + +Client + +Server + +Client + +Configure Logging + +Server Activity + +Level Change + +Only sends error leveland abovelogging/setLevel (info) + +Empty Result + +notifications/message (info) + +notifications/message (warning) + +notifications/message (error) + +logging/setLevel (error) + +Empty Result + +Error Handling + +Servers SHOULD return standard JSON-RPC errors for common failure cases: + + Invalid log level: -32602 (Invalid params) + Configuration errors: -32603 (Internal error) + +Implementation Considerations + + Servers SHOULD: + Rate limit log messages + Include relevant context in data field + Use consistent logger names + Remove sensitive information + + Clients MAY: + Present log messages in the UI + Implement log filtering/search + Display severity visually + Persist log messages + +Security + + Log messages MUST NOT contain: + Credentials or secrets + Personal identifying information + Internal system details that could aid attacks + + Implementations SHOULD: + Rate limit messages + Validate all data fields + Control log access + Monitor for sensitive content + + + Pagination +Protocol Revision: 2024-11-05 + +The Model Context Protocol (MCP) supports paginating list operations that may return large result sets. Pagination allows servers to yield results in smaller chunks rather than all at once. + +Pagination is especially important when connecting to external services over the internet, but also useful for local integrations to avoid performance issues with large data sets. +Pagination Model + +Pagination in MCP uses an opaque cursor-based approach, instead of numbered pages. + + The cursor is an opaque string token, representing a position in the result set + Page size is determined by the server, and MAY NOT be fixed + +Response Format + +Pagination starts when the server sends a response that includes: + + The current page of results + An optional nextCursor field if more results exist + +{ + "jsonrpc": "2.0", + "id": "123", + "result": { + "resources": [...], + "nextCursor": "eyJwYWdlIjogM30=" + } +} + +Request Format + +After receiving a cursor, the client can continue paginating by issuing a request including that cursor: + +{ + "jsonrpc": "2.0", + "method": "resources/list", + "params": { + "cursor": "eyJwYWdlIjogMn0=" + } +} + +Pagination Flow + +Server + +Client + +Server + +Client + +loop[Pagination Loop]List Request (no cursor) + +Page of results + nextCursor + +List Request (with cursor) + +Operations Supporting Pagination + +The following MCP operations support pagination: + + resources/list - List available resources + resources/templates/list - List resource templates + prompts/list - List available prompts + tools/list - List available tools + +Implementation Guidelines + + Servers SHOULD: + Provide stable cursors + Handle invalid cursors gracefully + + Clients SHOULD: + Treat a missing nextCursor as the end of results + Support both paginated and non-paginated flows + + Clients MUST treat cursors as opaque tokens: + Don’t make assumptions about cursor format + Don’t attempt to parse or modify cursors + Don’t persist cursors across sessions + +Error Handling + +Invalid cursors SHOULD result in an error with code -32602 (Invalid params). + + +Roots +Protocol Revision: 2024-11-05 + +The Model Context Protocol (MCP) provides a standardized way for clients to expose filesystem “roots” to servers. Roots define the boundaries of where servers can operate within the filesystem, allowing them to understand which directories and files they have access to. Servers can request the list of roots from supporting clients and receive notifications when that list changes. +User Interaction Model + +Roots in MCP are typically exposed through workspace or project configuration interfaces. + +For example, implementations could offer a workspace/project picker that allows users to select directories and files the server should have access to. This can be combined with automatic workspace detection from version control systems or project files. + +However, implementations are free to expose roots through any interface pattern that suits their needs—the protocol itself does not mandate any specific user interaction model. +Capabilities + +Clients that support roots MUST declare the roots capability during initialization: + +{ + "capabilities": { + "roots": { + "listChanged": true + } + } +} + +listChanged indicates whether the client will emit notifications when the list of roots changes. +Protocol Messages +Listing Roots + +To retrieve roots, servers send a roots/list request: + +Request: + +{ + "jsonrpc": "2.0", + "id": 1, + "method": "roots/list" +} + +Response: + +{ + "jsonrpc": "2.0", + "id": 1, + "result": { + "roots": [ + { + "uri": "file:///home/user/projects/myproject", + "name": "My Project" + } + ] + } +} + +Root List Changes + +When roots change, clients that support listChanged MUST send a notification: + +{ + "jsonrpc": "2.0", + "method": "notifications/roots/list_changed" +} + +Message Flow + +Client + +Server + +Client + +Server + +Discovery + +Changesroots/list + +Available roots + +notifications/roots/list_changed + +roots/list + +Updated roots + +Data Types +Root + +A root definition includes: + + uri: Unique identifier for the root. This MUST be a file:// URI in the current specification. + name: Optional human-readable name for display purposes. + +Example roots for different use cases: +Project Directory + +{ + "uri": "file:///home/user/projects/myproject", + "name": "My Project" +} + +Multiple Repositories + +[ + { + "uri": "file:///home/user/repos/frontend", + "name": "Frontend Repository" + }, + { + "uri": "file:///home/user/repos/backend", + "name": "Backend Repository" + } +] + +Error Handling + +Clients SHOULD return standard JSON-RPC errors for common failure cases: + + Client does not support roots: -32601 (Method not found) + Internal errors: -32603 + +Example error: + +{ + "jsonrpc": "2.0", + "id": 1, + "error": { + "code": -32601, + "message": "Roots not supported", + "data": { + "reason": "Client does not have roots capability" + } + } +} + +Security Considerations + + Clients MUST: + Only expose roots with appropriate permissions + Validate all root URIs to prevent path traversal + Implement proper access controls + Monitor root accessibility + + Servers SHOULD: + Handle cases where roots become unavailable + Respect root boundaries during operations + Validate all paths against provided roots + +Implementation Guidelines + + Clients SHOULD: + Prompt users for consent before exposing roots to servers + Provide clear user interfaces for root management + Validate root accessibility before exposing + Monitor for root changes + + Servers SHOULD: + Check for roots capability before usage + Handle root list changes gracefully + Respect root boundaries in operations + Cache root information appropriately + +Sampling + +Sampling +Protocol Revision: 2024-11-05 + +The Model Context Protocol (MCP) provides a standardized way for servers to request LLM sampling (“completions” or “generations”) from language models via clients. This flow allows clients to maintain control over model access, selection, and permissions while enabling servers to leverage AI capabilities—with no server API keys necessary. Servers can request text or image-based interactions and optionally include context from MCP servers in their prompts. +User Interaction Model + +Sampling in MCP allows servers to implement agentic behaviors, by enabling LLM calls to occur nested inside other MCP server features. + +Implementations are free to expose sampling through any interface pattern that suits their needs—the protocol itself does not mandate any specific user interaction model. + +For trust & safety and security, there SHOULD always be a human in the loop with the ability to deny sampling requests. + +Applications SHOULD: + + Provide UI that makes it easy and intuitive to review sampling requests + Allow users to view and edit prompts before sending + Present generated responses for review before delivery + +Capabilities + +Clients that support sampling MUST declare the sampling capability during initialization: + +{ + "capabilities": { + "sampling": {} + } +} + +Protocol Messages +Creating Messages + +To request a language model generation, servers send a sampling/createMessage request: + +Request: + +{ + "jsonrpc": "2.0", + "id": 1, + "method": "sampling/createMessage", + "params": { + "messages": [ + { + "role": "user", + "content": { + "type": "text", + "text": "What is the capital of France?" + } + } + ], + "modelPreferences": { + "hints": [ + { + "name": "claude-3-sonnet" + } + ], + "intelligencePriority": 0.8, + "speedPriority": 0.5 + }, + "systemPrompt": "You are a helpful assistant.", + "maxTokens": 100 + } +} + +Response: + +{ + "jsonrpc": "2.0", + "id": 1, + "result": { + "role": "assistant", + "content": { + "type": "text", + "text": "The capital of France is Paris." + }, + "model": "claude-3-sonnet-20240307", + "stopReason": "endTurn" + } +} + +Message Flow + +LLM + +User + +Client + +Server + +LLM + +User + +Client + +Server + +Server initiates sampling + +Human-in-the-loop review + +Model interaction + +Response review + +Complete requestsampling/createMessage + +Present request for approval + +Review and approve/modify + +Forward approved request + +Return generation + +Present response for approval + +Review and approve/modify + +Return approved response + +Data Types +Messages + +Sampling messages can contain: +Text Content + +{ + "type": "text", + "text": "The message content" +} + +Image Content + +{ + "type": "image", + "data": "base64-encoded-image-data", + "mimeType": "image/jpeg" +} + +Model Preferences + +Model selection in MCP requires careful abstraction since servers and clients may use different AI providers with distinct model offerings. A server cannot simply request a specific model by name since the client may not have access to that exact model or may prefer to use a different provider’s equivalent model. + +To solve this, MCP implements a preference system that combines abstract capability priorities with optional model hints: +Capability Priorities + +Servers express their needs through three normalized priority values (0-1): + + costPriority: How important is minimizing costs? Higher values prefer cheaper models. + speedPriority: How important is low latency? Higher values prefer faster models. + intelligencePriority: How important are advanced capabilities? Higher values prefer more capable models. + +Model Hints + +While priorities help select models based on characteristics, hints allow servers to suggest specific models or model families: + + Hints are treated as substrings that can match model names flexibly + Multiple hints are evaluated in order of preference + Clients MAY map hints to equivalent models from different providers + Hints are advisory—clients make final model selection + +For example: + +{ + "hints": [ + {"name": "claude-3-sonnet"}, // Prefer Sonnet-class models + {"name": "claude"} // Fall back to any Claude model + ], + "costPriority": 0.3, // Cost is less important + "speedPriority": 0.8, // Speed is very important + "intelligencePriority": 0.5 // Moderate capability needs +} + +The client processes these preferences to select an appropriate model from its available options. For instance, if the client doesn’t have access to Claude models but has Gemini, it might map the sonnet hint to gemini-1.5-pro based on similar capabilities. +Error Handling + +Clients SHOULD return errors for common failure cases: + +Example error: + +{ + "jsonrpc": "2.0", + "id": 1, + "error": { + "code": -1, + "message": "User rejected sampling request" + } +} + +Security Considerations + + Clients SHOULD implement user approval controls + Both parties SHOULD validate message content + Clients SHOULD respect model preference hints + Clients SHOULD implement rate limiting + Both parties MUST handle sensitive data appropriately + + + + + \ No newline at end of file diff --git a/README.md b/README.md index 5422f78..b944cfd 100644 --- a/README.md +++ b/README.md @@ -1,70 +1,135 @@ -# mcp-ragdocs MCP Server +# mcp-server-ragdocs -A Model Context Protocol server for fetching and storing documentation in a vector database, enabling semantic search and retrieval to augment LLM capabilities with relevant documentation context. - -This is a TypeScript-based MCP server that implements a simple notes system. It demonstrates core MCP concepts by providing: - -- Resources representing text notes with URIs and metadata -- Tools for creating new notes -- Prompts for generating summaries of notes +A Model Context Protocol (MCP) server that enables semantic search and retrieval of documentation using a vector database (Qdrant). This server allows you to add documentation from URLs or local files and then search through them using natural language queries. ## Features -### Resources -- List and access notes via `note://` URIs -- Each note has a title, content and metadata -- Plain text mime type for simple content access - -### Tools -- `create_note` - Create new text notes - - Takes title and content as required parameters - - Stores note in server state +- Add documentation from URLs or local files +- Store documentation in a vector database for semantic search +- Search through documentation using natural language +- List all documentation sources -### Prompts -- `summarize_notes` - Generate a summary of all stored notes - - Includes all note contents as embedded resources - - Returns structured prompt for LLM summarization +## Installation -## Development +You can use this server directly with `npx`: -Install dependencies: ```bash -npm install +npx -y @qpd-v/mcp-server-ragdocs ``` -Build the server: +Or install it globally: + ```bash -npm run build +npm install -g @qpd-v/mcp-server-ragdocs ``` -For development with auto-rebuild: +## Requirements + +- Node.js 16 or higher +- Qdrant running locally (see [Qdrant Installation](#qdrant-installation)) +- OpenAI API key for generating embeddings + +## Qdrant Installation + +1. Using Docker (recommended): ```bash -npm run watch +docker run -p 6333:6333 -p 6334:6334 qdrant/qdrant ``` -## Installation +2. Or download from [Qdrant's website](https://qdrant.tech/documentation/quick-start/) -To use with Claude Desktop, add the server config: +## Configuration -On MacOS: `~/Library/Application Support/Claude/claude_desktop_config.json` -On Windows: `%APPDATA%/Claude/claude_desktop_config.json` +### Claude Desktop + +Add this to your Claude Desktop configuration file: + +Windows: `%AppData%\Claude\claude_desktop_config.json` +macOS: `~/Library/Application Support/Claude/claude_desktop_config.json` ```json { "mcpServers": { - "mcp-ragdocs": { - "command": "/path/to/mcp-ragdocs/build/index.js" + "ragdocs": { + "command": "npx", + "args": ["-y", "@qpd-v/mcp-server-ragdocs"], + "env": { + "OPENAI_API_KEY": "your-openai-api-key", + "QDRANT_URL": "http://localhost:6333" + } } } } ``` -### Debugging +### Environment Variables + +- `OPENAI_API_KEY` (required): Your OpenAI API key for generating embeddings +- `QDRANT_URL` (optional): URL of your Qdrant instance (defaults to http://localhost:6333) + +## Available Tools + +1. `add_documentation` + - Add documentation from a URL to the RAG database + - Parameters: + - `url`: URL of the documentation to fetch + +2. `search_documentation` + - Search through stored documentation + - Parameters: + - `query`: Search query + - `limit` (optional): Maximum number of results to return (default: 5) -Since MCP servers communicate over stdio, debugging can be challenging. We recommend using the [MCP Inspector](https://github.com/modelcontextprotocol/inspector), which is available as a package script: +3. `list_sources` + - List all documentation sources currently stored + - No parameters required + +## Example Usage + +In Claude Desktop or any other MCP-compatible client: + +1. Add documentation: +``` +Add this documentation: https://docs.example.com/api +``` +2. Search documentation: +``` +Search the documentation for information about authentication +``` + +3. List sources: +``` +What documentation sources are available? +``` + +## Development + +1. Clone the repository: +```bash +git clone https://github.com/qpd-v/mcp-server-ragdocs.git +cd mcp-server-ragdocs +``` + +2. Install dependencies: ```bash -npm run inspector +npm install +``` + +3. Build the project: +```bash +npm run build ``` -The Inspector will provide a URL to access debugging tools in your browser. +4. Run locally: +```bash +npm start +``` + +## License + +MIT + +## Contributing + +Contributions are welcome! Please feel free to submit a Pull Request. diff --git a/package.json b/package.json index 39b2d11..5e841f8 100644 --- a/package.json +++ b/package.json @@ -1,8 +1,8 @@ { - "name": "mcp-ragdocs", + "name": "@qpd-v/mcp-server-ragdocs", "version": "0.1.0", "description": "A Model Context Protocol server for fetching and storing documentation in a vector database, enabling semantic search and retrieval to augment LLM capabilities with relevant documentation context.", - "private": true, + "private": false, "type": "module", "bin": { "mcp-ragdocs": "./build/index.js" @@ -14,8 +14,29 @@ "build": "tsc && node -e \"require('fs').chmodSync('build/index.js', '755')\"", "prepare": "npm run build", "watch": "tsc --watch", - "inspector": "npx @modelcontextprotocol/inspector build/index.js" + "inspector": "npx @modelcontextprotocol/inspector build/index.js", + "start": "node build/index.js" }, + "keywords": [ + "mcp", + "model-context-protocol", + "rag", + "documentation", + "vector-database", + "qdrant", + "claude", + "llm" + ], + "author": "qpd-v", + "license": "MIT", + "repository": { + "type": "git", + "url": "git+https://github.com/qpd-v/mcp-server-ragdocs.git" + }, + "bugs": { + "url": "https://github.com/qpd-v/mcp-server-ragdocs/issues" + }, + "homepage": "https://github.com/qpd-v/mcp-server-ragdocs#readme", "dependencies": { "@azure/openai": "^2.0.0", "@modelcontextprotocol/sdk": "0.6.0", @@ -28,5 +49,8 @@ "devDependencies": { "@types/node": "^20.11.24", "typescript": "^5.3.3" + }, + "publishConfig": { + "access": "public" } } diff --git a/qdrant_storage/collections/documentation/0/newest_clocks.json b/qdrant_storage/collections/documentation/0/newest_clocks.json index c90ab93..ea36bbc 100644 --- a/qdrant_storage/collections/documentation/0/newest_clocks.json +++ b/qdrant_storage/collections/documentation/0/newest_clocks.json @@ -1 +1 @@ -{"clocks":[{"peer_id":3856757951601897,"clock_id":0,"current_tick":29,"token":2787282897899178577}]} \ No newline at end of file +{"clocks":[{"peer_id":3856757951601897,"clock_id":0,"current_tick":227,"token":16475189807144537991}]} \ No newline at end of file diff --git a/qdrant_storage/collections/documentation/0/segments/30c1435e-159b-4e27-95b6-b1a7f3b8e1a4/000009.sst b/qdrant_storage/collections/documentation/0/segments/30c1435e-159b-4e27-95b6-b1a7f3b8e1a4/000009.sst deleted file mode 100644 index 3611aa3..0000000 Binary files a/qdrant_storage/collections/documentation/0/segments/30c1435e-159b-4e27-95b6-b1a7f3b8e1a4/000009.sst and /dev/null differ diff --git a/qdrant_storage/collections/documentation/0/segments/30c1435e-159b-4e27-95b6-b1a7f3b8e1a4/000012.sst b/qdrant_storage/collections/documentation/0/segments/30c1435e-159b-4e27-95b6-b1a7f3b8e1a4/000012.sst deleted file mode 100644 index cb9ea27..0000000 Binary files a/qdrant_storage/collections/documentation/0/segments/30c1435e-159b-4e27-95b6-b1a7f3b8e1a4/000012.sst and /dev/null differ diff --git a/qdrant_storage/collections/documentation/0/segments/30c1435e-159b-4e27-95b6-b1a7f3b8e1a4/000014.sst b/qdrant_storage/collections/documentation/0/segments/30c1435e-159b-4e27-95b6-b1a7f3b8e1a4/000014.sst deleted file mode 100644 index 9104df4..0000000 Binary files a/qdrant_storage/collections/documentation/0/segments/30c1435e-159b-4e27-95b6-b1a7f3b8e1a4/000014.sst and /dev/null differ diff --git a/qdrant_storage/collections/documentation/0/segments/30c1435e-159b-4e27-95b6-b1a7f3b8e1a4/000017.sst b/qdrant_storage/collections/documentation/0/segments/30c1435e-159b-4e27-95b6-b1a7f3b8e1a4/000017.sst deleted file mode 100644 index e1dad36..0000000 Binary files a/qdrant_storage/collections/documentation/0/segments/30c1435e-159b-4e27-95b6-b1a7f3b8e1a4/000017.sst and /dev/null differ diff --git a/qdrant_storage/collections/documentation/0/segments/30c1435e-159b-4e27-95b6-b1a7f3b8e1a4/MANIFEST-000005 b/qdrant_storage/collections/documentation/0/segments/30c1435e-159b-4e27-95b6-b1a7f3b8e1a4/MANIFEST-000005 index 6822f5d..d90d020 100644 Binary files a/qdrant_storage/collections/documentation/0/segments/30c1435e-159b-4e27-95b6-b1a7f3b8e1a4/MANIFEST-000005 and b/qdrant_storage/collections/documentation/0/segments/30c1435e-159b-4e27-95b6-b1a7f3b8e1a4/MANIFEST-000005 differ diff --git a/qdrant_storage/collections/documentation/0/segments/30c1435e-159b-4e27-95b6-b1a7f3b8e1a4/segment.json b/qdrant_storage/collections/documentation/0/segments/30c1435e-159b-4e27-95b6-b1a7f3b8e1a4/segment.json index 1a07996..fdaa4ec 100644 --- a/qdrant_storage/collections/documentation/0/segments/30c1435e-159b-4e27-95b6-b1a7f3b8e1a4/segment.json +++ b/qdrant_storage/collections/documentation/0/segments/30c1435e-159b-4e27-95b6-b1a7f3b8e1a4/segment.json @@ -1 +1 @@ -{"version":25,"config":{"vector_data":{"":{"size":1536,"distance":"Cosine","storage_type":"InRamChunkedMmap","index":{"type":"plain","options":{}},"quantization_config":null}},"payload_storage_type":{"type":"on_disk"}}} \ No newline at end of file +{"version":225,"config":{"vector_data":{"":{"size":1536,"distance":"Cosine","storage_type":"InRamChunkedMmap","index":{"type":"plain","options":{}},"quantization_config":null}},"payload_storage_type":{"type":"on_disk"}}} \ No newline at end of file diff --git a/qdrant_storage/collections/documentation/0/segments/30c1435e-159b-4e27-95b6-b1a7f3b8e1a4/vector_storage/deleted/status.dat b/qdrant_storage/collections/documentation/0/segments/30c1435e-159b-4e27-95b6-b1a7f3b8e1a4/vector_storage/deleted/status.dat index 64b9483..2d7ae40 100644 Binary files a/qdrant_storage/collections/documentation/0/segments/30c1435e-159b-4e27-95b6-b1a7f3b8e1a4/vector_storage/deleted/status.dat and b/qdrant_storage/collections/documentation/0/segments/30c1435e-159b-4e27-95b6-b1a7f3b8e1a4/vector_storage/deleted/status.dat differ diff --git a/qdrant_storage/collections/documentation/0/segments/30c1435e-159b-4e27-95b6-b1a7f3b8e1a4/vector_storage/vectors/chunk_0.mmap b/qdrant_storage/collections/documentation/0/segments/30c1435e-159b-4e27-95b6-b1a7f3b8e1a4/vector_storage/vectors/chunk_0.mmap index 2c918f3..3185fcc 100644 Binary files a/qdrant_storage/collections/documentation/0/segments/30c1435e-159b-4e27-95b6-b1a7f3b8e1a4/vector_storage/vectors/chunk_0.mmap and b/qdrant_storage/collections/documentation/0/segments/30c1435e-159b-4e27-95b6-b1a7f3b8e1a4/vector_storage/vectors/chunk_0.mmap differ diff --git a/qdrant_storage/collections/documentation/0/segments/30c1435e-159b-4e27-95b6-b1a7f3b8e1a4/vector_storage/vectors/status.dat b/qdrant_storage/collections/documentation/0/segments/30c1435e-159b-4e27-95b6-b1a7f3b8e1a4/vector_storage/vectors/status.dat index f1dba9d..308adbe 100644 Binary files a/qdrant_storage/collections/documentation/0/segments/30c1435e-159b-4e27-95b6-b1a7f3b8e1a4/vector_storage/vectors/status.dat and b/qdrant_storage/collections/documentation/0/segments/30c1435e-159b-4e27-95b6-b1a7f3b8e1a4/vector_storage/vectors/status.dat differ diff --git a/qdrant_storage/collections/documentation/0/segments/3bd3d92f-06a3-49d3-b6ed-ef6bd4d4e47d/000009.sst b/qdrant_storage/collections/documentation/0/segments/3bd3d92f-06a3-49d3-b6ed-ef6bd4d4e47d/000009.sst deleted file mode 100644 index a625770..0000000 Binary files a/qdrant_storage/collections/documentation/0/segments/3bd3d92f-06a3-49d3-b6ed-ef6bd4d4e47d/000009.sst and /dev/null differ diff --git a/qdrant_storage/collections/documentation/0/segments/3bd3d92f-06a3-49d3-b6ed-ef6bd4d4e47d/000012.sst b/qdrant_storage/collections/documentation/0/segments/3bd3d92f-06a3-49d3-b6ed-ef6bd4d4e47d/000012.sst deleted file mode 100644 index 58a2e74..0000000 Binary files a/qdrant_storage/collections/documentation/0/segments/3bd3d92f-06a3-49d3-b6ed-ef6bd4d4e47d/000012.sst and /dev/null differ diff --git a/qdrant_storage/collections/documentation/0/segments/3bd3d92f-06a3-49d3-b6ed-ef6bd4d4e47d/000014.sst b/qdrant_storage/collections/documentation/0/segments/3bd3d92f-06a3-49d3-b6ed-ef6bd4d4e47d/000014.sst deleted file mode 100644 index 82b2190..0000000 Binary files a/qdrant_storage/collections/documentation/0/segments/3bd3d92f-06a3-49d3-b6ed-ef6bd4d4e47d/000014.sst and /dev/null differ diff --git a/qdrant_storage/collections/documentation/0/segments/3bd3d92f-06a3-49d3-b6ed-ef6bd4d4e47d/000017.sst b/qdrant_storage/collections/documentation/0/segments/3bd3d92f-06a3-49d3-b6ed-ef6bd4d4e47d/000017.sst deleted file mode 100644 index dd3ab7d..0000000 Binary files a/qdrant_storage/collections/documentation/0/segments/3bd3d92f-06a3-49d3-b6ed-ef6bd4d4e47d/000017.sst and /dev/null differ diff --git a/qdrant_storage/collections/documentation/0/segments/3bd3d92f-06a3-49d3-b6ed-ef6bd4d4e47d/MANIFEST-000005 b/qdrant_storage/collections/documentation/0/segments/3bd3d92f-06a3-49d3-b6ed-ef6bd4d4e47d/MANIFEST-000005 index 8646e0c..6ff0308 100644 Binary files a/qdrant_storage/collections/documentation/0/segments/3bd3d92f-06a3-49d3-b6ed-ef6bd4d4e47d/MANIFEST-000005 and b/qdrant_storage/collections/documentation/0/segments/3bd3d92f-06a3-49d3-b6ed-ef6bd4d4e47d/MANIFEST-000005 differ diff --git a/qdrant_storage/collections/documentation/0/segments/3bd3d92f-06a3-49d3-b6ed-ef6bd4d4e47d/segment.json b/qdrant_storage/collections/documentation/0/segments/3bd3d92f-06a3-49d3-b6ed-ef6bd4d4e47d/segment.json index 88cf91c..77e8218 100644 --- a/qdrant_storage/collections/documentation/0/segments/3bd3d92f-06a3-49d3-b6ed-ef6bd4d4e47d/segment.json +++ b/qdrant_storage/collections/documentation/0/segments/3bd3d92f-06a3-49d3-b6ed-ef6bd4d4e47d/segment.json @@ -1 +1 @@ -{"version":26,"config":{"vector_data":{"":{"size":1536,"distance":"Cosine","storage_type":"InRamChunkedMmap","index":{"type":"plain","options":{}},"quantization_config":null}},"payload_storage_type":{"type":"on_disk"}}} \ No newline at end of file +{"version":226,"config":{"vector_data":{"":{"size":1536,"distance":"Cosine","storage_type":"InRamChunkedMmap","index":{"type":"plain","options":{}},"quantization_config":null}},"payload_storage_type":{"type":"on_disk"}}} \ No newline at end of file diff --git a/qdrant_storage/collections/documentation/0/segments/3bd3d92f-06a3-49d3-b6ed-ef6bd4d4e47d/vector_storage/vectors/chunk_0.mmap b/qdrant_storage/collections/documentation/0/segments/3bd3d92f-06a3-49d3-b6ed-ef6bd4d4e47d/vector_storage/vectors/chunk_0.mmap index 6cec829..3c3017c 100644 Binary files a/qdrant_storage/collections/documentation/0/segments/3bd3d92f-06a3-49d3-b6ed-ef6bd4d4e47d/vector_storage/vectors/chunk_0.mmap and b/qdrant_storage/collections/documentation/0/segments/3bd3d92f-06a3-49d3-b6ed-ef6bd4d4e47d/vector_storage/vectors/chunk_0.mmap differ diff --git a/qdrant_storage/collections/documentation/0/segments/3bd3d92f-06a3-49d3-b6ed-ef6bd4d4e47d/vector_storage/vectors/status.dat b/qdrant_storage/collections/documentation/0/segments/3bd3d92f-06a3-49d3-b6ed-ef6bd4d4e47d/vector_storage/vectors/status.dat index f1dba9d..308adbe 100644 Binary files a/qdrant_storage/collections/documentation/0/segments/3bd3d92f-06a3-49d3-b6ed-ef6bd4d4e47d/vector_storage/vectors/status.dat and b/qdrant_storage/collections/documentation/0/segments/3bd3d92f-06a3-49d3-b6ed-ef6bd4d4e47d/vector_storage/vectors/status.dat differ diff --git a/qdrant_storage/collections/documentation/0/segments/3c3f1a7f-b7bc-4a8d-a182-d447454c252e/000009.sst b/qdrant_storage/collections/documentation/0/segments/3c3f1a7f-b7bc-4a8d-a182-d447454c252e/000009.sst deleted file mode 100644 index a8a798a..0000000 Binary files a/qdrant_storage/collections/documentation/0/segments/3c3f1a7f-b7bc-4a8d-a182-d447454c252e/000009.sst and /dev/null differ diff --git a/qdrant_storage/collections/documentation/0/segments/3c3f1a7f-b7bc-4a8d-a182-d447454c252e/000012.sst b/qdrant_storage/collections/documentation/0/segments/3c3f1a7f-b7bc-4a8d-a182-d447454c252e/000012.sst deleted file mode 100644 index ce4dc4b..0000000 Binary files a/qdrant_storage/collections/documentation/0/segments/3c3f1a7f-b7bc-4a8d-a182-d447454c252e/000012.sst and /dev/null differ diff --git a/qdrant_storage/collections/documentation/0/segments/3c3f1a7f-b7bc-4a8d-a182-d447454c252e/000014.sst b/qdrant_storage/collections/documentation/0/segments/3c3f1a7f-b7bc-4a8d-a182-d447454c252e/000014.sst deleted file mode 100644 index ac5da39..0000000 Binary files a/qdrant_storage/collections/documentation/0/segments/3c3f1a7f-b7bc-4a8d-a182-d447454c252e/000014.sst and /dev/null differ diff --git a/qdrant_storage/collections/documentation/0/segments/3c3f1a7f-b7bc-4a8d-a182-d447454c252e/000017.sst b/qdrant_storage/collections/documentation/0/segments/3c3f1a7f-b7bc-4a8d-a182-d447454c252e/000017.sst deleted file mode 100644 index 89e73dd..0000000 Binary files a/qdrant_storage/collections/documentation/0/segments/3c3f1a7f-b7bc-4a8d-a182-d447454c252e/000017.sst and /dev/null differ diff --git a/qdrant_storage/collections/documentation/0/segments/3c3f1a7f-b7bc-4a8d-a182-d447454c252e/MANIFEST-000005 b/qdrant_storage/collections/documentation/0/segments/3c3f1a7f-b7bc-4a8d-a182-d447454c252e/MANIFEST-000005 index 8ac5c96..677f343 100644 Binary files a/qdrant_storage/collections/documentation/0/segments/3c3f1a7f-b7bc-4a8d-a182-d447454c252e/MANIFEST-000005 and b/qdrant_storage/collections/documentation/0/segments/3c3f1a7f-b7bc-4a8d-a182-d447454c252e/MANIFEST-000005 differ diff --git a/qdrant_storage/collections/documentation/0/segments/3c3f1a7f-b7bc-4a8d-a182-d447454c252e/segment.json b/qdrant_storage/collections/documentation/0/segments/3c3f1a7f-b7bc-4a8d-a182-d447454c252e/segment.json index 5897f7c..67e43cc 100644 --- a/qdrant_storage/collections/documentation/0/segments/3c3f1a7f-b7bc-4a8d-a182-d447454c252e/segment.json +++ b/qdrant_storage/collections/documentation/0/segments/3c3f1a7f-b7bc-4a8d-a182-d447454c252e/segment.json @@ -1 +1 @@ -{"version":24,"config":{"vector_data":{"":{"size":1536,"distance":"Cosine","storage_type":"InRamChunkedMmap","index":{"type":"plain","options":{}},"quantization_config":null}},"payload_storage_type":{"type":"on_disk"}}} \ No newline at end of file +{"version":224,"config":{"vector_data":{"":{"size":1536,"distance":"Cosine","storage_type":"InRamChunkedMmap","index":{"type":"plain","options":{}},"quantization_config":null}},"payload_storage_type":{"type":"on_disk"}}} \ No newline at end of file diff --git a/qdrant_storage/collections/documentation/0/segments/3c3f1a7f-b7bc-4a8d-a182-d447454c252e/vector_storage/deleted/status.dat b/qdrant_storage/collections/documentation/0/segments/3c3f1a7f-b7bc-4a8d-a182-d447454c252e/vector_storage/deleted/status.dat index 64b9483..2d7ae40 100644 Binary files a/qdrant_storage/collections/documentation/0/segments/3c3f1a7f-b7bc-4a8d-a182-d447454c252e/vector_storage/deleted/status.dat and b/qdrant_storage/collections/documentation/0/segments/3c3f1a7f-b7bc-4a8d-a182-d447454c252e/vector_storage/deleted/status.dat differ diff --git a/qdrant_storage/collections/documentation/0/segments/3c3f1a7f-b7bc-4a8d-a182-d447454c252e/vector_storage/vectors/chunk_0.mmap b/qdrant_storage/collections/documentation/0/segments/3c3f1a7f-b7bc-4a8d-a182-d447454c252e/vector_storage/vectors/chunk_0.mmap index b7eb7c7..e3588b6 100644 Binary files a/qdrant_storage/collections/documentation/0/segments/3c3f1a7f-b7bc-4a8d-a182-d447454c252e/vector_storage/vectors/chunk_0.mmap and b/qdrant_storage/collections/documentation/0/segments/3c3f1a7f-b7bc-4a8d-a182-d447454c252e/vector_storage/vectors/chunk_0.mmap differ diff --git a/qdrant_storage/collections/documentation/0/segments/3c3f1a7f-b7bc-4a8d-a182-d447454c252e/vector_storage/vectors/status.dat b/qdrant_storage/collections/documentation/0/segments/3c3f1a7f-b7bc-4a8d-a182-d447454c252e/vector_storage/vectors/status.dat index f1dba9d..308adbe 100644 Binary files a/qdrant_storage/collections/documentation/0/segments/3c3f1a7f-b7bc-4a8d-a182-d447454c252e/vector_storage/vectors/status.dat and b/qdrant_storage/collections/documentation/0/segments/3c3f1a7f-b7bc-4a8d-a182-d447454c252e/vector_storage/vectors/status.dat differ diff --git a/qdrant_storage/collections/documentation/0/segments/4357a9b1-c2fe-4c3d-924d-4a7085b0499f/000009.sst b/qdrant_storage/collections/documentation/0/segments/4357a9b1-c2fe-4c3d-924d-4a7085b0499f/000009.sst deleted file mode 100644 index 2a80221..0000000 Binary files a/qdrant_storage/collections/documentation/0/segments/4357a9b1-c2fe-4c3d-924d-4a7085b0499f/000009.sst and /dev/null differ diff --git a/qdrant_storage/collections/documentation/0/segments/4357a9b1-c2fe-4c3d-924d-4a7085b0499f/000012.sst b/qdrant_storage/collections/documentation/0/segments/4357a9b1-c2fe-4c3d-924d-4a7085b0499f/000012.sst deleted file mode 100644 index 22f88f8..0000000 Binary files a/qdrant_storage/collections/documentation/0/segments/4357a9b1-c2fe-4c3d-924d-4a7085b0499f/000012.sst and /dev/null differ diff --git a/qdrant_storage/collections/documentation/0/segments/4357a9b1-c2fe-4c3d-924d-4a7085b0499f/000014.sst b/qdrant_storage/collections/documentation/0/segments/4357a9b1-c2fe-4c3d-924d-4a7085b0499f/000014.sst deleted file mode 100644 index 1338312..0000000 Binary files a/qdrant_storage/collections/documentation/0/segments/4357a9b1-c2fe-4c3d-924d-4a7085b0499f/000014.sst and /dev/null differ diff --git a/qdrant_storage/collections/documentation/0/segments/4357a9b1-c2fe-4c3d-924d-4a7085b0499f/000017.sst b/qdrant_storage/collections/documentation/0/segments/4357a9b1-c2fe-4c3d-924d-4a7085b0499f/000017.sst deleted file mode 100644 index d3a8bd3..0000000 Binary files a/qdrant_storage/collections/documentation/0/segments/4357a9b1-c2fe-4c3d-924d-4a7085b0499f/000017.sst and /dev/null differ diff --git a/qdrant_storage/collections/documentation/0/segments/4357a9b1-c2fe-4c3d-924d-4a7085b0499f/MANIFEST-000005 b/qdrant_storage/collections/documentation/0/segments/4357a9b1-c2fe-4c3d-924d-4a7085b0499f/MANIFEST-000005 index b3aef9c..49a64b4 100644 Binary files a/qdrant_storage/collections/documentation/0/segments/4357a9b1-c2fe-4c3d-924d-4a7085b0499f/MANIFEST-000005 and b/qdrant_storage/collections/documentation/0/segments/4357a9b1-c2fe-4c3d-924d-4a7085b0499f/MANIFEST-000005 differ diff --git a/qdrant_storage/collections/documentation/0/segments/4357a9b1-c2fe-4c3d-924d-4a7085b0499f/segment.json b/qdrant_storage/collections/documentation/0/segments/4357a9b1-c2fe-4c3d-924d-4a7085b0499f/segment.json index 550d278..f6604be 100644 --- a/qdrant_storage/collections/documentation/0/segments/4357a9b1-c2fe-4c3d-924d-4a7085b0499f/segment.json +++ b/qdrant_storage/collections/documentation/0/segments/4357a9b1-c2fe-4c3d-924d-4a7085b0499f/segment.json @@ -1 +1 @@ -{"version":27,"config":{"vector_data":{"":{"size":1536,"distance":"Cosine","storage_type":"InRamChunkedMmap","index":{"type":"plain","options":{}},"quantization_config":null}},"payload_storage_type":{"type":"on_disk"}}} \ No newline at end of file +{"version":219,"config":{"vector_data":{"":{"size":1536,"distance":"Cosine","storage_type":"InRamChunkedMmap","index":{"type":"plain","options":{}},"quantization_config":null}},"payload_storage_type":{"type":"on_disk"}}} \ No newline at end of file diff --git a/qdrant_storage/collections/documentation/0/segments/4357a9b1-c2fe-4c3d-924d-4a7085b0499f/vector_storage/deleted/status.dat b/qdrant_storage/collections/documentation/0/segments/4357a9b1-c2fe-4c3d-924d-4a7085b0499f/vector_storage/deleted/status.dat index 64b9483..6e47316 100644 Binary files a/qdrant_storage/collections/documentation/0/segments/4357a9b1-c2fe-4c3d-924d-4a7085b0499f/vector_storage/deleted/status.dat and b/qdrant_storage/collections/documentation/0/segments/4357a9b1-c2fe-4c3d-924d-4a7085b0499f/vector_storage/deleted/status.dat differ diff --git a/qdrant_storage/collections/documentation/0/segments/4357a9b1-c2fe-4c3d-924d-4a7085b0499f/vector_storage/vectors/chunk_0.mmap b/qdrant_storage/collections/documentation/0/segments/4357a9b1-c2fe-4c3d-924d-4a7085b0499f/vector_storage/vectors/chunk_0.mmap index 7a94200..920173b 100644 Binary files a/qdrant_storage/collections/documentation/0/segments/4357a9b1-c2fe-4c3d-924d-4a7085b0499f/vector_storage/vectors/chunk_0.mmap and b/qdrant_storage/collections/documentation/0/segments/4357a9b1-c2fe-4c3d-924d-4a7085b0499f/vector_storage/vectors/chunk_0.mmap differ diff --git a/qdrant_storage/collections/documentation/0/segments/4357a9b1-c2fe-4c3d-924d-4a7085b0499f/vector_storage/vectors/status.dat b/qdrant_storage/collections/documentation/0/segments/4357a9b1-c2fe-4c3d-924d-4a7085b0499f/vector_storage/vectors/status.dat index f1dba9d..c347917 100644 Binary files a/qdrant_storage/collections/documentation/0/segments/4357a9b1-c2fe-4c3d-924d-4a7085b0499f/vector_storage/vectors/status.dat and b/qdrant_storage/collections/documentation/0/segments/4357a9b1-c2fe-4c3d-924d-4a7085b0499f/vector_storage/vectors/status.dat differ diff --git a/qdrant_storage/collections/documentation/0/segments/627217db-dfc1-44ae-903b-98ac2be735dd/000009.sst b/qdrant_storage/collections/documentation/0/segments/627217db-dfc1-44ae-903b-98ac2be735dd/000009.sst deleted file mode 100644 index 4e63a52..0000000 Binary files a/qdrant_storage/collections/documentation/0/segments/627217db-dfc1-44ae-903b-98ac2be735dd/000009.sst and /dev/null differ diff --git a/qdrant_storage/collections/documentation/0/segments/627217db-dfc1-44ae-903b-98ac2be735dd/000013.sst b/qdrant_storage/collections/documentation/0/segments/627217db-dfc1-44ae-903b-98ac2be735dd/000013.sst deleted file mode 100644 index a501f39..0000000 Binary files a/qdrant_storage/collections/documentation/0/segments/627217db-dfc1-44ae-903b-98ac2be735dd/000013.sst and /dev/null differ diff --git a/qdrant_storage/collections/documentation/0/segments/627217db-dfc1-44ae-903b-98ac2be735dd/000015.sst b/qdrant_storage/collections/documentation/0/segments/627217db-dfc1-44ae-903b-98ac2be735dd/000015.sst deleted file mode 100644 index 2fe1b7e..0000000 Binary files a/qdrant_storage/collections/documentation/0/segments/627217db-dfc1-44ae-903b-98ac2be735dd/000015.sst and /dev/null differ diff --git a/qdrant_storage/collections/documentation/0/segments/627217db-dfc1-44ae-903b-98ac2be735dd/000018.sst b/qdrant_storage/collections/documentation/0/segments/627217db-dfc1-44ae-903b-98ac2be735dd/000018.sst deleted file mode 100644 index a867cc8..0000000 Binary files a/qdrant_storage/collections/documentation/0/segments/627217db-dfc1-44ae-903b-98ac2be735dd/000018.sst and /dev/null differ diff --git a/qdrant_storage/collections/documentation/0/segments/627217db-dfc1-44ae-903b-98ac2be735dd/MANIFEST-000005 b/qdrant_storage/collections/documentation/0/segments/627217db-dfc1-44ae-903b-98ac2be735dd/MANIFEST-000005 index 75b7277..a3c586a 100644 Binary files a/qdrant_storage/collections/documentation/0/segments/627217db-dfc1-44ae-903b-98ac2be735dd/MANIFEST-000005 and b/qdrant_storage/collections/documentation/0/segments/627217db-dfc1-44ae-903b-98ac2be735dd/MANIFEST-000005 differ diff --git a/qdrant_storage/collections/documentation/0/segments/627217db-dfc1-44ae-903b-98ac2be735dd/segment.json b/qdrant_storage/collections/documentation/0/segments/627217db-dfc1-44ae-903b-98ac2be735dd/segment.json index 334403f..ebbcf7e 100644 --- a/qdrant_storage/collections/documentation/0/segments/627217db-dfc1-44ae-903b-98ac2be735dd/segment.json +++ b/qdrant_storage/collections/documentation/0/segments/627217db-dfc1-44ae-903b-98ac2be735dd/segment.json @@ -1 +1 @@ -{"version":21,"config":{"vector_data":{"":{"size":1536,"distance":"Cosine","storage_type":"InRamChunkedMmap","index":{"type":"plain","options":{}},"quantization_config":null}},"payload_storage_type":{"type":"on_disk"}}} \ No newline at end of file +{"version":221,"config":{"vector_data":{"":{"size":1536,"distance":"Cosine","storage_type":"InRamChunkedMmap","index":{"type":"plain","options":{}},"quantization_config":null}},"payload_storage_type":{"type":"on_disk"}}} \ No newline at end of file diff --git a/qdrant_storage/collections/documentation/0/segments/627217db-dfc1-44ae-903b-98ac2be735dd/vector_storage/deleted/status.dat b/qdrant_storage/collections/documentation/0/segments/627217db-dfc1-44ae-903b-98ac2be735dd/vector_storage/deleted/status.dat index d887b78..6e47316 100644 Binary files a/qdrant_storage/collections/documentation/0/segments/627217db-dfc1-44ae-903b-98ac2be735dd/vector_storage/deleted/status.dat and b/qdrant_storage/collections/documentation/0/segments/627217db-dfc1-44ae-903b-98ac2be735dd/vector_storage/deleted/status.dat differ diff --git a/qdrant_storage/collections/documentation/0/segments/627217db-dfc1-44ae-903b-98ac2be735dd/vector_storage/vectors/chunk_0.mmap b/qdrant_storage/collections/documentation/0/segments/627217db-dfc1-44ae-903b-98ac2be735dd/vector_storage/vectors/chunk_0.mmap index f25c485..ae21983 100644 Binary files a/qdrant_storage/collections/documentation/0/segments/627217db-dfc1-44ae-903b-98ac2be735dd/vector_storage/vectors/chunk_0.mmap and b/qdrant_storage/collections/documentation/0/segments/627217db-dfc1-44ae-903b-98ac2be735dd/vector_storage/vectors/chunk_0.mmap differ diff --git a/qdrant_storage/collections/documentation/0/segments/627217db-dfc1-44ae-903b-98ac2be735dd/vector_storage/vectors/status.dat b/qdrant_storage/collections/documentation/0/segments/627217db-dfc1-44ae-903b-98ac2be735dd/vector_storage/vectors/status.dat index 3ea21ae..c347917 100644 Binary files a/qdrant_storage/collections/documentation/0/segments/627217db-dfc1-44ae-903b-98ac2be735dd/vector_storage/vectors/status.dat and b/qdrant_storage/collections/documentation/0/segments/627217db-dfc1-44ae-903b-98ac2be735dd/vector_storage/vectors/status.dat differ diff --git a/qdrant_storage/collections/documentation/0/segments/92d794e6-8a4a-4478-bcb1-55861ff3ae89/000009.sst b/qdrant_storage/collections/documentation/0/segments/92d794e6-8a4a-4478-bcb1-55861ff3ae89/000009.sst deleted file mode 100644 index c6adc4a..0000000 Binary files a/qdrant_storage/collections/documentation/0/segments/92d794e6-8a4a-4478-bcb1-55861ff3ae89/000009.sst and /dev/null differ diff --git a/qdrant_storage/collections/documentation/0/segments/92d794e6-8a4a-4478-bcb1-55861ff3ae89/000012.sst b/qdrant_storage/collections/documentation/0/segments/92d794e6-8a4a-4478-bcb1-55861ff3ae89/000012.sst deleted file mode 100644 index 044c8dd..0000000 Binary files a/qdrant_storage/collections/documentation/0/segments/92d794e6-8a4a-4478-bcb1-55861ff3ae89/000012.sst and /dev/null differ diff --git a/qdrant_storage/collections/documentation/0/segments/92d794e6-8a4a-4478-bcb1-55861ff3ae89/000014.sst b/qdrant_storage/collections/documentation/0/segments/92d794e6-8a4a-4478-bcb1-55861ff3ae89/000014.sst deleted file mode 100644 index 40b93ef..0000000 Binary files a/qdrant_storage/collections/documentation/0/segments/92d794e6-8a4a-4478-bcb1-55861ff3ae89/000014.sst and /dev/null differ diff --git a/qdrant_storage/collections/documentation/0/segments/92d794e6-8a4a-4478-bcb1-55861ff3ae89/000017.sst b/qdrant_storage/collections/documentation/0/segments/92d794e6-8a4a-4478-bcb1-55861ff3ae89/000017.sst deleted file mode 100644 index 6a82b4a..0000000 Binary files a/qdrant_storage/collections/documentation/0/segments/92d794e6-8a4a-4478-bcb1-55861ff3ae89/000017.sst and /dev/null differ diff --git a/qdrant_storage/collections/documentation/0/segments/92d794e6-8a4a-4478-bcb1-55861ff3ae89/MANIFEST-000005 b/qdrant_storage/collections/documentation/0/segments/92d794e6-8a4a-4478-bcb1-55861ff3ae89/MANIFEST-000005 index 7b43aae..9de1dcf 100644 Binary files a/qdrant_storage/collections/documentation/0/segments/92d794e6-8a4a-4478-bcb1-55861ff3ae89/MANIFEST-000005 and b/qdrant_storage/collections/documentation/0/segments/92d794e6-8a4a-4478-bcb1-55861ff3ae89/MANIFEST-000005 differ diff --git a/qdrant_storage/collections/documentation/0/segments/92d794e6-8a4a-4478-bcb1-55861ff3ae89/segment.json b/qdrant_storage/collections/documentation/0/segments/92d794e6-8a4a-4478-bcb1-55861ff3ae89/segment.json index 5952801..3eccc30 100644 --- a/qdrant_storage/collections/documentation/0/segments/92d794e6-8a4a-4478-bcb1-55861ff3ae89/segment.json +++ b/qdrant_storage/collections/documentation/0/segments/92d794e6-8a4a-4478-bcb1-55861ff3ae89/segment.json @@ -1 +1 @@ -{"version":28,"config":{"vector_data":{"":{"size":1536,"distance":"Cosine","storage_type":"InRamChunkedMmap","index":{"type":"plain","options":{}},"quantization_config":null}},"payload_storage_type":{"type":"on_disk"}}} \ No newline at end of file +{"version":220,"config":{"vector_data":{"":{"size":1536,"distance":"Cosine","storage_type":"InRamChunkedMmap","index":{"type":"plain","options":{}},"quantization_config":null}},"payload_storage_type":{"type":"on_disk"}}} \ No newline at end of file diff --git a/qdrant_storage/collections/documentation/0/segments/92d794e6-8a4a-4478-bcb1-55861ff3ae89/vector_storage/deleted/status.dat b/qdrant_storage/collections/documentation/0/segments/92d794e6-8a4a-4478-bcb1-55861ff3ae89/vector_storage/deleted/status.dat index 64b9483..6e47316 100644 Binary files a/qdrant_storage/collections/documentation/0/segments/92d794e6-8a4a-4478-bcb1-55861ff3ae89/vector_storage/deleted/status.dat and b/qdrant_storage/collections/documentation/0/segments/92d794e6-8a4a-4478-bcb1-55861ff3ae89/vector_storage/deleted/status.dat differ diff --git a/qdrant_storage/collections/documentation/0/segments/92d794e6-8a4a-4478-bcb1-55861ff3ae89/vector_storage/vectors/chunk_0.mmap b/qdrant_storage/collections/documentation/0/segments/92d794e6-8a4a-4478-bcb1-55861ff3ae89/vector_storage/vectors/chunk_0.mmap index b80f1ba..b34549a 100644 Binary files a/qdrant_storage/collections/documentation/0/segments/92d794e6-8a4a-4478-bcb1-55861ff3ae89/vector_storage/vectors/chunk_0.mmap and b/qdrant_storage/collections/documentation/0/segments/92d794e6-8a4a-4478-bcb1-55861ff3ae89/vector_storage/vectors/chunk_0.mmap differ diff --git a/qdrant_storage/collections/documentation/0/segments/92d794e6-8a4a-4478-bcb1-55861ff3ae89/vector_storage/vectors/status.dat b/qdrant_storage/collections/documentation/0/segments/92d794e6-8a4a-4478-bcb1-55861ff3ae89/vector_storage/vectors/status.dat index f1dba9d..c347917 100644 Binary files a/qdrant_storage/collections/documentation/0/segments/92d794e6-8a4a-4478-bcb1-55861ff3ae89/vector_storage/vectors/status.dat and b/qdrant_storage/collections/documentation/0/segments/92d794e6-8a4a-4478-bcb1-55861ff3ae89/vector_storage/vectors/status.dat differ diff --git a/qdrant_storage/collections/documentation/0/segments/aed6ec59-ebf0-406f-b54a-c4e518507ae8/000009.sst b/qdrant_storage/collections/documentation/0/segments/aed6ec59-ebf0-406f-b54a-c4e518507ae8/000009.sst deleted file mode 100644 index bf71b1b..0000000 Binary files a/qdrant_storage/collections/documentation/0/segments/aed6ec59-ebf0-406f-b54a-c4e518507ae8/000009.sst and /dev/null differ diff --git a/qdrant_storage/collections/documentation/0/segments/aed6ec59-ebf0-406f-b54a-c4e518507ae8/000012.sst b/qdrant_storage/collections/documentation/0/segments/aed6ec59-ebf0-406f-b54a-c4e518507ae8/000012.sst deleted file mode 100644 index b2472c4..0000000 Binary files a/qdrant_storage/collections/documentation/0/segments/aed6ec59-ebf0-406f-b54a-c4e518507ae8/000012.sst and /dev/null differ diff --git a/qdrant_storage/collections/documentation/0/segments/aed6ec59-ebf0-406f-b54a-c4e518507ae8/000014.sst b/qdrant_storage/collections/documentation/0/segments/aed6ec59-ebf0-406f-b54a-c4e518507ae8/000014.sst deleted file mode 100644 index b0f2ad4..0000000 Binary files a/qdrant_storage/collections/documentation/0/segments/aed6ec59-ebf0-406f-b54a-c4e518507ae8/000014.sst and /dev/null differ diff --git a/qdrant_storage/collections/documentation/0/segments/aed6ec59-ebf0-406f-b54a-c4e518507ae8/000017.sst b/qdrant_storage/collections/documentation/0/segments/aed6ec59-ebf0-406f-b54a-c4e518507ae8/000017.sst deleted file mode 100644 index cbab95a..0000000 Binary files a/qdrant_storage/collections/documentation/0/segments/aed6ec59-ebf0-406f-b54a-c4e518507ae8/000017.sst and /dev/null differ diff --git a/qdrant_storage/collections/documentation/0/segments/aed6ec59-ebf0-406f-b54a-c4e518507ae8/MANIFEST-000005 b/qdrant_storage/collections/documentation/0/segments/aed6ec59-ebf0-406f-b54a-c4e518507ae8/MANIFEST-000005 index bdd5ff8..83e9184 100644 Binary files a/qdrant_storage/collections/documentation/0/segments/aed6ec59-ebf0-406f-b54a-c4e518507ae8/MANIFEST-000005 and b/qdrant_storage/collections/documentation/0/segments/aed6ec59-ebf0-406f-b54a-c4e518507ae8/MANIFEST-000005 differ diff --git a/qdrant_storage/collections/documentation/0/segments/aed6ec59-ebf0-406f-b54a-c4e518507ae8/segment.json b/qdrant_storage/collections/documentation/0/segments/aed6ec59-ebf0-406f-b54a-c4e518507ae8/segment.json index 1cc41cd..4a83ad2 100644 --- a/qdrant_storage/collections/documentation/0/segments/aed6ec59-ebf0-406f-b54a-c4e518507ae8/segment.json +++ b/qdrant_storage/collections/documentation/0/segments/aed6ec59-ebf0-406f-b54a-c4e518507ae8/segment.json @@ -1 +1 @@ -{"version":23,"config":{"vector_data":{"":{"size":1536,"distance":"Cosine","storage_type":"InRamChunkedMmap","index":{"type":"plain","options":{}},"quantization_config":null}},"payload_storage_type":{"type":"on_disk"}}} \ No newline at end of file +{"version":223,"config":{"vector_data":{"":{"size":1536,"distance":"Cosine","storage_type":"InRamChunkedMmap","index":{"type":"plain","options":{}},"quantization_config":null}},"payload_storage_type":{"type":"on_disk"}}} \ No newline at end of file diff --git a/qdrant_storage/collections/documentation/0/segments/aed6ec59-ebf0-406f-b54a-c4e518507ae8/vector_storage/deleted/status.dat b/qdrant_storage/collections/documentation/0/segments/aed6ec59-ebf0-406f-b54a-c4e518507ae8/vector_storage/deleted/status.dat index d887b78..6e47316 100644 Binary files a/qdrant_storage/collections/documentation/0/segments/aed6ec59-ebf0-406f-b54a-c4e518507ae8/vector_storage/deleted/status.dat and b/qdrant_storage/collections/documentation/0/segments/aed6ec59-ebf0-406f-b54a-c4e518507ae8/vector_storage/deleted/status.dat differ diff --git a/qdrant_storage/collections/documentation/0/segments/aed6ec59-ebf0-406f-b54a-c4e518507ae8/vector_storage/vectors/chunk_0.mmap b/qdrant_storage/collections/documentation/0/segments/aed6ec59-ebf0-406f-b54a-c4e518507ae8/vector_storage/vectors/chunk_0.mmap index f44990b..cdf778e 100644 Binary files a/qdrant_storage/collections/documentation/0/segments/aed6ec59-ebf0-406f-b54a-c4e518507ae8/vector_storage/vectors/chunk_0.mmap and b/qdrant_storage/collections/documentation/0/segments/aed6ec59-ebf0-406f-b54a-c4e518507ae8/vector_storage/vectors/chunk_0.mmap differ diff --git a/qdrant_storage/collections/documentation/0/segments/aed6ec59-ebf0-406f-b54a-c4e518507ae8/vector_storage/vectors/status.dat b/qdrant_storage/collections/documentation/0/segments/aed6ec59-ebf0-406f-b54a-c4e518507ae8/vector_storage/vectors/status.dat index 3ea21ae..c347917 100644 Binary files a/qdrant_storage/collections/documentation/0/segments/aed6ec59-ebf0-406f-b54a-c4e518507ae8/vector_storage/vectors/status.dat and b/qdrant_storage/collections/documentation/0/segments/aed6ec59-ebf0-406f-b54a-c4e518507ae8/vector_storage/vectors/status.dat differ diff --git a/qdrant_storage/collections/documentation/0/segments/b85ea428-1929-4a70-828f-1f1d6fc39bc4/000009.sst b/qdrant_storage/collections/documentation/0/segments/b85ea428-1929-4a70-828f-1f1d6fc39bc4/000009.sst deleted file mode 100644 index 1763d82..0000000 Binary files a/qdrant_storage/collections/documentation/0/segments/b85ea428-1929-4a70-828f-1f1d6fc39bc4/000009.sst and /dev/null differ diff --git a/qdrant_storage/collections/documentation/0/segments/b85ea428-1929-4a70-828f-1f1d6fc39bc4/000012.sst b/qdrant_storage/collections/documentation/0/segments/b85ea428-1929-4a70-828f-1f1d6fc39bc4/000012.sst deleted file mode 100644 index 0e89248..0000000 Binary files a/qdrant_storage/collections/documentation/0/segments/b85ea428-1929-4a70-828f-1f1d6fc39bc4/000012.sst and /dev/null differ diff --git a/qdrant_storage/collections/documentation/0/segments/b85ea428-1929-4a70-828f-1f1d6fc39bc4/000014.sst b/qdrant_storage/collections/documentation/0/segments/b85ea428-1929-4a70-828f-1f1d6fc39bc4/000014.sst deleted file mode 100644 index 451e0f9..0000000 Binary files a/qdrant_storage/collections/documentation/0/segments/b85ea428-1929-4a70-828f-1f1d6fc39bc4/000014.sst and /dev/null differ diff --git a/qdrant_storage/collections/documentation/0/segments/b85ea428-1929-4a70-828f-1f1d6fc39bc4/000017.sst b/qdrant_storage/collections/documentation/0/segments/b85ea428-1929-4a70-828f-1f1d6fc39bc4/000017.sst deleted file mode 100644 index 43e7172..0000000 Binary files a/qdrant_storage/collections/documentation/0/segments/b85ea428-1929-4a70-828f-1f1d6fc39bc4/000017.sst and /dev/null differ diff --git a/qdrant_storage/collections/documentation/0/segments/b85ea428-1929-4a70-828f-1f1d6fc39bc4/MANIFEST-000005 b/qdrant_storage/collections/documentation/0/segments/b85ea428-1929-4a70-828f-1f1d6fc39bc4/MANIFEST-000005 index 1f76e9b..68d840a 100644 Binary files a/qdrant_storage/collections/documentation/0/segments/b85ea428-1929-4a70-828f-1f1d6fc39bc4/MANIFEST-000005 and b/qdrant_storage/collections/documentation/0/segments/b85ea428-1929-4a70-828f-1f1d6fc39bc4/MANIFEST-000005 differ diff --git a/qdrant_storage/collections/documentation/0/segments/b85ea428-1929-4a70-828f-1f1d6fc39bc4/segment.json b/qdrant_storage/collections/documentation/0/segments/b85ea428-1929-4a70-828f-1f1d6fc39bc4/segment.json index b638096..6e06f63 100644 --- a/qdrant_storage/collections/documentation/0/segments/b85ea428-1929-4a70-828f-1f1d6fc39bc4/segment.json +++ b/qdrant_storage/collections/documentation/0/segments/b85ea428-1929-4a70-828f-1f1d6fc39bc4/segment.json @@ -1 +1 @@ -{"version":22,"config":{"vector_data":{"":{"size":1536,"distance":"Cosine","storage_type":"InRamChunkedMmap","index":{"type":"plain","options":{}},"quantization_config":null}},"payload_storage_type":{"type":"on_disk"}}} \ No newline at end of file +{"version":222,"config":{"vector_data":{"":{"size":1536,"distance":"Cosine","storage_type":"InRamChunkedMmap","index":{"type":"plain","options":{}},"quantization_config":null}},"payload_storage_type":{"type":"on_disk"}}} \ No newline at end of file diff --git a/qdrant_storage/collections/documentation/0/segments/b85ea428-1929-4a70-828f-1f1d6fc39bc4/vector_storage/deleted/status.dat b/qdrant_storage/collections/documentation/0/segments/b85ea428-1929-4a70-828f-1f1d6fc39bc4/vector_storage/deleted/status.dat index d887b78..6e47316 100644 Binary files a/qdrant_storage/collections/documentation/0/segments/b85ea428-1929-4a70-828f-1f1d6fc39bc4/vector_storage/deleted/status.dat and b/qdrant_storage/collections/documentation/0/segments/b85ea428-1929-4a70-828f-1f1d6fc39bc4/vector_storage/deleted/status.dat differ diff --git a/qdrant_storage/collections/documentation/0/segments/b85ea428-1929-4a70-828f-1f1d6fc39bc4/vector_storage/vectors/chunk_0.mmap b/qdrant_storage/collections/documentation/0/segments/b85ea428-1929-4a70-828f-1f1d6fc39bc4/vector_storage/vectors/chunk_0.mmap index 0d66be7..f43b29f 100644 Binary files a/qdrant_storage/collections/documentation/0/segments/b85ea428-1929-4a70-828f-1f1d6fc39bc4/vector_storage/vectors/chunk_0.mmap and b/qdrant_storage/collections/documentation/0/segments/b85ea428-1929-4a70-828f-1f1d6fc39bc4/vector_storage/vectors/chunk_0.mmap differ diff --git a/qdrant_storage/collections/documentation/0/segments/b85ea428-1929-4a70-828f-1f1d6fc39bc4/vector_storage/vectors/status.dat b/qdrant_storage/collections/documentation/0/segments/b85ea428-1929-4a70-828f-1f1d6fc39bc4/vector_storage/vectors/status.dat index 3ea21ae..c347917 100644 Binary files a/qdrant_storage/collections/documentation/0/segments/b85ea428-1929-4a70-828f-1f1d6fc39bc4/vector_storage/vectors/status.dat and b/qdrant_storage/collections/documentation/0/segments/b85ea428-1929-4a70-828f-1f1d6fc39bc4/vector_storage/vectors/status.dat differ diff --git a/qdrant_storage/collections/documentation/0/wal/first-index b/qdrant_storage/collections/documentation/0/wal/first-index index bdf7e09..d8af278 100644 --- a/qdrant_storage/collections/documentation/0/wal/first-index +++ b/qdrant_storage/collections/documentation/0/wal/first-index @@ -1 +1 @@ -{"ack_index":28} \ No newline at end of file +{"ack_index":226} \ No newline at end of file diff --git a/qdrant_storage/collections/documentation/0/wal/open-1 b/qdrant_storage/collections/documentation/0/wal/open-1 index 83e4e4e..c14408b 100644 Binary files a/qdrant_storage/collections/documentation/0/wal/open-1 and b/qdrant_storage/collections/documentation/0/wal/open-1 differ