Which integrations are available for this server?

Enables installation of the MCP server via npm, providing access to NPM package management for installing and running the file context server.

How do I use MCP File Context Server?

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., "@MCP File Context Server search for all functions in the src directory" 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.

en es ja ko zh

MCP File Context Server

by bsmi021

Overview Schema Related Servers Score Discussions

JavaScript

Local

File Context Server

A Model Context Protocol (MCP) server that provides file system context to Large Language Models (LLMs). This server enables LLMs to read, search, and analyze code files with advanced caching and real-time file watching capabilities.

Features

File Operations
- Read file and directory contents
- List files with detailed metadata
- Real-time file watching and cache invalidation
- Support for multiple file encodings
- Recursive directory traversal
- File type filtering
Code Analysis
- Cyclomatic complexity calculation
- Dependency extraction
- Comment analysis
- Quality metrics:
  - Duplicate lines detection
  - Long lines detection (>100 characters)
  - Complex function identification
  - Line counts (total, non-empty, comments)
Smart Caching
- LRU (Least Recently Used) caching strategy
- Automatic cache invalidation on file changes
- Size-aware caching with configurable limits
- Cache statistics and performance metrics
- Last read result caching for efficient searches
Advanced Search
- Regex pattern matching
- Context-aware results with configurable surrounding lines
- File type filtering
- Multi-pattern search support
- Cached result searching
- Exclusion patterns

Related MCP server: TokenScope

Installation

Installing via Smithery

To install File Context Server for Claude Desktop automatically via Smithery:

npx -y @smithery/cli install @bsmi021/mcp-file-context-server --client claude

Manual Installation

npm install @modelcontextprotocol/file-context-server

Usage

Starting the Server

npx file-context-server

Available Tools

list_context_files

Lists files in a directory with detailed metadata

{
  "path": "./src",
  "recursive": true,
  "includeHidden": false
}

read_context

Reads file or directory contents with metadata

{
  "path": "./src/index.ts",
  "encoding": "utf8",
  "maxSize": 1000000,
  "recursive": true,
  "fileTypes": ["ts", "js"]
}

search_context

Searches for patterns in files with context

{
  "pattern": "function.*",
  "path": "./src",
  "options": {
    "recursive": true,
    "contextLines": 2,
    "fileTypes": ["ts"]
  }
}

analyze_code

Analyzes code files for quality metrics

{
  "path": "./src",
  "recursive": true,
  "metrics": ["complexity", "dependencies", "quality"]
}

cache_stats
- Gets cache statistics and performance metrics
```
{
  "detailed": true
}
```

Error Handling

The server provides detailed error messages with specific error codes:

FILE_NOT_FOUND: File or directory does not exist
PERMISSION_DENIED: Access permission issues
INVALID_PATH: Invalid file path format
FILE_TOO_LARGE: File exceeds size limit
ENCODING_ERROR: File encoding issues
UNKNOWN_ERROR: Unexpected errors

Configuration

Environment variables for customization:

MAX_CACHE_SIZE: Maximum number of cached entries (default: 1000)
CACHE_TTL: Cache time-to-live in milliseconds (default: 1 hour)
MAX_FILE_SIZE: Maximum file size in bytes for reading

Development

# Install dependencies
npm install

# Build
npm run build

# Run tests
npm test

# Start in development mode
npm run dev

License

MIT

Contributing

Contributions are welcome! Please read our Contributing Guide for details on our code of conduct and the process for submitting pull requests.

Cross-Platform Path Compatibility

Note: As of April 2025, all file and directory path handling in File Context Server has been updated for improved cross-platform compatibility (Windows, macOS, Linux):

All glob patterns use POSIX-style paths (forward slashes) internally, ensuring consistent file matching regardless of OS.
All file system operations (reading, writing, stat, etc.) use normalized absolute paths for reliability.
If you are developing or extending the server, use path.posix.join for glob patterns and path.normalize for file system access.
This change prevents issues with path separators and file matching on different operating systems.

No changes are required for end users, but developers should follow these conventions when contributing to the project.

Available Tools

6 tools

generate_outlineC

Generate a code outline for a file, showing its structure (classes, functions, imports, etc). Supports TypeScript/JavaScript and Python files.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Path to the file to analyze

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool generates an outline and supports specific languages, but it doesn't describe key behavioral traits such as what the output format looks like (e.g., structured data, text), whether it handles errors for unsupported files, or if there are performance considerations. For a tool with no annotation coverage, this leaves significant gaps in understanding how it behaves.

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 concise and well-structured in two sentences: the first states the core purpose, and the second adds language support. There's no wasted text, and it's front-loaded with the main function. However, it could be slightly more efficient by integrating the language support into the first sentence, but it's still highly effective.

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 (analyzing code structure) and the lack of annotations and output schema, the description is incomplete. It doesn't explain what the generated outline includes (e.g., depth, formatting) or how errors are handled, which are crucial for an AI agent to use it correctly. With no structured data to fill these gaps, the description should provide more context to be fully helpful.

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?

The input schema has 100% description coverage, with the 'path' parameter fully documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't clarify path formats or constraints). Since the schema does the heavy lifting, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

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 tool's purpose: 'Generate a code outline for a file, showing its structure (classes, functions, imports, etc).' It specifies the verb ('generate'), resource ('code outline'), and scope ('file'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'getFiles' or 'read_context', which might also involve file operations, so it doesn't reach the highest score.

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 minimal usage guidance: it mentions supported languages (TypeScript/JavaScript and Python), which implies when to use it for those file types. However, it doesn't offer explicit guidance on when to choose this tool over alternatives like 'getFiles' (which might list files) or 'read_context' (which might read file contents), nor does it mention prerequisites or exclusions. This lack of comparative context limits its helpfulness.

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

get_chunk_countA

Get the total number of chunks that will be returned for a read_context request. Use this tool FIRST before reading content to determine how many chunks you need to request. The parameters should match what you'll use in read_context.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Path to file or directory
`encoding`	No	File encoding (e.g., utf8, ascii, latin1)	utf8
`maxSize`	No	Maximum file size in bytes. Files larger than this will be chunked.
`recursive`	No	Whether to read directories recursively (includes subdirectories)
`fileTypes`	No	File extension(s) to include WITHOUT dots (e.g. ["ts", "js", "py"] or just "ts"). Empty/undefined means all files.

TDQS

A4.2/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 the full burden of behavioral disclosure. It explains the tool's role in planning for 'read_context' and that parameters should match, which adds useful context. However, it lacks details on performance characteristics, error handling, or output format, leaving gaps in behavioral understanding for a tool with no annotation support.

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 highly concise and well-structured with two sentences. The first sentence states the purpose, and the second provides critical usage guidance. Every word serves a clear purpose, with no redundancy or unnecessary elaboration.

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 complexity (5 parameters, no output schema, no annotations), the description is reasonably complete. It clarifies the tool's purpose and usage relative to 'read_context', but lacks details on output format or error scenarios. With 100% schema coverage, it provides adequate context for basic use, though more behavioral transparency would enhance completeness.

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 fully documents all 5 parameters. The description adds minimal value beyond the schema by implying parameter alignment with 'read_context', but does not provide additional syntax or format details. This meets the baseline score of 3 when schema coverage is high.

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: 'Get the total number of chunks that will be returned for a read_context request.' It specifies the verb ('Get') and resource ('total number of chunks'), and distinguishes it from sibling tools like 'read_context' by focusing on pre-calculation rather than content retrieval.

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

Usage Guidelines5/5

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

The description provides explicit usage guidance: 'Use this tool FIRST before reading content to determine how many chunks you need to request.' It directly addresses when to use this tool (before 'read_context') and why (to determine chunk count), offering clear context for its application relative to alternatives.

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

getFilesC

Retrieve multiple files by their paths, returning content and metadata for each file

ParametersJSON Schema

Name	Required	Description	Default
`filePathList`	Yes	The list of file paths for the file content to return.

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It mentions the action ('retrieve') and output ('content and metadata'), but lacks critical behavioral details such as permissions required, error handling for invalid paths, rate limits, or whether this is a read-only operation. This is a significant gap for a tool that interacts with files.

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, efficient sentence that front-loads the core action and output without any wasted words. It's appropriately sized for the tool's complexity.

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 lack of annotations and output schema, the description is incomplete. It doesn't address behavioral aspects like safety, error handling, or output structure, which are crucial for a file retrieval tool. The agent would need to guess about these elements.

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 the parameter 'filePathList' well-documented in the schema. The description adds minimal value beyond the schema by implying retrieval of multiple files, but doesn't provide additional semantics like path format examples or constraints beyond what's in 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 the tool's purpose with specific verbs ('Retrieve multiple files') and resources ('files by their paths'), and specifies what it returns ('content and metadata for each file'). However, it doesn't explicitly differentiate from sibling tools like 'read_context' or 'get_profile_context', which might also involve file/content retrieval operations.

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. It doesn't mention prerequisites, limitations, or compare it to sibling tools like 'read_context' or 'get_profile_context', leaving the agent 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_profile_contextC

Get repository context based on current profile settings

ParametersJSON Schema

Name	Required	Description	Default
`refresh`	No	Whether to refresh file selection before generating context

TDQS

C2.8/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 only states what the tool does without disclosing behavioral traits. It doesn't mention whether this is a read-only operation, if it requires specific permissions, what 'repository context' includes (e.g., files, metadata), or any rate limits, leaving significant gaps in understanding its behavior.

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, efficient sentence that states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, though it could be slightly more informative given the lack of other details, but it earns its place by being clear and direct.

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 no annotations, no output schema, and a vague purpose, the description is incomplete. It doesn't explain what 'repository context' returns, how it relates to 'current profile settings', or provide enough detail for an agent to understand the tool's full scope and usage in context with sibling tools, leaving significant gaps.

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?

The input schema has 1 parameter with 100% description coverage, so the schema fully documents the 'refresh' parameter. The description adds no parameter-specific information beyond what the schema provides, but with only one well-documented parameter, the baseline is high, and the description doesn't detract from this.

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

Purpose3/5

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

The description states the tool 'Get repository context based on current profile settings', which provides a general purpose (verb+resource). However, it's vague about what 'repository context' entails and doesn't distinguish from sibling tools like 'read_context' or 'getFiles', leaving ambiguity about scope and differentiation.

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 versus alternatives like 'read_context' or 'getFiles' is provided. The description implies usage for obtaining context related to profiles, but lacks context about prerequisites, exclusions, or comparisons with sibling tools, offering minimal direction.

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

read_contextA

Read and analyze code files with advanced filtering and chunking. The server automatically ignores common artifact directories and files:

Version Control: .git/
Python: .venv/, pycache/, *.pyc, etc.
JavaScript/Node.js: node_modules/, bower_components/, .next/, dist/, etc.
IDE/Editor: .idea/, .vscode/, .env, etc.

For large files or directories, use get_chunk_count first to determine total chunks, then request specific chunks using chunkNumber parameter.

ParametersJSON Schema

Name	Required	Description	Default
`path`	Yes	Path to file or directory to read
`maxSize`	No	Maximum file size in bytes. Files larger than this will be chunked.
`encoding`	No	File encoding (e.g., utf8, ascii, latin1)	utf8
`recursive`	No	Whether to read directories recursively (includes subdirectories)
`fileTypes`	No	File extension(s) to include WITHOUT dots (e.g. ["ts", "js", "py"] or just "ts"). Empty/undefined means all files.
`chunkNumber`	No	Which chunk to return (0-based). Use with get_chunk_count to handle large files/directories.

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations provided, the description carries full burden and does an excellent job disclosing behavioral traits: it specifies automatic directory exclusions (version control, Python artifacts, JavaScript/Node.js, IDE/editor files), describes chunking behavior for large files, and explains the relationship with get_chunk_count. It doesn't mention error handling, performance characteristics, or authentication needs, but provides substantial operational context.

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 appropriately sized and front-loaded with the core purpose. The bulleted list of exclusions is efficient, and the guidance about get_chunk_count is necessary context. While slightly longer than minimal, every sentence earns its place by providing essential operational information that isn't in the schema.

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 complexity (6 parameters, chunking behavior, filtering logic) and no annotations/output schema, the description does an excellent job covering operational context. It explains the automatic exclusions, chunking workflow, and relationship with sibling tools. The main gap is lack of information about return format/content, but this is reasonable given the tool's primary focus on reading operations.

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 6 parameters thoroughly. The description adds some context about chunkNumber usage ('Use with get_chunk_count to handle large files/directories') and implies filtering through the automatic exclusions list, but doesn't provide additional parameter semantics beyond what's in the schema. This meets the baseline expectation when schema coverage is complete.

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 ('read and analyze code files') and resources ('code files'), and distinguishes it from siblings by mentioning advanced filtering/chunking capabilities and automatic directory exclusions. It goes beyond a simple read operation by describing analysis and filtering features.

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

Usage Guidelines5/5

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

The description provides explicit guidance on when to use this tool versus alternatives: it mentions using 'get_chunk_count first to determine total chunks' for large files/directories, and the automatic exclusion list helps users understand when this tool is appropriate versus when manual filtering might be needed elsewhere. It also distinguishes from 'getFiles' by focusing on content reading rather than just file listing.

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

set_profileC

Set the active profile for context generation

ParametersJSON Schema

Name	Required	Description	Default
`profile_name`	Yes	Name of the profile to activate

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 for behavioral disclosure. It states the action ('Set the active profile') but doesn't reveal important behavioral traits: whether this is a persistent configuration change, if it affects subsequent operations, what permissions are required, if there are side effects, or what happens on failure. The description is minimal and lacks operational context.

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 extremely concise - a single 7-word sentence that communicates the core purpose without any wasted words. It's front-loaded with the essential action and purpose. This is an example of efficient communication where every word earns its place.

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 that this is a mutation tool (implied by 'Set') with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what 'active profile' means in the system context, how this affects other operations, what the expected outcome is, or provide any error handling information. For a tool that likely changes system state, more context is needed.

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% (the single parameter 'profile_name' is fully documented in the schema), so the baseline is 3. The description doesn't add any parameter-specific information beyond what's already in the schema - it doesn't explain what constitutes a valid profile name, where profiles come from, or provide examples.

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 tool's purpose with a specific verb ('Set') and resource ('active profile'), and indicates the functional outcome ('for context generation'). However, it doesn't explicitly differentiate this from sibling tools like 'get_profile_context' or explain how 'set_profile' relates to other profile/context operations.

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 'get_profile_context' or 'read_context'. There's no mention of prerequisites, when this operation is needed, or what happens if no profile is set. The phrase 'for context generation' hints at a purpose but doesn't establish clear usage boundaries.

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.

6 tool updatesAug 15, 2025
- First observedgenerate_outline
- First observedget_chunk_count
- First observedget_profile_context
- First observedgetFiles
- First observedread_context
- First observedset_profile

Install Server

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

TDQS

B3.3/5.0

Disambiguation4/5

Most tools have distinct purposes, but 'getFiles' and 'read_context' both involve retrieving file content, which could cause confusion. 'generate_outline' and 'get_profile_context' are clearly separate, and 'set_profile' and 'get_chunk_count' are specialized utilities.

Naming Consistency2/5

Naming is inconsistent with mixed conventions: 'generate_outline' and 'read_context' use snake_case, while 'getFiles' uses camelCase. Verb styles vary (e.g., 'generate' vs. 'get' vs. 'read'), and 'get_chunk_count' includes an underscore while 'getFiles' does not, creating a chaotic pattern.

Tool Count5/5

With 6 tools, the count is well-scoped for a file context server, covering core operations like file retrieval, analysis, and profile management without being overwhelming or too sparse.

Completeness4/5

The toolset covers key file context operations: retrieving files, analyzing code, generating outlines, and managing profiles. A minor gap exists in update or delete operations for profiles or contexts, but agents can likely work around this for the server's purpose.

Maintenance

ActivityInactive

ResponsivenessUnresponsive

Resources

Need Help?

Reddit Discussion

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

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216
Cortex C
io.cortex.mcp
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
Developer Tools Monitoring Observability
312
Sentry AOAuth
dev.sentry.mcp
Enable secure connectivity between Sentry issues and debugging data, and LLM clients, using a Model Context Protocol (MCP) server.
Monitoring Developer Tools Observability
3

Related MCP Servers

code-index-mcp
Code Analysis Developer Tools Search
johnhuang316
A
license
A
quality
A
maintenance
A Model Context Protocol (MCP) server that helps large language models index, search, and analyze code repositories with minimal setup
Updated a month ago (2026-07-27 08:14 UTC)
14
1,005
MIT
TokenScope
Code Analysis Developer Tools Autonomous Agents
cdgaete
A
license
Not graded
quality
D
maintenance
A Model Context Protocol server that enables token-aware directory exploration and file analysis for LLMs, helping them understand codebases through intelligent scanning and reporting.
Updated a year ago (2025-05-06 05:48 UTC)
4
MIT
CodeAlive MCPofficial
Code Analysis RAG Systems Developer Tools
CodeAlive-AI
A
license
Not graded
quality
A
maintenance
A Model Context Protocol server that enhances AI agents by providing deep semantic understanding of codebases, enabling more intelligent interactions through advanced code search and contextual awareness.
Updated 20 days ago (2026-08-16 13:58 UTC)
89
MIT
Local Project Sync
Code Analysis Developer Tools
xueshanisusan
F
license
B
quality
D
maintenance
A Model Context Protocol (MCP) server that enables AI applications to access and analyze local code repositories without manual uploads, providing file listing, content reading, code searching, and project structure analysis capabilities.
Updated a year ago (2025-07-31 19:47 UTC)
7
-

Appeared in Searches

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/bsmi021/mcp-file-context-server'

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

File Context Server

Features

Installation

Installing via Smithery

Manual Installation

Usage

Starting the Server

Available Tools

Error Handling

Configuration

Development

License

Contributing

Cross-Platform Path Compatibility

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

CodeAlive MCPofficial

Appeared in Searches

Latest Blog Posts

MCP directory API