MCP Context Master

by onigetoc

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation3/5
Two 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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness3/5
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.
Average 3.8/5 across 9 of 9 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness2/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines5/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
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 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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
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 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.
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 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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
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 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.
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 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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/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 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness4/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
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 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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mcp-context-master MCP server](https://glama.ai/mcp/servers/onigetoc/mcp-context-master/badges/card.svg)](https://glama.ai/mcp/servers/onigetoc/mcp-context-master)

Score Badge

Copy to your README.md:

[![mcp-context-master MCP server](https://glama.ai/mcp/servers/onigetoc/mcp-context-master/badges/score.svg)](https://glama.ai/mcp/servers/onigetoc/mcp-context-master)

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/onigetoc/mcp-context-master'

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