Context Continuation MCP Server

by core3-coder

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
Disambiguation5/5
Each tool has a clearly distinct purpose with no overlap: session management (start, end, restore), status tracking (get_status, track_message), project operations (add_milestone, get_project_summary), and decision logging. The descriptions reinforce unique functions, making tool selection unambiguous.
Naming Consistency5/5
All tools follow a consistent 'context_verb_noun' pattern with snake_case throughout (e.g., context_start_session, context_log_decision). This predictable naming scheme enhances readability and makes the tool set cohesive and easy to navigate.
Tool Count5/5
With 8 tools, the count is well-scoped for a context tracking server, covering session lifecycle, status monitoring, project management, and decision logging. Each tool earns its place without redundancy, fitting a typical range for this domain.
Completeness5/5
The tool set provides complete coverage for context tracking: session lifecycle (start, end, restore), real-time updates (track_message, get_status), project management (add_milestone, get_project_summary), and decision documentation (log_decision). No obvious gaps exist, enabling agents to handle all core workflows seamlessly.
Average 2.8/5 across 8 of 8 tools scored.
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
- Last stable release on June 2, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under Apache 2.0.
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 are provided, so the description carries the full burden of behavioral disclosure. It mentions 'comprehensive' but doesn't specify what that includes (e.g., timeline, resources, risks), whether it's read-only, requires permissions, or has side effects. For a tool with no annotation coverage, this leaves 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 with no wasted words. It's front-loaded with the core action ('Get a comprehensive project summary'), making it easy to parse. However, it could be more structured by explicitly stating the tool's scope or limitations.
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 single parameter with good schema coverage, the description is incomplete. It doesn't explain what the summary includes, how it's formatted, or potential errors. For a tool that likely returns complex project data, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with 'projectPath' clearly documented as 'Path to project directory'. The description adds no additional meaning beyond this, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the schema handles the parameter documentation adequately.
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 'Get a comprehensive project summary' states a clear verb ('Get') and resource ('project summary'), but it's somewhat vague about what constitutes 'comprehensive' and doesn't distinguish this tool from potential sibling tools like 'context_get_status' that might also retrieve project information. It's functional but lacks specificity.
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. With siblings like 'context_get_status' available, there's no indication of whether this tool is for high-level overviews, detailed reports, or specific contexts. Usage is implied only by the name, not explained.
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 provided, the description carries the full burden of behavioral disclosure. 'Track a message' suggests a logging or recording action, but it doesn't specify whether this is a read-only operation, if it modifies session state, what happens to tracked messages (e.g., storage, retrieval), or any side effects like rate limits. The description is minimal and lacks critical behavioral details for a tool with no annotation coverage.
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, straightforward sentence with no wasted words, making it highly concise. It front-loads the core action ('track a message') and adds minimal context ('in the current session'). However, it could be more structured by including brief usage notes, but it earns high marks for brevity and clarity within its limited scope.
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 complexity of tracking messages in a session, the lack of annotations, and no output schema, the description is incomplete. It doesn't explain what 'track' entails (e.g., does it store, log, or analyze messages?), the expected return values, or how this integrates with sibling tools like 'context_get_status'. For a tool with 2 parameters and no structured behavioral hints, more detail is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage, with clear documentation for both parameters ('message' and 'role'), including an enum for 'role'. The description adds no parameter-specific information beyond what the schema provides, such as format examples or usage context. Given the high schema coverage, a baseline score of 3 is appropriate as the schema handles the parameter semantics adequately.
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 action ('track') and resource ('a message') but lacks specificity about what 'track' means operationally. It mentions 'in the current session' which provides some context, but doesn't distinguish this tool from siblings like 'context_log_decision' or 'context_add_milestone' that might also handle message-related operations. The purpose is understandable but vague.
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 is provided. The phrase 'in the current session' implies it should be used during an active session, but there's no mention of prerequisites (e.g., a session must be started), exclusions, or comparisons to sibling tools like 'context_log_decision' for similar functions. Usage is implied but not clearly defined.
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 full burden but discloses minimal behavioral traits. It mentions logging but doesn't specify where (e.g., file, database), permissions needed, or effects (e.g., irreversible, append-only). This leaves gaps for a mutation tool with 7 parameters.
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 ('Log a technical decision') that is front-loaded and wastes no words. It's appropriately sized for the tool's purpose, though it could benefit from more detail.
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 complexity (7 parameters, no annotations, no output schema), the description is incomplete. It doesn't explain return values, error handling, or behavioral context, leaving the agent with insufficient information for proper invocation beyond basic parameter filling.
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 parameters are well-documented in the schema. The description adds no meaning beyond the schema, such as explaining relationships between parameters (e.g., how 'alternatives' relate to 'decision'). Baseline 3 is appropriate given high schema coverage.
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 'Log a technical decision' states a clear verb ('Log') and resource ('technical decision'), but it's vague about what logging entails (e.g., where it's stored, format). It doesn't distinguish from siblings like 'context_add_milestone' or 'context_track_message', which might involve similar logging actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. The description lacks context about prerequisites, timing, or comparisons to sibling tools like 'context_add_milestone' for milestone tracking or 'context_track_message' for message logging.
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 full burden. It states the tool starts a session but doesn't disclose behavioral traits such as what 'context tracking' involves, whether it's idempotent, what permissions are needed, or what happens if a session already exists. This leaves critical operational details unspecified.
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 with zero waste. It's front-loaded and appropriately sized for the tool's apparent complexity, making it easy to parse without unnecessary elaboration.
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 explain what 'context tracking' means, what the tool returns, or how it interacts with sibling tools. For a tool that likely manages stateful sessions, this leaves too many gaps for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters (projectPath and sessionName) with clear descriptions. The description adds no additional meaning beyond what the schema provides, such as explaining how these parameters affect the session or their practical use cases.
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 'Start a new context tracking session' clearly states the action (start) and resource (context tracking session), but it's somewhat vague about what 'context tracking' entails. It doesn't differentiate from siblings like 'context_restore_session' or 'context_end_session', leaving ambiguity about when each should be used.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'context_restore_session' and 'context_end_session', the description lacks any indication of prerequisites, timing, or exclusions, leaving the agent to guess based on tool names alone.
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 provided, the description carries the full burden of behavioral disclosure. 'Add a project milestone' implies a write operation, but it doesn't specify whether this requires specific permissions, if changes are reversible, what happens on failure, or any rate limits. For a mutation tool with zero annotation coverage, this leaves 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at three words, front-loading the core action and resource without any wasted text. It efficiently communicates the essential purpose in a minimal format, earning full marks for brevity and clarity.
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 as a write operation with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what the tool returns, error conditions, or how it integrates with the project context implied by sibling tools. For a mutation tool in this environment, more context is needed to ensure proper usage.
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 description adds no parameter semantics beyond what the input schema provides. Since schema description coverage is 100%, the schema already documents all parameters (projectPath, title, description, status) with details like required fields, defaults, and enums. The baseline score of 3 reflects adequate coverage by the schema alone, with no extra value from the description.
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 ('Add') and resource ('project milestone'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential siblings that might also modify project data, such as 'context_log_decision' or 'context_track_message', which could involve similar project 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 (e.g., needing an active session or project), exclusions, or how it relates to sibling tools like 'context_get_project_summary' or 'context_get_status', which might be used before or after adding milestones.
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 provided, the description carries full burden for behavioral disclosure. 'End' implies a destructive/mutative operation that terminates session state, but the description doesn't specify whether this is reversible, what data is preserved/lost, or if authentication/permissions are required. It mentions an optional summary parameter but doesn't explain its purpose or effect.
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 with zero wasted words. It's front-loaded with the core action and resource. Every word earns its place - 'End' specifies the action, 'the current context tracking session' specifies exactly what's affected.
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?
For a session termination tool with no annotations and no output schema, the description is incomplete. It doesn't explain what 'ending' entails (data persistence, cleanup, notifications), what happens to tracked messages/decisions/milestones, return values, or error conditions. Given the sibling tools suggest a rich context tracking system, this description leaves too many behavioral questions unanswered.
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 'summary' is documented in schema as 'Optional session summary'), so the baseline is 3. The description doesn't add any parameter information beyond what the schema provides - it doesn't explain what constitutes a useful summary, format expectations, or how the summary is used after session termination.
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 ('End') and resource ('current context tracking session'), making the purpose immediately understandable. It distinguishes from siblings like 'context_start_session' by specifying the opposite operation. However, it doesn't explicitly differentiate from 'context_restore_session' which might also involve session state changes.
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 (e.g., must have an active session started with 'context_start_session'), when not to use it, or what happens if called without an active session. The sibling tools include session management alternatives, but no comparison is 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 provided, the description carries the full burden of behavioral disclosure. It states the tool generates a prompt but doesn't explain what the prompt contains, how it's formatted, whether it's read-only or has side effects, or any permissions or limitations. This is inadequate for a tool with potential behavioral implications.
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 directly states the tool's function without unnecessary words. It's front-loaded with the core action and resource, making it highly concise and well-structured.
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 (generating a prompt for context restoration), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what the prompt looks like, how it aids 'continuing work', or what behavioral traits to expect, leaving significant gaps for an agent to understand its use.
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 ('Path to project directory'), so the schema fully documents the parameter. The description adds no additional parameter information, but with 0 parameters needing compensation and high schema coverage, the baseline is 4 as it doesn't detract from the schema's clarity.
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 'Generate[s] a context restoration prompt for continuing work', which provides a clear verb ('Generate') and resource ('context restoration prompt'). However, it doesn't specify what format the prompt takes, what 'context restoration' entails, or how it differs from sibling tools like context_get_status or context_start_session, leaving the purpose somewhat vague.
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 offers no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., after a session ends), exclusions (e.g., not for initial setup), or comparisons to siblings like context_get_status for checking current state, leaving the agent with no usage context.
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 provided, the description carries the full burden of behavioral disclosure. While 'Get' implies a read operation, it doesn't specify whether this requires authentication, what permissions are needed, whether it's rate-limited, or what format the status information returns. For a status-checking tool with zero annotation coverage, this is a significant gap in behavioral 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 perfectly concise at just 6 words, front-loading the essential information ('Get current session status and token usage'). Every word earns its place, with no wasted text or unnecessary elaboration. It's appropriately sized for a simple status-retrieval tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It tells the agent what the tool does but doesn't provide enough context about when to use it, what the return format looks like, or behavioral constraints. For a status-checking tool, more information about the returned data structure would be helpful since there's no output schema.
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 0 parameters with 100% schema description coverage, so the schema already fully documents the parameter situation. The description appropriately doesn't waste space discussing non-existent parameters. According to the scoring rules, 0 parameters earns a baseline score of 4, as there's nothing for the description to add beyond what the schema provides.
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 ('Get') and resource ('current session status and token usage'). It distinguishes itself from siblings like context_start_session or context_end_session by focusing on status retrieval rather than session lifecycle management. However, it doesn't explicitly differentiate from context_get_project_summary, which might also provide status information.
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 when this tool is appropriate (e.g., during active sessions, for monitoring usage) or when other tools like context_get_project_summary might be better suited. There's no explicit when/when-not guidance or alternative suggestions.
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:

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

Score Badge

Copy to your README.md:

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

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/core3-coder/context-continue-mcp'

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