Enables searching GitHub repositories for project documentation and automatically downloading relevant context files based on project dependencies.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Context Master Set up project context"
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.
An intelligent Model Context Protocol (MCP) server that revolutionizes project bootstrapping by automatically discovering and downloading the most relevant contextual documentation for your development projects.
Context Master transforms how developers start new projects by providing intelligent context gathering through:
Smart Project Analysis - Automatically analyzes your project dependencies
Intelligent Priority System - Advanced scoring to recommend only the most valuable documentation
Automated Documentation - Downloads comprehensive project context as organized markdown files
Project Intelligence - Understands your tech stack and suggests the best resources
Related MCP server: Context7 MCP
🧠 Intelligent Analysis: Automatically analyzes package.json, requirements.txt, and project structure
🎯 Smart Prioritization: Advanced scoring system that identifies which libraries truly need documentation
🔍 Enhanced GitHub Search: Multi-criteria search with relevance scoring and health indicators
📥 Automated Downloads: Bulk download of prioritized documentation with smart naming
📊 Project Intelligence: Understands your tech stack and provides tailored recommendations
🚀 One-Command Setup: Complete project context setup with a single setup_project_context call
Context Files: Downloaded .md files containing comprehensive project documentation
Project Documentation: Additional documentation for understanding your project dependencies
# Clone the repository
git clone https://github.com/onigetoc/mcp-context-master.git
cd mcp-context-master
# Install dependencies
npm install
# Build the project
npm run buildCreate a .env file with your GitHub token:
GITHUB_TOKEN=ghp_your_token_hereGet your GitHub token from: https://github.com/settings/tokens
Add to your MCP client configuration:
For Kiro IDE (.kiro/settings/mcp.json):
{
"mcpServers": {
"mcp-context-master": {
"command": "node",
"args": [
"C:\\path\\to\\mcp-context-master\\build\\index.js"
],
"env": {
"GITHUB_TOKEN": "your_github_token_here"
}
}
}
}For Claude Desktop:
{
"mcpServers": {
"mcp-context-master": {
"command": "node",
"args": ["/path/to/mcp-context-master/build/index.js"],
"env": {
"GITHUB_TOKEN": "your_github_token_here"
}
}
}
}setup_project_context ⭐ Main ToolInitialize and setup Context Master for a project. Analyzes your project dependencies and downloads documentation for important libraries.
add_project_contextFetch and download context for a single library and add it to the project.
list_available_contextsList all available context files in your project.
read_specific_contextRead the content of a specific context file.
read_templateRead a Context Master template file from your project.
search_githubSearch GitHub repositories for project context.
coding_assistantDetect your current coding assistant and determine the appropriate context to use.
To set up Context Master for your project:
User: "Initialize context master for my project"
Tool: setup_project_context will analyze your package.json/requirements.txt and download relevant documentationTo add documentation for a library:
User: "Add project context for remotion"
Tool: add_project_context will search and download remotion documentationTo see what documentation you have:
User: "List available contexts"
Tool: list_available_contexts will show all downloaded context filesTo read a specific context file:
User: "Read the react context"
Tool: read_specific_context will display the documentationNode.js 18+
GitHub token (for repository search)
Internet connection (for documentation downloads)
MCP client (Claude Desktop, VSCode, Kiro, etc.)
MIT
Adds knowledge context for a library using EXACT package names from package.json or confirmed library names. If you're unsure about the exact library name, use the search workflow first: 1) Search GitHub for the library, 2) Confirm the correct repository, 3) Use this tool with the exact name. For example: Use 'remotion' (not '@remotion/captions'), 'react' (not 'react-dom'), '@tanstack/react-query' (not 'react-query'). If the user mentions a feature or topic (like 'captions', 'routing'), that should be used as a topic parameter, not as part of the library name. IMPORTANT: Always provide the absolute path to the user's project directory as projectPath parameter.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Optional topic to focus the documentation (e.g., 'srt caption', 'authentication', 'routing'). This helps Context7 provide targeted documentation and saves tokens. | |
| tokens | No | Number of tokens to request from Context7 (between 2000 and 10000). Default: 3000. Use higher values for broader overviews, lower values for specific features. | |
| libraryName | Yes | The name of the library to add (e.g., 'react', '@reduxjs/toolkit', 'remotion'). | |
| projectPath | No | REQUIRED: Absolute path to the user's project directory (e.g., C:\Users\Name\projects\my-app or /home/user/projects/my-app). The MCP server cannot automatically detect the user's project location - you must provide it explicitly. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses the exact-name requirement, the projectPath requirement (cannot be auto-detected), and the topic distinction. However, it doesn't describe the operation's outcome or whether it overwrites existing context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is detailed but well-structured with a numbered workflow and illustrative examples. Each sentence contributes meaning, though it could be tightened slightly without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters and no output schema or annotations, the description is thorough: prerequisites, parameter nuances, and usage examples are all covered. It lacks only a statement about return values or confirmation behavior, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all parameters at 100%, but the description adds critical semantics: exact naming rules, topic vs library distinction, and the mandatory nature of projectPath (despite not being in the required array). This goes beyond the schema's basic examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds knowledge context for a library and emphasizes EXACT package names, distinguishing it from search_library_advisor and other sibling tools. The verb 'adds' plus the resource 'knowledge context for a library' makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use the search workflow when unsure of the library name, provides step-by-step guidance, and clarifies when to use topic vs libraryName. Also notes that projectPath must always be provided, giving clear when/how to use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
🚨 MANDATORY STEP 1: Initialize Context Master. When user says 'init context master' or '/cm-init', call this tool FIRST, then IMMEDIATELY call setup_project_context. DO NOT ask user for confirmation between steps. DO NOT ask user to create files manually. This tool auto-creates all required files including cm-ai-infos.yaml. CRITICAL: After this tool completes, you MUST call setup_project_context with the same projectPath. No exceptions.
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | No | REQUIRED: Absolute path to the user's project directory (e.g., C:\Users\Name\projects\my-app or /home/user/projects/my-app). The MCP server cannot automatically detect the user's project location - you must provide it explicitly. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool auto-creates files (a side effect) and that it is mandatory to chain with setup_project_context. It also mentions the specific file cm-ai-infos.yaml. While it does not cover error scenarios or idempotency, it provides solid transparency about the tool's actions and side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized for the critical imperative it conveys. It is front-loaded with 'MANDATORY STEP 1' and each sentence carries essential guidance about the sequence, constraints, and automatic file creation. No unnecessary wording; the emphasis serves a legitimate operational purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simple interface (one param, no output schema, no annotations), the description fully covers the necessary context: when to use, what it does, what to do next, and what parameters are needed. The schema already documents the parameter, so the description's focus on process and sequencing makes the tool's usage well-specified for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter projectPath, so the schema fully documents its meaning and requiredness. The description adds little beyond the schema, referring to 'the same projectPath' in the follow-up instruction, but it does not provide new semantic details about the parameter itself. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Initialize') and resource ('Context Master'). It goes beyond a tautology by explaining that it auto-creates all required files, including cm-ai-infos.yaml, and explicitly positions it as 'STEP 1', distinguishing it from sibling tools like setup_project_context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit trigger phrases ('init context master' or '/cm-init'), mandates calling this tool first, and gives precise follow-up instructions (immediately call setup_project_context with the same projectPath). It also states what not to do (do not ask for confirmation or manual file creation), offering clear guidance on when and how to use this tool versus the next step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all available knowledge files with metadata including title, description, and creation date.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry burden. It only states what the tool lists, not whether it's read-only, requires authentication, or any edge cases like empty results. No behavioral traits disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, directly starts with action verb, no unnecessary words. Well structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless list tool, the description covers the basic output fields. However, the existence of sibling tools with overlapping names creates ambiguity, and without an output schema, the description could be more explicit about what 'knowledge files' includes and whether 'added contexts' differs from 'available contexts'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool takes zero parameters, so baseline is 4. The description mentions output metadata (title, description, creation date), which gives some context, but no parameter semantics needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Lists') and resource ('all available knowledge files') with metadata fields. However, it doesn't distinguish from sibling 'list_available_contexts' which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No information about when to use this tool versus alternatives like 'list_available_contexts' or 'search_library_advisor'. No conditions or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lists all available knowledge files from the knowledge manifest.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It implies a read-only operation but does not specify whether it returns full file contents, file names only, or any potential limitations. The description lacks context about output format or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence, front-loaded with the verb 'Lists' and the resource. Every word is purposeful and there is no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool, the description is minimally sufficient, but it lacks any detail about the output format or how it differs from the sibling 'list_added_contexts_details'. The absence of annotations and output schema places more burden on the description, which it only partially meets.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter semantics. The baseline of 4 applies, and the description correctly implies no inputs are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (lists) and the resource (all available knowledge files) with a specific source (knowledge manifest). It distinguishes from sibling tools like list_added_contexts_details by emphasizing 'available' and 'knowledge manifest'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 does not mention any exclusions, prerequisites, or comparison with sibling list tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Reads the content of a specific knowledge file.
| Name | Required | Description | Default |
|---|---|---|---|
| fileName | Yes | The exact name of the knowledge file to read (e.g., 'cm-react-context-2023-10-27.md'). inside .context-master/knowledge directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It states a read operation, which is clearly non-destructive, but doesn't disclose behavior on file-not-found, response format, or permissions. The minimal description adds little beyond the purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that clearly states the purpose with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with a single parameter and no output schema, the description adequately communicates the function and input. However, it does not mention how it relates to the sibling read_template tool or error behavior, leaving a slight gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the parameter with 100% description, including an example and directory path. The tool description adds no additional parameter clarification, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads the content of a specific knowledge file, using a specific verb and resource. It distinguishes from siblings like list_available_contexts and search_library_advisor by implying direct retrieval of a known file.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 compared to siblings such as search_library_advisor or list_available_contexts. The description only states what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a Context Master template file from the user's project .context-master directory
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | No | Path to the project directory (default: current directory) | . |
| templateName | Yes | Name of the template file to read (e.g., "cm-ai-infos.md", "cm-analyze.md") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It does add the important scoping detail of reading from the .context-master directory, but it omits return format, error behavior, or permission requirements. For a read tool, this is minimal but acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It immediately states the action and target, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool, the description covers the core action but does not differentiate from the sibling tool read_specific_context or provide any behavioral nuances. It is adequate but leaves gaps in context that could impact tool selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters (projectPath and templateName) with full coverage and defaults. The description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 specific resource 'Context Master template file' from a defined location ('.context-master directory'). This distinguishes it from reading general context files, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as read_specific_context. It only states what the tool does without any context on selection criteria, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for libraries and get guidance on the correct workflow for adding context. Use this when you're unsure about exact library names or when users mention features/topics. This tool will find the correct repository and suggest the proper Context7 workflow with appropriate topics. Example: search for 'Remotion' to find 'remotion-dev/remotion', then suggest using Context7 with topic 'captions' or 'srt'.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for the library (e.g., "Remotion", "React Query", "Framer Motion") | |
| topic | No | Optional topic to focus on (e.g., "captions", "routing", "animations") |
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 clearly explains that the tool will find the correct repository and suggest a workflow with appropriate topics, and gives a concrete example. It does not explicitly state whether the operation is read-only or if there are side effects, but the described behavior strongly implies a safe advisory action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it opens with the core purpose, gives the usage condition, then provides an illustrative example. Every sentence earns its place without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only two parameters, no output schema, and no annotations, the description covers the key aspects: what it does, when to use it, and an example of expected output. It could mention error handling or what happens if no library is found, but that is not essential for a search/guidance tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds value by providing a concrete example ('Remotion' → 'remotion-dev/remotion', topics 'captions' or 'srt'), clarifying how the query and optional topic parameters interact and what kinds of values are useful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'search' and clearly identifies the resource as libraries, with the added purpose of providing guidance on the correct Context7 workflow. This distinguishes it from sibling tools that initialize, set up, add, or read contexts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it: 'Use this when you're unsure about exact library names or when users mention features/topics.' This provides clear context, though it does not explicitly state when not to use it or mention alternative sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
🚨 MANDATORY STEP 2: Complete Context Master setup. This tool is AUTOMATICALLY called after initialize_context_master. When user says 'init context master', you MUST call initialize_context_master first, then IMMEDIATELY call this tool. DO NOT ask user for confirmation. DO NOT ask user to create files manually. This tool auto-handles all missing configurations and completes the setup process.
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | No | REQUIRED: Absolute path to the user's project directory (e.g., C:\Users\Name\projects\my-app or /home/user/projects/my-app). The MCP server cannot automatically detect the user's project location - you must provide it explicitly. | |
| maxDependencies | No | Maximum number of dependencies to search for (default: 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions 'auto-handles all missing configurations' and 'completes the setup process,' but these are vague and do not reveal specific side effects, file system changes, or system interactions. The description focuses on agent orchestration (mandatory step, don't ask) rather than the tool's actual runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and uses ALL CAPS, exclamation marks, and repetitive imperative clauses. Several sentences are redundant (e.g., two separate 'DO NOT' warnings), and the core purpose could be conveyed in half the length. The hortatory style detracts from clarity and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides strong workflow context by positioning the tool as step 2 in a sequence and tying it to a user utterance. However, it does not explain what inputs are needed (projectPath is described as REQUIRED in schema but the description omits it), nor does it describe success criteria or what happens after execution. The focus on the agent's required actions leaves the tool's own behavior under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description itself adds no parameter information, but the schema already provides rich detail, including path examples and the required nature of projectPath. The absence of parameter discussion in the description is acceptable because the schema fully compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as the mandatory second step in Context Master setup, using the verb 'complete' and resource 'setup'. It distinguishes itself from the sibling initialize_context_master by stating it is automatically called afterward. However, it stops short of specifying concrete actions (e.g., file creation, config updates), instead focusing on workflow directives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use instructions: immediately after initialize_context_master, triggered by the phrase 'init context master'. It gives clear sequencing and explicitly states exclusions ('DO NOT ask user for confirmation', 'DO NOT ask user to create files manually'), making the usage context unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update project's AGENTS.md file with Context Master instructions. Reads the template from .context-master directory and updates the project's AGENTS.md file. Automatically detects the current project directory.
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | No | Optional project directory path, if not provided, automatically detects the current working directory. |
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 reading a template and auto-detecting the directory, but does not disclose whether the file is overwritten, merged, or created if missing, nor any permissions or failure modes. As a mutation tool, more transparency is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, tightly written with the main action first. No redundant words or repetition, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter mutation tool with no output schema, the description covers the core workflow (read template, update AGENTS.md) and default directory handling. However, it omits what happens to existing AGENTS.md content and does not explain the prerequisites (e.g., presence of .context-master), leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds meaning by explaining that the optional projectPath defaults to the current working directory, clarifying behavior beyond the schema's simple 'if not provided' phrasing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
'Update project's AGENTS.md file' clearly states the action and target resource. The description adds that it reads a template from .context-master, distinguishing it from sibling tools like initialize_context_master or add_project_context. Purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are mentioned. However, the description implies it is used to apply Context Master instructions to the current project's AGENTS.md, which is a distinct use case among the siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0add_project_contextinitialize_context_masterlist_added_contexts_detailslist_available_contextsread_specific_contextread_templatesearch_library_advisorsetup_project_contextupdate_agents_fileTwo listing tools (list_available_contexts and list_added_contexts_details) have overlapping descriptions, both listing knowledge files, though one includes metadata. The setup tools (initialize_context_master and setup_project_context) are sequential but clearly defined. Other tools target distinct actions, so overall ambiguity is moderate.
Tool names consistently use snake_case verb-first pattern (search, initialize, setup, add, list, read, update). Minor inconsistencies: 'search_library_advisor' uses an agent-like noun rather than a resource, and 'list_added_contexts_details' is verbose. But the pattern is predictable and readable.
9 tools is a well-scoped number for a context management server, covering setup, searching, adding, listing, reading, and updating. No redundant or excessive tools, and each earns its place.
The toolset covers setup, add, list, read, and update agents file, but lacks delete/remove context operations and any update mechanism for existing context entries. This creates a notable gap in lifecycle management, though the core workflow of adding and reading context is covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Provide your AI coding tools with token-efficient access to up-to-date technical documentation for…
Versioned documentation registry and semantic search for AI tools and coding assistants.
Shared project context for AI agents and teams: docs, tasks, and messages that stay current.
Generate, search, and manage codebase documentation on DocuWriter.ai. 72 tools incl. Autopilot.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/onigetoc/mcp-context-master'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
