Context Forge

by Radics

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Tools are mostly distinct: get_context and search_context both retrieve context but are differentiated by task-scoping vs. searching. checkpoint_status and sync_status are both status checks but cover different system aspects, so ambiguity is low overall.
Naming Consistency4/5
Most tools follow a clear verb_noun pattern (get_context, write_handoff, record_fact). checkpoint_status and sync_status deviate slightly as they are noun-like status queries, but the naming remains consistent in style and predictable.
Tool Count5/5
With 7 tools, the server is well-scoped for its purpose of context and handoff management. Each tool covers a distinct functional area, and the count is neither sparse nor bloated.
Completeness4/5
The tool set covers core operations: retrieving context, searching, getting runbooks, writing handoffs, recording facts, and checking status. Minor gaps include no update or delete operations for facts or contexts, but the primary lifecycle for the domain appears covered.
Average 3.4/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- Last stable release on August 11, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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?
Annotations indicate non-read-only and non-destructive, but the description adds no further behavioral context such as duplication handling, overwrite behavior, or side effects. It merely restates the action implied by the name.
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 single sentence is concise and front-loaded, with no wasted words. However, it is minimal to the point of under-specification, so it does not fully earn a perfect score.
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 5-parameter mutation tool with no output schema and sparse annotations, the description is inadequate. It omits return behavior, side effects, and parameter usage details, leaving significant gaps for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 5 parameters and 0% schema description coverage, the description must compensate. It mentions fact, evidence, and confidence but omits recorded_by and gives no additional semantics for evidence format or confidence meaning. The schema provides types/constraints, but the description fails to bridge the coverage gap.
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 a specific verb 'record' and resource 'project fact', clearly distinguishing it from sibling tools like get_context and write_handoff. It conveys a focused write operation with relevant parameters.
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 gives no guidance on when to use this tool versus alternatives. Sibling write_handoff could overlap, but no distinction or context is provided, leaving the agent without decision criteria.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to repeat safety info. It does add a small behavioral detail by specifying that lookup occurs by operation key, but it does not describe error behavior, return format, or what happens if the runbook is not found. This is adequate but not rich, hence a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is direct and front-loaded. Every word contributes to the meaning: 'Get a project runbook by operation key.' There is no unnecessary verbosity or redundant information, making it an exemplar of conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what a runbook contains or what the return value looks like, but it does not. It fails to mention any edge cases, such as missing runbooks or authorization requirements. Given the tool's apparent simplicity and the presence of sibling tools, the description leaves significant contextual gaps, earning a 2.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for lack of parameter docs. It clarifies that 'operation' is a key but does not explain what constitutes a valid key or provide examples. 'project' is also left as a bare string with no semantic detail. This is insufficient for a low-coverage scenario, so a score of 2 is warranted.
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 that the tool retrieves a project runbook using an operation key, which is a specific verb-resource pair ('Get' + 'runbook') that distinguishes it from sibling tools like get_context or record_fact. It also mentions the key identifier (operation key), 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 get_context or search_context. It does not mention prerequisites, exclusions, or when another tool would be more appropriate. The lack of any usage context earns a low score.
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?
Annotations already indicate this is a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false), so the description doesn't contradict these. It adds 'structured, evidence-backed' as a quality expectation, but it does not disclose side effects like whether the handoff is appended, overwrites prior handoffs, or requires specific permissions. Given the presence of basic annotations, the description adds some value but leaves gaps.
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 that states the action immediately ('Write...'). Every word contributes value, avoiding fluff or repetition. It is appropriately sized for a simple statement of purpose, though it sacrifices necessary detail elsewhere.
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?
The tool has 8 parameters (7 required) and no output schema, yet the description provides no information about expected inputs, return values, or post-conditions. It is too terse for the complexity involved, leaving an agent uninformed about how to construct a valid handoff or what to expect as a result. The description is far from complete for such a structured tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning, but it does not. The description only says 'structured, evidence-backed' without referencing specific fields like summary, decisions, changes, or verification. It provides no hints about parameter usage or naming conventions beyond what the schema already exposes through names and types.
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: writing a structured, evidence-backed handoff for another agent. It uses a specific verb ('write') and resource ('handoff'), and distinguishes itself from sibling tools that focus on reading context, searching, or status. No ambiguity exists about its core purpose.
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, nor any exclusions or prerequisites. Without mentioning sibling tools or specific scenarios, an agent is left to infer usage solely from the name and generic description. There is no explicit 'when to use' or 'when not to use' information.
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?
Annotations already declare the tool as read-only and non-destructive, and the description does not contradict this. The description adds only minimal behavioral context ('local cache and synchronization status') without discussing potential side effects, return details, or operational constraints, which is acceptable given the simple read-only nature.
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 filler or redundancy. Every word contributes to conveying the tool's purpose statement.
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 tool has no parameters and good safety annotations, but the lack of an output schema and the vague term 'status' leave some ambiguity about what the agent will receive. The description is sufficient for a basic understanding but does not fully clarify the return value or edge cases, warranting a moderate score.
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, and the schema coverage is trivially 100%. The description does not need to elaborate on parameters, and the baseline of 4 for no-parameter tools is appropriate.
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 uses a specific verb ('Show') and a clear resource ('local cache and synchronization status'), making the tool's purpose immediately understandable. However, it does not explicitly distinguish itself from sibling tools like checkpoint_status, though the resource named is distinct enough.
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 does not provide any guidance on when to use this tool versus alternatives, nor does it mention prerequisites or conditions. It simply states what the tool does, leaving the agent to infer appropriate usage from context.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows it is safe. The description adds specific behavioral context by naming the states inspected (pending handoff window, automatic checkpoint trigger state), going beyond the annotations. However, it does not describe the return format or potential side effects, though none are expected.
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 sentence, front-loaded with the action, and contains no filler. Every word contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no explanation of the required 'project' parameter, the description is under-specified. It does not clarify what 'automatic checkpoint trigger state' means or what the response looks like, limiting the agent's ability to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not mention the 'project' parameter at all. The agent is left without any guidance on what value to provide for this required string parameter.
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 verb 'Show' with a specific object ('pending handoff window and automatic checkpoint trigger state'), clearly identifying it as a status inspection tool. This distinguishes it from sibling tools like write_handoff (writing) and get_runbook (retrieval).
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 alternative guidance is given. The description implies usage for checking handoff status, but does not discuss exclusions or contrast with siblings like write_handoff or sync_status.
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?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds only the optional project scoping, but does not disclose behavior such as default limit, ordering, or return structure. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, front-loading the main action and resource. Every word earns its place.
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 search tool, the description is minimal. It lacks information about return values, limit behavior, or any other contextual details that would help an agent use it effectively. However, the annotations provide safety assurances, and the tool is not complex.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only clarifies the 'project' parameter ('optionally within one project'), leaving 'query' and 'limit' without additional meaning beyond their types and requiredness. This is insufficient for a tool with three parameters.
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 identifies 'portable context' as the resource, clearly stating the tool's purpose. It also differentiates from sibling get_context by indicating search functionality with optional project scoping.
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?
The description gives no explicit guidance on when to use this tool versus alternatives like get_context. While the purpose implies searching, it lacks any mention of exclusions, prerequisites, or alternative tool references, making usage guidelines only implied.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds the token budget scoping, which clarifies that output is size-limited, but does not detail output format or behavior when budget is exceeded. This is similar to the calibration example and warrants a 3.
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 sentence that is front-loaded with the essential action and scope. Every word adds value, with no fluff or repetition.
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 tool is relatively simple, and annotations provide safety context, but there is no output schema or explanation of return value format. The description does not clarify how token_budget affects content (e.g., truncation) or what 'context' includes. It is minimally adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden, but it only mentions 'task-scoped project context' and 'token budget,' which indirectly references project, task, and token_budget. It does not explain the 'mode' parameter or provide any additional semantics beyond the schema. With 4 parameters, this is insufficient compensation.
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: 'Get task-scoped project context within a token budget.' It specifies the verb ('Get'), the resource ('task-scoped project context'), and a key constraint ('token budget'), which distinguishes it from siblings like search_context and get_runbook.
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 implies when to use the tool (when needing context for a specific task in a project, constrained by tokens) but does not explicitly mention when not to use it or name alternative tools. This is clear context without exclusions.
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-forge MCP server](https://glama.ai/mcp/servers/Radics/context-forge/badges/card.svg)](https://glama.ai/mcp/servers/Radics/context-forge)

Score Badge

Copy to your README.md:

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

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/Radics/context-forge'

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