Which integrations are available for this server?

Provides tools to fetch and manage context files from GitHub repositories, supporting both public and private repositories via personal access tokens.

How do I use Context File MCP Service?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Context File MCP Service Show me all context files tagged 'api'" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Context File MCP Service

by yrstruely

Overview Schema Related Servers Score Discussions

JavaScript

Context File MCP Service

A powerful Model Context Protocol (MCP) service for managing AI context files from local directories and GitHub repositories. Provides intelligent file watching, tag-based organization, and full-text search capabilities.

Features

✨ Dual Source Support

Read from local filesystem directories
Fetch from GitHub repositories (public and private)

🔍 File Watching

Automatic detection of file changes (add, modify, delete)
Real-time metadata and index updates
Efficient monitoring with minimal overhead

🏷️ Smart Tagging & Categorization

Extract tags from YAML frontmatter
Parse inline hashtags from content
Fast tag-based file discovery
Metadata extraction (title, description, tags)

🔎 Full-Text Search

Search across all context files
Relevance-based ranking
Filter by tags and sources
Context snippets in results

🚀 Optimized Performance

Intelligent caching
Incremental updates
Support for large repositories

Related MCP server: membot

Installation

Prerequisites

Node.js 18+
npm or yarn

Setup

Clone or download the service:

mkdir context-file-mcp
cd context-file-mcp

Install dependencies:

npm install @modelcontextprotocol/sdk@^0.5.0 @octokit/rest@^20.0.0 chokidar@^3.5.3

Create package.json:

{
  "name": "context-file-mcp",
  "version": "2.0.0",
  "type": "module",
  "bin": {
    "context-file-mcp": "./index.ts"
  },
  "dependencies": {
    "@modelcontextprotocol/sdk": "^0.5.0",
    "@octokit/rest": "^20.0.0",
    "chokidar": "^3.5.3"
  }
}

Save the service code as index.ts
Make it executable:

chmod +x index.ts

Configuration

For Claude Desktop

Add to your claude_desktop_config.json:

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

Windows: %APPDATA%\Claude\claude_desktop_config.json

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

{
  "mcpServers": {
    "context-files": {
      "command": "node",
      "args": ["/absolute/path/to/context-file-mcp/index.ts"]
    }
  }
}

For Claude Code

Add to your MCP settings:

macOS/Linux: ~/.config/claude-code/mcp_settings.json

Windows: %APPDATA%\claude-code\mcp_settings.json

{
  "mcpServers": {
    "context-files": {
      "command": "node",
      "args": ["/absolute/path/to/context-file-mcp/index.ts"]
    }
  }
}

Usage

Adding Sources

Local Directory:

Add a local source called 'project-docs' from /Users/me/project/docs with watching enabled

GitHub Repository:

Add a GitHub source called 'team-context' from owner 'mycompany' repo 'ai-context' path 'docs' with token 'ghp_...'

Managing Context Files

List Sources:

Show me all configured sources

List Files:

List all context files in 'project-docs'

Read Files:

Read the authentication.md context file from 'project-docs'

Read Multiple Files:

Read these context files from 'project-docs': authentication.md, database.md, api-guidelines.md

Search & Discovery

Full-Text Search:

Search for 'authentication flow' in my context files

Search with Tag Filter:

Search for 'database' in files tagged 'backend'

List All Tags:

Show me all available tags

Find by Tag:

Show me all context files tagged 'api'

Get Metadata:

What are the tags and description for api-guidelines.md in 'project-docs'?

Maintenance

Refresh File List:

Refresh the file list for 'project-docs'

Stop Watching:

Stop watching 'project-docs' for changes

Context File Format

Create context files with YAML frontmatter for optimal organization:

---
title: Authentication Guide
description: OAuth2 and JWT implementation guidelines
tags: [auth, security, api, backend]
---

# Authentication Guide

This guide covers our authentication approach using OAuth2 and JWT.

## OAuth2 Flow

Use #oauth2 for third-party authentication...

## JWT Tokens

Implement #jwt for session management...

Supported Formats

Frontmatter tags: tags: [tag1, tag2, tag3]
Array format:
```
tags:
  - tag1
  - tag2
```
Inline hashtags: #tag1 #tag2 within content

File Extensions

The service automatically detects these file types:

.md - Markdown files
.mdx - MDX files
.txt - Plain text files
.context - Context-specific files

API Reference

Tools

`add_source`

Add a new context file source.

Parameters:

name (string, required): Identifier for the source
type (string, required): "local" or "github"
path (string, required): Directory path or GitHub repo path
watch (boolean, optional): Enable file watching (local only)
githubToken (string, optional): GitHub PAT for private repos
owner (string, required for GitHub): Repository owner
repo (string, required for GitHub): Repository name
branch (string, optional): Branch name (default: "main")

`list_sources`

List all configured sources.

`list_files`

List files in a source.

Parameters:

source (string, required): Source name

`read_context_file`

Read a single context file.

Parameters:

source (string, required): Source name
file (string, required): File path

`read_multiple_context_files`

Read multiple context files.

Parameters:

source (string, required): Source name
files (array, required): Array of file paths

`search_context_files`

Search across context files.

Parameters:

query (string, required): Search query
tags (array, optional): Filter by tags
source (string, optional): Limit to specific source

`list_tags`

List all available tags.

`get_files_by_tag`

Get files with a specific tag.

Parameters:

tag (string, required): Tag name

`get_file_metadata`

Get metadata for a file.

Parameters:

source (string, required): Source name
file (string, required): File path

`refresh_file_list`

Force refresh file cache.

Parameters:

source (string, required): Source name

`stop_watching`

Stop watching a source.

Parameters:

source (string, required): Source name

Resources

Context files are exposed as MCP resources with URIs:

context://<source-name>/<file-path>

Example: context://project-docs/auth/oauth2.md

Resources include metadata:

tags: Array of tags
title: File title (from frontmatter)
description: File description (from frontmatter)

GitHub Authentication

For private repositories, create a GitHub Personal Access Token (PAT):

Go to GitHub Settings → Developer settings → Personal access tokens → Tokens (classic)
Generate new token with repo scope
Use the token when adding a GitHub source

Security Note: Store tokens securely. Consider using environment variables:

{
  "mcpServers": {
    "context-files": {
      "command": "node",
      "args": ["/path/to/index.ts"],
      "env": {
        "GITHUB_TOKEN": "ghp_..."
      }
    }
  }
}

Then modify the service to read from process.env.GITHUB_TOKEN.

Use Cases

Documentation Assistant

Keep all project documentation in context for accurate answers:

"Using the API guidelines and authentication docs, help me implement a new endpoint"

Coding Standards Enforcement

Reference style guides and best practices:

"Review this code against our coding standards in 'standards/typescript.md'"

Knowledge Base

Build a searchable knowledge base:

"Search for 'deployment pipeline' across all documentation"

Multi-Project Context

Manage contexts for multiple projects:

Add local source 'project-a-docs' from /projects/a/docs
Add local source 'project-b-docs' from /projects/b/docs

Team Collaboration

Share context via GitHub:

Add GitHub source 'team-kb' from owner 'company' repo 'knowledge-base' path 'context'

Troubleshooting

Files Not Appearing

Check file extensions: Only .md, .txt, .context, and .mdx files are indexed
Verify path: Ensure the path is absolute and accessible
Refresh cache: Use refresh_file_list to force update

File Watching Not Working

Local sources only: File watching only works for local directories
Enable watching: Ensure watch: true when adding source
Check permissions: Verify read access to the directory

GitHub Connection Issues

Check token: Ensure PAT has repo scope
Verify repository: Confirm owner and repo names
Branch name: Default is "main", specify if different
Rate limits: GitHub API has rate limits; consider caching

Search Not Finding Files

Refresh source: Run refresh_file_list to update indexes
Check tags: Ensure files have proper frontmatter
Case sensitivity: Searches are case-insensitive but check spelling

Performance Tips

Enable caching: File lists and metadata are cached automatically
Use file watching: Avoid manual refreshes with automatic updates
Tag organization: Well-tagged files improve search performance
Limit scope: Search specific sources when possible
GitHub rate limits: Cache aggressively for GitHub sources

Contributing

Contributions are welcome! Areas for improvement:

Additional metadata extraction
Custom file type support
Advanced search operators
Workspace integration
Export/import configurations

License

MIT License - feel free to use and modify as needed.

Support

For issues and questions:

Check the troubleshooting section
Review Claude's MCP documentation: https://docs.claude.com
File issues on your repository

Version History

v2.0.0

Added file watching with chokidar
Implemented tag indexing and categorization
Added full-text search with relevance ranking
Metadata extraction from frontmatter
Enhanced error handling

v1.0.0

Initial release
Local and GitHub source support
Basic file reading
MCP tools and resources integration

Available Tools

9 tools

add_sourceB

Add a context file source (local directory or GitHub repository)

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Name to identify this source
`path`	Yes	Path to context files (local directory path or GitHub repo path)
`repo`	No	GitHub repository name (required for GitHub)
`type`	Yes	Type of source: local directory or GitHub repository
`owner`	No	GitHub repository owner (required for GitHub)
`watch`	No	Enable file watching for automatic updates (local sources only)
`branch`	No	GitHub branch name (defaults to 'main')
`githubToken`	No	GitHub personal access token (required for GitHub)

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are present, so the description bears the full burden of disclosing behavioral traits. It only states 'add a context file source' without explaining side effects, authorization needs, validation behavior, or whether adding triggers immediate file indexing.

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

Conciseness4/5

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

The description is a single concise sentence that directly states the tool's purpose. While very brief, it is not verbose and every word contributes meaning. Could benefit from slightly more structure.

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

Completeness2/5

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

Given the tool's complexity (8 parameters, conditional requirements for GitHub vs local, a 'watch' feature), the description is underspecified. It lacks context on return values, error handling, and behavioral details that are not covered by the schema alone.

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?

All 8 parameters have descriptions in the schema (100% coverage). The description adds no additional meaning beyond what the schema already provides, so the baseline score of 3 applies.

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 uses the specific verb 'Add' and clearly identifies the resource as a 'context file source'. It further specifies the two possible types (local directory or GitHub repository), which distinguishes it from sibling tools like list_sources or refresh_file_list.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives is provided. The description does not mention when not to use it, prerequisites, or which sibling might be more appropriate in certain scenarios.

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

get_file_metadataB

Get metadata (tags, title, description) for a context file

ParametersJSON Schema

Name	Required	Description	Default
`file`	Yes	Path to the file
`source`	Yes	Name of the source

TDQS

B3.4/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits like read-only nature, error handling, or permission requirements. The description carries the full burden but fails to add transparency beyond the basic operation.

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?

Single sentence conveying core functionality with no extraneous words. Efficiently communicates purpose and return content.

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?

For a simple metadata retrieval tool with full schema coverage, the description is largely complete. It could mention default behavior for missing files or partial metadata, but overall it adequately covers the main use case.

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 coverage is 100% with clear parameter descriptions. The tool description does not add additional meaning beyond the schema, so baseline score of 3 is appropriate.

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 verb 'Get', the resource 'metadata (tags, title, description)', and the target 'context file'. It distinguishes from siblings like read_context_file (content) and get_files_by_tag (file retrieval by tag).

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives such as read_context_file or search_context_files. The description only states functionality without context for selection.

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

get_files_by_tagB

Get all context files with a specific tag

ParametersJSON Schema

Name	Required	Description	Default
`tag`	Yes	Tag to search for

TDQS

B3/5.0

Behavior2/5

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

No annotations provided, and the description discloses no behavioral traits (e.g., read-only, pagination, empty results). The agent cannot infer side effects or constraints beyond basic purpose.

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?

Single sentence is very concise but lacks necessary details like return value or usage context. It is not overly verbose, but could include more information without losing conciseness.

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

Completeness2/5

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

No output schema and no annotations; description fails to mention return value format (e.g., file paths or objects) or behavior when no files match. Incomplete for a simple tool.

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?

Input schema has 100% coverage for the single 'tag' parameter with a clear description. The tool description does not add further meaning, so baseline score of 3 applies.

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?

Description clearly states the verb 'Get' and resource 'context files' with qualification 'with a specific tag', distinguishing it from siblings like list_files (all files) and search_context_files (broader search).

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives like search_context_files. No when-not or prerequisites mentioned, leaving the agent without usage context.

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

list_filesB

List all context files available in a source

ParametersJSON Schema

Name	Required	Description	Default
`source`	Yes	Name of the source to list files from

TDQS

B3.3/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It states a read-only operation but does not disclose any behavioral traits such as pagination, sorting, or recursion. The description is adequate but minimal.

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 a single, concise sentence that directly states the tool's purpose. No wasted words.

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?

With multiple siblings and no output schema, the description is not fully complete. It lacks details on output format and does not help distinguish from similar tools.

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 has 100% description coverage for the single parameter 'source'. The description adds no extra meaning beyond the schema, meeting the baseline for full coverage.

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

Purpose4/5

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

The description clearly states the verb 'list' and resource 'context files' with a scope 'in a source'. However, it does not explicitly differentiate from siblings like 'search_context_files' or 'get_files_by_tag', which also list files but with filtering.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus its siblings. An explicit statement like 'when you need all files without filtering' would help.

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

list_sourcesA

List all configured context file sources

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only states it lists sources. No details on read-only nature, side effects, or authorization requirements are provided.

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?

Single sentence is concise, front-loads the core action, and contains no redundant information.

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?

Description is minimal but adequate for a simple list tool. However, it lacks specification of output format or expectations, which would improve completeness.

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

Parameters4/5

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

No parameters exist, so description adds no parameter-specific meaning. Baseline score of 4 applies due to zero parameters and full schema coverage.

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?

Description clearly states the action (list) and the resource (all configured context file sources), distinguishing it from sibling tools like list_files (files) and add_source (addition).

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives such as list_files or search_context_files. The description does not mention exclusions or context.

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

read_context_fileB

Read the contents of a specific context file

ParametersJSON Schema

Name	Required	Description	Default
`file`	Yes	Path to the file within the source
`source`	Yes	Name of the source

TDQS

B3/5.0

Behavior2/5

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

Without annotations, the description should disclose behavioral traits, but it only states 'Read the contents'. It does not mention whether the operation is safe, what encoding is returned, or any error conditions. Minimal transparency.

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 a single sentence with no extraneous words, but it is too minimal. It could include more structured information without becoming verbose.

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

Completeness2/5

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

With no output schema, the description should explain what the tool returns, but it does not. The tool has two required parameters and siblings, yet the description lacks completeness for effective use.

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 coverage is 100%, so both parameters are described in the input schema. The description adds no extra meaning beyond the schema, meeting the baseline expectation.

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 verb 'Read' and the resource 'context file', with 'specific' distinguishing it from siblings that list or search. It effectively conveys the tool's function.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like 'read_multiple_context_files' or 'get_file_metadata'. The agent is left without context for tool selection.

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

read_multiple_context_filesC

Read multiple context files at once

ParametersJSON Schema

Name	Required	Description	Default
`files`	Yes	Array of file paths to read
`source`	Yes	Name of the source

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, and the description lacks behavioral details such as error handling, file existence behavior, limit on number of files, or whether it fails fast or continues on errors. This is insufficient for a batch operation.

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

Conciseness4/5

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

The description is a single concise sentence with no redundancy. It is front-loaded and earns its place, though it could be slightly expanded with key details without losing conciseness.

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 the simplicity of the tool (2 params, no output schema, no annotations), the description is minimally adequate. However, it lacks context on file existence handling, source meaning, and batch behavior, making it incomplete for full agent decision-making.

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% with both parameters described. The description adds no additional meaning beyond the schema, such as clarifying what 'source' represents or how file paths are resolved. Baseline 3 due to high coverage without extra value.

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

Purpose4/5

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

The description clearly states the verb 'read' and the resource 'multiple context files', indicating batch reading. However, it does not explicitly differentiate from the sibling tool 'read_context_file' which reads a single file.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'read_context_file' for single file or 'search_context_files'. No contextual or exclusionary information is given.

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

refresh_file_listB

Refresh the cached list of files for a source

ParametersJSON Schema

Name	Required	Description	Default
`source`	Yes	Name of the source to refresh

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided, and the description does not disclose behavioral traits such as whether the operation is destructive, requires authentication, or has rate limits. 'Refresh' implies a cache update but lacks detail.

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

Conciseness4/5

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

The description is a single, concise sentence with no unnecessary words. It could be slightly more informative but is appropriately sized.

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

Completeness2/5

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

Given low complexity, the description is too minimal. It does not explain the return value, side effects, or when the refresh is needed. Lacks completeness for a tool with no output schema and no annotations.

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 coverage is 100% with a clear description for the single parameter 'source'. The description adds no additional meaning beyond the schema, earning the baseline score.

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 action (refresh) and the resource (cached list of files for a source). It distinguishes from sibling tools like list_files which lists files without refreshing.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool vs alternatives. It implies usage for refreshing after changes, but does not explain when not to use it or mention alternative methods like list_files.

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

search_context_filesC

Search across context files with optional tag filtering

ParametersJSON Schema

Name	Required	Description
`tags`	No	Filter by tags (optional)
`query`	Yes	Search query string
`source`	No	Limit search to specific source (optional)

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but fails to disclose behavioral traits like read-only nature, authentication needs, or rate limits. It gives no indication of side effects or safe usage assumptions.

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

Conciseness4/5

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

The description is a single, concise sentence that front-loads the core purpose. It is efficient with no wasted words, but could benefit from slight expansion on return value without losing conciseness.

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

Completeness2/5

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

Given the absence of an output schema, the description is incomplete as it does not explain what the search returns (e.g., file paths, contents, or metadata). This leaves the agent guessing about the output format and usability.

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 coverage is 100% with adequate descriptions for all three parameters. The description adds only a mention of 'optional tag filtering' which aligns with the tags parameter, providing minimal extra meaning beyond the schema.

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

Purpose4/5

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

The description clearly states 'Search across context files' with optional tag filtering, which differentiates it from sibling tools like list_files, get_files_by_tag, and read_context_file. However, it does not specify whether it returns file paths, content snippets, or metadata, slightly reducing clarity.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives such as get_files_by_tag for tag-heavy queries or list_files for enumeration. The description does not mention prerequisites, limitations, or contextual triggers.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.6/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: listing, reading (single and multiple), searching, retrieving by tag, fetching metadata, refreshing cache, and managing sources. No overlapping functionalities that would cause misselection.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case (e.g., list_files, read_context_file, add_source). The naming convention is uniform and predictable across all 9 tools.

Tool Count5/5

With 9 tools, the set is well-scoped for a context file management service. Each tool covers a necessary operation without redundancy or excessive granularity.

Completeness5/5

The tool surface covers the full lifecycle for context files: browsing sources, listing files, reading content (single and batch), searching/tagging, retrieving metadata, and refreshing cache. No obvious gaps for the intended read-oriented purpose.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

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

Related MCP Connectors

Orcha
io.github.westonhancock
Securely search and manage workspace context files for AI agents and teams.
Search File Systems Knowledge & Memory
1
ContextLayer B
io.github.DotNova
Intelligent context infrastructure for AI teams: knowledge graph, sessions, tasks, documents.
Knowledge & Memory Developer Tools
622
OneLore
ai.onelore
Shared project context for AI agents and teams: docs, tasks, and messages that stay current.
Project Management Documentation Access
2
Sombra
so.sombra
AI research library. Save, organise and reuse notes and webpages as clean markdown context.
Note Taking Research & Data Web Scraping
2

Related MCP Servers

MCP Tools
Knowledge & Memory Developer Tools Autonomous Agents
taylorleese
A
license
B
quality
A
maintenance
Provides context management and todo persistence with AI second opinions from ChatGPT and Claude. Enables saving code snippets, conversations, and todos across sessions with full-text search capabilities.
Updated a month ago (2026-08-07 06:51 UTC)
3
3
MIT
membot
Knowledge & Memory Search
evantahler
A
license
Not graded
quality
A
maintenance
Provides a persistent, versioned, and searchable context store for AI agents with local embedding and hybrid search.
Updated 2 months ago (2026-07-04 18:05 UTC)
85
3
MIT
Agent Context MCP Server
Knowledge & Memory Developer Tools
Arunavo-ProjectIdea
A
license
B
quality
B
maintenance
Tracks working context and code structure in a portable local SQLite database, enabling seamless context and task continuity across different AI coding tools.
Updated 2 months ago (2026-07-10 20:18 UTC)
12
1
MIT
Memory Fabric
Knowledge & Memory Developer Tools
elViRafa
A
license
Not graded
quality
A
maintenance
Enables AI coding assistants to store and retrieve project-aware context as plain Markdown files locally, with no cloud or vector database required.
Updated 16 days ago (2026-08-19 00:48 UTC)
2
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/yrstruely/contextual'

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