cartograph-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| cg_registryA | Registry-facing daily workflow for Cartograph widgets and blueprints. Use search before writing reusable logic, inspect before installing or editing, install to add a widget to the current project, and rate to leave registry feedback. When installing or inspecting, use the exact value from the 'id' field returned by search. |
| cg_installedA | Mutate widgets already installed in the current project. Use this for installed copies only; use cg_registry install for adding a new widget. Actions: upgrade requires widget_dir and optionally version; uninstall requires widget_dir. Pass the widget directory path (e.g. cg/backend-retry-python). |
| cg_statusA | Check health/status for installed widgets in the current project. Use this to see if widgets are out of sync with the library, have local modifications, or have updates available. Omit widget_dir to scan all installed widgets; provide a specific directory (e.g. cg/backend-retry-python) to inspect one. |
| cg_createA | Scaffold a new Cartograph widget or blueprint. Use name for the slug only, not the full widget_id; Cartograph combines domain + name + language for widgets. For blueprints, just use the name. |
| cg_validateA | Run the full preflight / smoke pipeline without checking the module into the library. Use this as the dry run for checkin before recording reusable changes. |
| cg_checkinA | Run the full validation / smoke pipeline and then check the module into the library. Use this only for changes that should become reusable logic. Requires reason. Supports either path or widget_dir for compatibility. |
| cg_blueprintC | Blueprint-specific composition management. Blueprints are higher-order widgets that compose other widgets as dependencies. Use this to add or remove dependencies. |
| cg_configA | Read or update Cartograph workflow defaults. Provide key to read the current value; provide both key and value to update it. |
| cg_rulesC | List or manage custom validation rules that run during Cartograph validate and checkin. |
| cg_helpA | Recovery guidance for common Cartograph trouble states (e.g. local out of sync with cloud, checkin blocked, validation contamination, publish rejected). Use action=list to browse topics with one-line summaries, then action=get with a topic to read the full resolution. Reach for this before guessing when an agent is stuck on a Cartograph error state. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 10 tools
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.
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.
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.
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.