Skip to main content

RFC

StaticMCP - Static Model Context Protocol​

Version: 0.1

Status: Draft

Date: 2025-08-06

Abstract​

This document defines StaticMCP, an extension to the Model Context Protocol (MCP) that enables serving AI model context through pre-generated static files rather than dynamic server applications. StaticMCP maintains full compatibility with the MCP specification while offering significant improvements in performance, cost, scalability, and deployment simplicity.

1. Introduction​

1.1 Background​

The Model Context Protocol (MCP) provides a standardized interface for AI models to interact with external tools and resources. However, many use cases involve serving relatively static data that doesn't require real-time computation or database queries. Traditional MCP implementations in these scenarios introduce unnecessary complexity and operational overhead.

1.2 Motivation​

StaticMCP addresses several key challenges:

  • Performance: Eliminates runtime computation for faster response times
  • Cost: Reduces infrastructure requirements to static file hosting
  • Reliability: Removes server-side failure points and scaling bottlenecks
  • Simplicity: Enables deployment to any static hosting platform
  • Caching: Leverages existing web caching infrastructure at all levels

1.3 Scope​

This RFC defines:

  • The StaticMCP file structure and organization
  • Mapping between MCP operations and static file paths
  • Bridge server requirements and behavior
  • Compatibility requirements with existing MCP clients

2. Architecture Overview​

2.1 Core Principles​

StaticMCP operates on four fundamental principles:

  1. Pre-computation: All responses are generated at build time
  2. File-based mapping: MCP operations map directly to file system paths
  3. Standard compliance: Full compatibility with MCP protocol semantics
  4. Web-native: Leverages standard HTTP caching and CDN capabilities

2.2 System Components​

  1. Generator Tools: Scripts/applications that create static files
  2. Build Process: Orchestrates file generation and validation
  3. Static File Host: Standard web server or CDN hosting JSON files
  4. StaticMCP Bridge: Lightweight proxy translating MCP to HTTP requests
  5. MCP Client: Standard MCP client (AI models, applications)

3. File Structure Specification​

3.1 Directory Layout​

staticmcp-root/
  ├── mcp.json                     # Server manifest
  ├── resources/                   # Resource responses
  │     ├── {encoded-uri}.json     # Individual resource files
  │     └── index.json             # Resource listing
  └── tools/                       # Tool call responses
        └── {tool-name}/           # Tool-specific directory
              └── {arg}.json       # Parameterized responses

3.2 Manifest File (mcp.json)​

The root manifest file defines server capabilities:

{
  "protocolVersion": "2025-06-18",
  "serverInfo": {
    "name": "My StaticMCP Server",
    "version": "1.0.0"
  },
  "capabilities": {
    "resources": [
      {
        "uri": "file://README.md",
        "name": "Project README",
        "description": "Main project documentation",
        "mimeType": "text/markdown"
      }
    ],
    "tools": [
      {
        "name": "search",
        "description": "Search through project content",
        "inputSchema": {
          "type": "object",
          "properties": {
            "query": {
              "type": "string",
              "description": "Search query"
            }
          },
          "required": ["query"]
        }
      }
    ]
  }
}

4. Request Mapping​

4.1 Resource Requests​

MCP resource requests map to files in the resources/ directory:

MCP RequestFile Path
resources/read with URI file://README.mdresources/README.md.json
resources/read with URI web://docs/apiresources/docs/api.json

4.1.1 URI Encoding Rules​

  1. Remove everything before :// (inclusive)
  2. / refers to directory
  3. No special characters allowed
  4. Ensure resulting filename is valid for target file system

4.2 Tool Requests​

Tool calls map to files in the tools/{tool-name}/ directory:

Tool CallFile Path
search("rust")tools/search/rust.json

5. Response Format​

5.1 Resource Response Files​

{
  "uri": "file://README.md",
  "mimeType": "text/markdown",
  "text": "# My Project\n\nThis is the project README..."
}

5.2 Tool Response Files​

{
  "content": [
    {
      "type": "text",
      "text": "Found 3 results for 'rust':\n1. Rust implementation guide\n2. Rust vs Python comparison\n3. Memory safety in Rust"
    }
  ]
}

6. Bridge Server Specification​

6.1 Requirements​

The StaticMCP bridge server MUST:

  1. Accept standard MCP JSON-RPC requests
  2. Translate requests to appropriate file paths
  3. Return standard MCP responses
  4. Handle file not found cases gracefully
  5. Support proper HTTP caching headers

6.2 Error Handling​

ScenarioHTTP StatusMCP Response
File not found404Resource/tool not available error
Invalid JSON500Internal server error
Bridge unavailable503Service temporarily unavailable

7. Generation Process​

7.1 Build Pipeline​

  1. Data Collection: Gather source data from various inputs
  2. Response Generation: Create individual JSON response files
  3. Manifest Creation: Generate the root mcp.json file
  4. Validation: Verify file structure and JSON validity
  5. Optimization: Compress and optimize files for delivery
  6. Deployment: Upload to static hosting platform

7.2 Incremental Updates​

For efficiency, generators SHOULD support incremental builds:

  1. Track file modification times
  2. Maintain dependency graphs
  3. Only regenerate changed files
  4. Update manifest with new timestamps

8. Security Considerations​

8.1 File System Safety​

  • Validate all generated file names to prevent directory traversal
  • Sanitize user input used in file path generation
  • Implement appropriate file size limits

8.2 Content Security​

  • Validate JSON schema compliance for all generated files
  • Implement content scanning for sensitive information
  • Use secure random number generation for parameter hashing

8.3 Read-only Access​

  • Files are read-only and cannot be amended by external request
  • For write access support, consider a hybrid approach

9. Performance Considerations​

9.1 File Organization​

  • Limit directory fan-out to prevent file system performance issues
  • Use appropriate file naming schemes for efficient lookup
  • Consider file size limits for optimal CDN performance

9.2 Caching Strategy​

  • Implement aggressive caching at all levels
  • Use content-based ETags for cache validation
  • Consider pre-warming CDN caches for frequently accessed files

10. Compatibility​

StaticMCP implementations MUST maintain full semantic compatibility with the MCP specification. Clients should not be able to distinguish between dynamic and static MCP servers based on response content.

11. References​