cartograph-mcp

by benteigland11

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.3.1
Disambiguation4/5
Tool boundaries are mostly clear: registry, installed widgets, status, creation, validation/checkin, blueprint, config, rules, and help each target a distinct area. The only mild ambiguities are between cg_registry and cg_installed, and cg_validate vs cg_checkin, but the descriptions draw useful separation lines.
Naming Consistency3/5
All tools share the cg_ prefix and lowercase style, which is good, but the semantic pattern is mixed: some are actions (create, validate, checkin), while others are nouns or states (registry, status, blueprint, config, rules). It is readable and predictable, but not a consistent verb_noun convention.
Tool Count5/5
Ten tools is well-scoped for a widget registry/workflow server. Each tool covers a meaningful slice of the lifecycle, and the count is neither bloated nor too thin for the stated purpose.
Completeness4/5
The surface covers the main workflow: scaffold, validate, check in, install, uninstall, upgrade, inspect status, manage dependencies, configure defaults, and resolve errors. Minor gaps exist around explicit registry removal or metadata editing, but agents can likely work around those with existing tools.
Average 3.9/5 across 10 of 10 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- Last stable release on August 19, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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 disclose behavioral traits. It does not mention that blueprints can be created (action 'create'), or any side effects like file modifications, validation behavior, or destructive potential of removing dependencies. Significantly incomplete for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise but incomplete. It front-loads the purpose but misses covering the 'create' action and is not well-structured to list operations clearly.
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 6 parameters and no annotations or output schema, the description fails to explain the 'create' operation, validation behavior, or return values. Does not provide enough context for an agent to use the tool correctly in a workflow.
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 descriptions cover all 6 parameters fully (100% coverage). The tool description adds no additional meaning beyond what the schema already provides. With full schema coverage, baseline is 3; description does not elevate it.
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?
Description clearly identifies the tool manages blueprints as higher-order widgets with dependencies. Uses verb 'add or remove' but omits the 'create' action present in schema, creating a slight gap in coverage. Differentiates from sibling tools by specifying blueprint composition but lacks explicit sibling distinction.
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 a high-level use case ('add or remove dependencies') but does not give explicit guidance on when to use this tool versus alternatives like cg_create or cg_registry. No context on prerequisites, when not to use, or fallback options.
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 alone must disclose behavioral traits. It only states the general purpose but fails to mention side effects (e.g., 'reset' might delete rules), authentication needs, or what happens during 'init'. The schema indicates a 'confirm' boolean for reset, but the description does not reinforce this.
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 efficiently conveys the core purpose without unnecessary words. It is front-loaded and every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has four parameters, no output schema, and no annotations, the description is too sparse. It does not explain what 'init' or 'reset' do, the format of returned data, or how to interpret results. More context is needed for an agent to use this tool correctly.
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 provides full coverage (100%) with descriptions for all four parameters, including enums for 'action' and 'scope'. The description adds no additional meaning beyond 'List or manage', so it meets the baseline but does not exceed it.
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: 'List or manage custom validation rules that run during Cartograph validate and checkin.' It specifies both the action (list/manage) and the resource (custom validation rules), and implicitly distinguishes from sibling tools like cg_validate which perform the validation itself.
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 does it mention prerequisites, limitations, or context-specific usage. For example, it doesn't clarify when to use 'list' vs 'init' vs 'reset' or when to prefer a sibling tool.
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 provided, so description must fully disclose behavior. It states it runs a full validation/smoke pipeline and checks in, but lacks details on side effects (e.g., overwriting, reversibility, permissions) or what 'check in' entails. Incomplete for a mutation tool.
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?
Two sentences only: first states primary action, second gives usage constraint and parameter hint. No redundancy, front-loaded with key purpose. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 7 parameters and no output schema or annotations, the description omits behavior for validation outcomes, side effects of publish/bump, and return value (e.g., success confirmation). Incomplete for a complex checkin 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?
Schema coverage is 100%, baseline 3. Description adds value by noting that 'widget_dir' is an alias for 'path' for compatibility, clarifying their relationship beyond schema. Also highlights that 'reason' is required, aligning with schema.
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 runs validation/smoke pipeline and checks module into library, with specific purpose for changes that should become reusable logic. Differentiates from siblings like cg_validate or cg_create.
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?
Explicitly states 'Use this only for changes that should become reusable logic' and 'Requires reason.' Provides clear context for when to use, but does not mention when not to use or suggest alternative tools among siblings.
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?
There are no annotations, so the description carries the behavioral burden. It discloses an important naming behavior: Cartograph combines domain + name + language for widgets, and blueprints use only the name. It does not, however, mention what actually gets created on disk, whether the operation is destructive, or what success/output looks like, so behavioral transparency is only partial.
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 very concise and front-loaded, with the core action stated in the first sentence. The second sentence earns its place by resolving a potential misapprehension about slug vs full widget_id and blueprint naming. No filler 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?
Given six parameters and no output schema, the description could do more. It covers the main naming behavior and widget vs blueprint distinction, but does not mention that domain/language are required for widgets, what default target behavior is, or what the tool returns/creates. The essentials are present, but some contextual guidance is missing.
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 coverage is 100%, so the baseline is 3. The description adds meaningful semantic nuance beyond the schema by clarifying that 'name' is a slug only, not a full widget_id, and explaining how domain, name, and language combine for widgets. This prevents a real misuse that the schema alone would not protect against.
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 ('Scaffold') and clear resources ('a new Cartograph widget or blueprint'), making the tool's purpose immediately obvious. It does not explicitly distinguish itself from the sibling cg_blueprint, which may cause mild ambiguity, but the core purpose is specific enough.
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 gives clear context for when to use: when scaffolding a new Cartograph widget or blueprint. It also adds practical guidance about how to specify the name and how blueprints differ. However, it does not mention exclusions or explicitly route to alternatives such as cg_blueprint.
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 exist, so the description carries full burden. It states the tool runs a pipeline without checking in, but does not describe failure modes, timeouts, or what happens on success/failure. Adequate but could be more detailed.
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?
Two sentences, no wasted words. Front-loaded with action and purpose, then usage guidance. Highly concise.
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 simple (2 optional params, no output schema). The description covers purpose and usage but doesn't mention what the tool returns or outputs. For a dry run, the return might be important to know, so it's slightly incomplete.
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 coverage is 100%, so baseline is 3. The description adds no additional meaning to the parameters beyond what the schema already provides for 'path' and 'lib'.
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 runs a preflight/smoke pipeline as a dry run for checkin. The verb 'validate' combined with 'run the full preflight / smoke pipeline' and context of 'without checking in' distinguishes it from siblings like cg_checkin.
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 says 'Use this as the dry run for checkin before recording reusable changes,' providing clear when-to-use guidance. It implies not to use instead of cg_checkin, but does not fully list alternatives or when not to use.
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 full burden. It implies read-only behavior (check health/status) but does not explicitly state no side effects, permissions needed, or other behavioral traits. Adequate but not comprehensive.
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 two sentences, front-loaded with purpose, and contains no unnecessary words. It efficiently conveys the key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate complexity, the description sufficiently covers the tool's use (scan all or specific). It does not elaborate on return format or pagination, but the schema handles those. Overall complete for practical 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 coverage is 100%, so the schema already describes all parameters. The description adds minimal context for widget_dir (example path) but does not enhance understanding of page, size, or all beyond the schema.
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 checks health/status of installed widgets, specifying details like out-of-sync, local modifications, or updates. It distinguishes from sibling tools which perform other operations like architect, blueprint, etc.
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 advises when to use the tool (to check widget status) and how to use it (omit or provide widget_dir). It does not mention when not to use or alternative tools, but the guidance is clear and practical.
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 provided, so description carries full burden. It states 'mutate' but doesn't disclose side effects, reversibility, error handling, or authorization needs for actions like upgrade/uninstall. Adequate but not thorough.
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?
Two sentences and a short instruction. Front-loaded with purpose. Somewhat mixed content (usage guidelines and parameter mappings in same sentence) but still efficient and clear.
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 mutation tool with 3 params and no output schema, description covers purpose, usage context, and action-specific requirements. However, lacks information on return values, error states, or operation results. Slight gaps given complexity.
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 coverage is 100%, but description adds value by linking parameters to actions (e.g., upgrade requires widget_dir and optionally version). This clarifies usage beyond the schema's static descriptions.
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 'Mutate' and resource 'widgets already installed in the current project', distinguishing it from sibling tool cg_registry install for adding new widgets.
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 says when to use this tool (installed copies only) vs cg_registry install for adding new widgets, and details action-specific requirements: upgrade needs widget_dir/version, uninstall needs widget_dir.
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?
The description discloses behavioral traits: reading vs updating based on parameter presence, and the ability to list all settings by omitting key. No annotations are provided, so the description carries the full burden, which it fulfills well.
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 two sentences, direct and front-loaded with the purpose. Every sentence provides essential information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not detail return values, but the behavior is sufficiently explained for an agent to use correctly. The sibling tools are distinct, so no further disambiguation is needed.
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 coverage is 100% with descriptions for both parameters. The description adds value by explaining the conditional behavior: key is used to read, both key and value to update, and omitting key lists all. This goes beyond the schema's static descriptions.
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 and resource: 'Read or update Cartograph workflow defaults.' It distinguishes from sibling tools like cg_blueprint or cg_create by specifying the unique action on configuration defaults.
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 explains when to read (provide key) and when to update (provide both key and value). It does not explicitly mention when not to use or compare to siblings, but the context is clear given the sibling tool names.
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 burden of behavioral disclosure. It implies registry interactions (search, install, rate) and gives a precautionary instruction to search before writing reusable logic, though it does not detail side effects like what installing modifies or whether rating is idempotent. That said, it provides a good deal of operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a compact paragraph of three sentences that front-loads the tool's purpose and action workflow, then adds the critical instruction about using the exact 'id' value. Every sentence earns its place and no redundant wording exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a multi-action orchestrator with 17 parameters and no output schema, the description could be even more complete. It covers the major workflow rules and parameter linkage but does not mention output shape or error conditions, which would be needed for full self-sufficiency. However, it is strong for an overview-level 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 all parameter descriptions at 100%, so the baseline is 3. The description adds value by linking the 'id' field semantics to widget_id, and clarifying the overall role of each action. However, most parameter meaning is already well captured in the schema.
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 identifies the tool as a registry-facing daily workflow for Cartograph widgets and blueprints, and enumerates the primary actions (search, inspect, install, rate). It distinguishes itself from siblings by focusing on the registry workflow rather than creation, validation, or status operations.
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 instructions on when to use the tool: use search before writing reusable logic, inspect before installing or editing, install to add a widget, and rate to leave feedback. It also tells the agent to use the exact 'id' value returned by search when installing or inspecting, which is actionable 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?
Describes non-destructive guidance retrieval, but lacks explicit statement about idempotency or side effects; however, no annotations exist so description carries burden.
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?
Two sentences, front-loaded with purpose, no wasted words.
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?
Complete for a help tool with only two parameters and no output schema; mentions return types for list and get actions.
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 covers 100% with descriptions; description adds context by explaining the list/get workflow and relation to topic output.
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 it provides recovery guidance for Cartograph trouble states with specific examples and distinguishes actions list and get.
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 advises to use this tool before guessing on error states, and explains when to use list versus get.
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:

[![cartograph-mcp MCP server](https://glama.ai/mcp/servers/benteigland11/cartograph-mcp/badges/card.svg)](https://glama.ai/mcp/servers/benteigland11/cartograph-mcp)

Score Badge

Copy to your README.md:

[![cartograph-mcp MCP server](https://glama.ai/mcp/servers/benteigland11/cartograph-mcp/badges/score.svg)](https://glama.ai/mcp/servers/benteigland11/cartograph-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/benteigland11/cartograph-mcp'

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