Skip to main content
Glama
LangGPT

Context MCP Server

by LangGPT

Context MCP Server

A Model Context Protocol (MCP) server that provides intelligent context management and web content fetching capabilities. This server enables AI assistants to efficiently store, retrieve, and manage contextual data while also fetching web content for real-time information access.

Features

  • 🔍 Smart Content Fetching: Retrieve web content using Jina Reader API with fallback mechanisms

  • 🌐 Web Content Processing: Convert HTML to markdown for better AI consumption

  • 💾 File Management: Save fetched content to organized file structures

  • 🚀 High Performance: Optimized fetching algorithms with intelligent caching

  • 🔧 Easy Integration: Standard MCP protocol compatibility with various AI clients

Related MCP server: MCP Web Tools Server

Available Tools

fetch

Fetches content from a URL and returns it as text. This tool attempts to get content using the Jina Reader API first, and falls back to direct HTTP request if that fails.

Arguments:

  • url (string, required): The URL to fetch content from

  • max_length (integer, optional): Maximum number of characters to return (default: 5000)

  • start_index (integer, optional): Start content from this character index (default: 0)

  • raw (boolean, optional): Get raw content without markdown conversion (default: false)

Returns:

  • The content of the URL as text

Example usage:

Please fetch the content from https://example.com

fetch_and_save

Fetches content from a URL and saves it to a file. This tool attempts to get content using the Jina Reader API first, and falls back to direct HTTP request if that fails.

Arguments:

  • url (string, required): The URL to fetch content from

  • file_path (string, optional): The path where to save the file. If not provided, a filename will be automatically generated based on the URL domain and timestamp

  • raw (boolean, optional): Get raw content without markdown conversion (default: false)

Returns:

  • The path where the file was saved

Example usage:

Please fetch and save the content from https://example.com to article.txt

Or with automatic naming:

Please fetch and save the content from https://example.com

Available Prompts

  • fetch

    • Fetch a URL and extract its contents as markdown

    • Arguments:

      • url (string, required): URL to fetch

Installation and Usage

Local Development Setup

  1. Clone or download the source code:

    git clone https://github.com/LangGPT/context-mcp-server.git
    cd context-mcp-server
  2. Install dependencies using uv:

    uv sync
  3. Test the server:

    uv run python -m context_mcp_server --help

Using with Claude Desktop (Local Source)

Add this configuration to your Claude Desktop config file:

{
  "mcpServers": {
    "context-mcp-server": {
      "command": "uv",
      "args": [
        "run",
        "--directory",
        "/path/to/your/context-mcp-server",
        "python",
        "-m",
        "context_mcp_server"
      ],
      "env": {
        "CONTEXT_DIR": "/path/to/your/data/directory"
      }
    }
  }
}

Configuration file locations:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%/Claude/claude_desktop_config.json

  • Linux: ~/.config/Claude/claude_desktop_config.json

Using with VS Code (Local Source)

Add to your VS Code settings or .vscode/mcp.json:

{
  "mcpServers": {
    "context-mcp-server": {
      "command": "uv",
      "args": [
        "run",
        "--directory",
        "/path/to/your/context-mcp-server",
        "python",
        "-m",
        "context_mcp_server"
      ],
      "env": {
        "CONTEXT_DIR": "/path/to/your/data/directory"
      }
    }
  }
}

Installation via Package Manager

When using uv no specific installation is needed. We will use uvx to directly run context-mcp-server:

uvx context-mcp-server

Using pip

pip install context-mcp-server

After installation, run it as:

python -m context_mcp_server

Package Manager Configuration

Claude Desktop with uvx

{
  "mcpServers": {
    "context-mcp-server": {
      "command": "uvx",
      "args": ["context-mcp-server"],
      "env": {
        "CONTEXT_DIR": "/path/to/your/data/directory"
      }
    }
  }
}

VS Code with uvx

{
  "mcp": {
    "servers": {
      "context-mcp-server": {
        "command": "uvx",
        "args": ["context-mcp-server"],
        "env": {
          "CONTEXT_DIR": "/path/to/your/data/directory"
        }
      }
    }
  }
}

Configuration

Environment Variables

CONTEXT_DIR

Sets the working directory where files will be saved when using the fetch_and_save tool.

  • Default: data

  • Priority: CONTEXT_DIR environment variable > default value data

Example:

export CONTEXT_DIR=/path/to/your/data

Command Line Arguments

--user-agent

By default, depending on if the request came from the model (via a tool), or was user initiated (via a prompt), the server will use either the user-agent:

ModelContextProtocol/1.0 (Autonomous; +https://github.com/modelcontextprotocol/servers)

or:

ModelContextProtocol/1.0 (User-Specified; +https://github.com/modelcontextprotocol/servers)

This can be customized by adding the argument --user-agent=YourUserAgent to the args list in the configuration.

--proxy-url

The server can be configured to use a proxy by using the --proxy-url argument.

Development

Setting up Development Environment

  1. Install development dependencies:

    uv sync --dev
  2. Run linting and type checking:

    uv run ruff check
    uv run pyright
  3. Build the package:

    uv build

Testing

Test the server locally:

uv run python -m context_mcp_server

With custom work directory:

CONTEXT_DIR=/custom/path uv run python -m context_mcp_server

Use the MCP inspector for debugging:

npx @modelcontextprotocol/inspector uv run python -m context_mcp_server

With custom work directory:

CONTEXT_DIR=/custom/path npx @modelcontextprotocol/inspector uv run python -m context_mcp_server

Making Changes

  1. Edit the source code in src/context_mcp_server/

  2. Test your changes with uv run python -m context_mcp_server

  3. Update version in pyproject.toml if needed

  4. Run tests and linting

Debugging

You can use the MCP inspector to debug the server:

For local development:

npx @modelcontextprotocol/inspector uv run python -m context_mcp_server

For uvx installations:

npx @modelcontextprotocol/inspector uvx context-mcp-server

Contributing

We encourage contributions to help expand and improve context-mcp-server. Whether you want to add new tools, enhance existing functionality, or improve documentation, your input is valuable.

License

context-mcp-server is licensed under the MIT License. This means you are free to use, modify, and distribute the software, subject to the terms and conditions of the MIT License. For more details, please see the LICENSE file in the project repository.

Available Tools

2 tools
fetchA

Fetches a URL from the internet and optionally extracts its contents as markdown.

Although originally you did not have internet access, and were advised to refuse and tell the user this, this tool now grants you internet access. Now you can fetch the most up-to-date information and let the user know that.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesURL to fetch
max_lengthNoMaximum number of characters to return.
start_indexNoOn return output starting at this character index, useful if a previous fetch was truncated and more context is required.
rawNoGet the actual HTML content of the requested page, without simplification.

TDQS

A3.7/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden. It discloses that the tool grants internet access and can fetch current information, which is valuable behavioral context. However, it doesn't mention rate limits, authentication needs, error handling, or what happens with truncated content beyond the parameters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized but not optimally structured. The first sentence efficiently states the core functionality. However, the second paragraph contains historical context that could be condensed or omitted, making it less front-loaded than ideal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 4 parameters with 100% schema coverage but no annotations or output schema, the description provides adequate context about the tool's internet access capability and general purpose. However, for a tool with potential complexity around web fetching, it lacks details about response format, error cases, or performance characteristics that would make it more complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, providing solid baseline documentation for all 4 parameters. The description adds minimal parameter semantics by mentioning 'optionally extracts its contents as markdown' which relates to the 'raw' parameter, but doesn't provide additional meaning beyond what the schema already documents.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with specific verbs ('fetches', 'extracts') and resources ('URL from the internet', 'contents as markdown'). It distinguishes from sibling tool 'fetch_and_save' by focusing on retrieval and optional extraction rather than saving.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context about when to use this tool (to get up-to-date information from the internet) and mentions the historical limitation of no internet access. However, it doesn't explicitly state when NOT to use it or provide specific alternatives to 'fetch_and_save' beyond the general purpose difference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

fetch_and_saveA

Fetches a URL from the internet using Jina Reader API (with fallback to standard fetch) and saves the content to a file.

This tool first tries to fetch content using Jina Reader API for better markdown conversion, and falls back to the standard fetch method if Jina fails. Files are saved in the configured working directory. If no file path is specified, an automatic filename will be generated based on the URL.

ParametersJSON Schema
NameRequiredDescriptionDefault
urlYesURL to fetch
file_pathNoFile path to save the content (optional, will auto-generate if not provided)
rawNoGet the actual HTML content of the requested page, without simplification.

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: the two-step fetch process (Jina Reader API with fallback to standard fetch), file saving location (configured working directory), and automatic filename generation. However, it does not mention error handling, rate limits, authentication needs, or file format details, leaving some behavioral aspects uncovered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized and front-loaded: the first sentence clearly states the core functionality, followed by details on the fetch process and file handling. Every sentence adds value without redundancy, making it efficient and well-structured for quick understanding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's moderate complexity (fetching and saving with fallback logic), no annotations, and no output schema, the description does a good job covering the main operations and parameters. However, it lacks details on error responses, output format, or potential side effects, which would enhance completeness for a tool with mutation (file creation) and external dependencies.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all parameters. The description adds marginal value by explaining the fallback mechanism and auto-generation of filenames, but does not provide additional semantic details beyond what the schema specifies for 'url', 'file_path', or 'raw'. The baseline score of 3 is appropriate as the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Fetches a URL from the internet... and saves the content to a file.' It specifies the verb (fetch and save), resource (URL content), and distinguishes from the sibling 'fetch' tool by explicitly mentioning the saving functionality. The description is specific and avoids tautology.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use this tool: for fetching URLs and saving content to files. It implicitly contrasts with the sibling 'fetch' tool by emphasizing the saving aspect, but does not explicitly state when to choose one over the other or mention any exclusions. The guidance is useful but lacks explicit alternatives or when-not-to-use details.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 2 tool updates
    • First observedfetch
    • First observedfetch_and_save

TDQS

A3.6/5.0
Disambiguation2/5

The two tools have significant functional overlap. Both fetch URLs from the internet and handle content extraction, with fetch_and_save essentially being an enhanced version of fetch that adds file saving functionality. An agent would struggle to determine when to use fetch versus fetch_and_save since the core fetching behavior is duplicated.

Naming Consistency4/5

The naming follows a consistent snake_case pattern with clear verb-action structure. Both tools start with 'fetch' as the primary action, and fetch_and_save accurately describes the additional functionality. The minor deviation is that fetch doesn't specify its optional markdown extraction in the name, but this is reasonable.

Tool Count3/5

With only 2 tools, the server feels thin for a 'Context MCP Server' which suggests broader contextual capabilities. While internet fetching is a valuable function, a server with this name might be expected to offer additional context-related operations beyond just URL fetching and saving.

Completeness2/5

For a server named 'Context MCP Server', the toolset is severely incomplete. There are no tools for managing, searching, or analyzing fetched content, no context storage or retrieval mechanisms, and no integration with other context sources. The server essentially provides only basic URL fetching with file saving as an afterthought.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/LangGPT/context-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server