Deterministic intent preflight before your agent builds: six calibrated gates, keyless, no model call.
This repository is the issue tracker for the package, not its source. The server is developed in Pathmode's private monorepo and published to npm from there. This repo previously held a hand-copied snapshot of the source, which drifted several versions behind the published package. It no longer carries that copy, so there is nothing here to read out of date.
To read the code, unpack the published tarball:
npm pack @pathmode/mcp-server && tar -xzf pathmode-mcp-server-*.tgzAdd to .mcp.json in your project root:
{
"mcpServers": {
"pathmode": {
"command": "npx",
"args": ["@pathmode/mcp-server"]
}
}
}No account and no API key. Specs live in intent.md in your repo, as plain markdown you own. Set
PATHMODE_API_KEY to sync intent and evidence across a team.
Related MCP server: lore
npm package: the published server, always current
IntentSpec: the open specification for the intent.md files this server writes
The intent.md profile: the six checks check_intent_readiness scores against
Pathmode: the platform for teams
Bug reports and feature requests belong in Issues.
Include the output of npx @pathmode/mcp-server --version and the client you are running.
MIT
Analyze the intent dependency graph for risks and strategic insights. Returns critical path, cycles, bottlenecks, orphans, status mismatches, and stalled intents.
| Name | Required | Description | Default |
|---|---|---|---|
| analysis | No | Type of analysis: full (default), critical-path, risks, or status distribution |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, openWorldHint) already indicate read-only and open-world behavior. The description adds value by listing specific outputs (cycles, bottlenecks, etc.) and does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: the first states the action, the second lists outputs. No redundant information, effectively front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description adequately covers purpose and expected outputs. Minor gap in explaining result format, but sufficient given simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single enum parameter. The description supplements by explaining what each analysis type returns (e.g., critical path, risks), adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Analyze the intent dependency graph') and the specific resources ('risks', 'strategic insights', 'critical path', etc.). It effectively distinguishes from sibling tools like get_intent or create_intent by focusing on graph-level analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives. No mention of context, prerequisites, or when not to use it, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new evidence item (e.g., a discovered bug, user feedback quote, behavioral observation, or feature request). Evidence can later be linked to intents to support prioritization.
| Name | Required | Description | Default |
|---|---|---|---|
| content | Yes | The evidence content — a finding, quote, or observation | |
| type | Yes | Type of evidence | |
| productId | Yes | Product (Space) ID this evidence belongs to | |
| source | No | Where this evidence came from (e.g., "User interview", "Bug report", "Support ticket") | |
| sourceUrl | No | URL to the original source | |
| severity | No | Severity level (required for friction type) | |
| sentiment | No | Emotional sentiment | |
| tags | No | Category tags (e.g., ["Onboarding", "Performance"]) | |
| stage | No | Workflow stage (e.g., "Discovery", "Checkout") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false, destructiveHint=false, and openWorldHint=true. The description adds that evidence is 'created' and can later be 'linked to intents,' which aligns with the mutation nature of the tool and provides helpful behavioral context (e.g., evidence is not immediately tied to an intent). No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose and examples. Every word contributes meaning; there is no superfluous text. Ideal conciseness for an AI agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters (3 required) and full schema coverage, the description adequately explains the tool's role and how it fits into the broader workflow (evidence links to intents). It does not detail the return value, but without an output schema this is acceptable. Slightly lacking in mentioning any prerequisites or constraints beyond the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema; it only gives examples of what evidence items look like. The schema sufficiently documents each parameter, so the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Create') and resource ('evidence item'), and provides concrete examples such as 'discovered bug, user feedback quote, behavioral observation, or feature request.' This makes the purpose specific and easy to understand, though it does not explicitly differentiate this tool from sibling tools like 'link_evidence' or 'query_evidence'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to create evidence that can later be linked to intents) but does not provide explicit guidance on when not to use it or mention alternatives. The context of linking to intents offers some usage context, but lacks exclusion criteria or comparative advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new intent spec in the workspace. Requires at minimum a title, objective, and productId. Returns the created intent with its ID. Use list_intents first to see existing intents and avoid duplicates.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Short name for the intent (e.g., "Improve onboarding flow") | |
| objective | Yes | Why this matters — the problem and who has it | |
| productId | Yes | Product (Space) ID this intent belongs to. Use get_workspace to find product IDs. | |
| outcomes | No | Observable, testable state changes | |
| constraints | No | Hard limits the implementation must respect | |
| healthMetrics | No | What to monitor after shipping | |
| edgeCases | No | Failure modes and boundary conditions | |
| verification | No | How to confirm it works | |
| problemSeverity | No | How severe the problem is |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-read-only and non-destructive behavior; the description confirms creation and adds that it returns the created intent with its ID. No contradictions, and the return value detail adds useful behavior context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core action and requirements, the second adds return value and usage tip. Efficient, front-loaded, and no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 9 parameters, no output schema, the description covers the core aspects (purpose, required fields, return value, and a workflow hint). Optional fields are well-documented in the schema, making the description sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 value by explaining that productId comes from get_workspace and reiterating the three required fields, aiding parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates a new intent spec, specifies required fields, and returns the created intent with its ID. It also mentions a sibling tool (list_intents) for deduplication, distinguishing it from other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to use list_intents first to avoid duplicates and references get_workspace to find productId, providing clear context on when and how to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export workspace context as a formatted file. Use "claude-md" for CLAUDE.md (full workspace context), "cursorrules" for Cursor AI rules, or "intent-md" for a single intent specification file. For cursorrules/intent-md, product context is always derived from the resolved intent. For claude-md, pass productId to select a specific product, otherwise the first active product is used.
| Name | Required | Description | Default |
|---|---|---|---|
| format | Yes | Export format | |
| intentId | No | Intent ID (optional, for cursorrules and intent-md) | |
| productId | No | Product ID (optional, only used for claude-md format to select a specific product) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint and openWorldHint, and the description adds valuable behavioral details: how product context is determined for each format (derived from intent for cursorrules/intent-md, selectable for claude-md). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three focused sentences, each serving a clear purpose: stating overall function, listing formats, and explaining behavioral nuances. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, no output schema), the description covers the necessary contextual information: format options, parameter usage, and product selection logic. Annotations adequately cover safety and open-world aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 meaning beyond the schema by explaining when each format is appropriate, the optional nature of intentId and productId, and the default behavior for product selection in claude-md.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool exports workspace context as a formatted file, listing three specific formats (claude-md, cursorrules, intent-md) with distinct uses. It differentiates well from sibling tools, none of which provide this export functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use each format and provides context: for claude-md pass productId to select a product, otherwise the first active product is used; for cursorrules/intent-md product context is derived from the resolved intent. This guides the agent effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a formatted execution prompt for a specific intent. This is the full structured prompt including objective, outcomes, constraints, edge cases, and verification steps.
| Name | Required | Description | Default |
|---|---|---|---|
| intentId | Yes | The intent ID to generate a prompt for | |
| mode | No | draft = critique the spec, execute = implement it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint and openWorldHint. Description confirms read-only nature and adds value by describing the prompt's structure and contents (e.g., constraints, verification steps). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with verb and resource. Efficient with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Good coverage given no output schema: describes purpose and behavior. Could be enhanced by mentioning that calling the tool is safe and read-only, but already adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description does not add additional meaning beyond the schema's descriptions; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get a formatted execution prompt for a specific intent,' specifying a clear verb and resource. It details what the prompt includes (objective, outcomes, constraints, etc.), distinguishing it from siblings like get_intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 like get_intent or get_constitution. No when-not-to-use or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the workspace constitution rules. These are mandatory constraints that all implementations must respect.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds that the content consists of 'mandatory constraints', providing context beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words, front-loading the action and purpose. Perfectly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description explains the output's nature (mandatory constraints) sufficiently. Annotations already provide read-only and open-world hints, making this complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description correctly covers schema coverage at 100%. No additional parameter information is needed, achieving baseline 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets 'workspace constitution rules' and specifies they are 'mandatory constraints'. This provides a specific verb and resource, differentiating it from siblings like get_workspace or get_agent_prompt.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing mandatory constraints ('all implementations must respect'), but lacks explicit when-not-to-use or alternative tools. A more direct statement about when to call this over siblings would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the currently active intent, preferring approved intents with real objective/outcome content over empty stubs. Returns the full IntentSpec with objective, outcomes, constraints, and edge cases.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter by status: draft, validated, approved, shipped, verified |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. Description adds value by specifying preference for approved intents with real content and listing return fields (objective, outcomes, constraints, edge cases). No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose and behavior, second states return content. No extraneous words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, preference logic, and return fields. However, does not address what happens if no active intent exists or if multiple are active. Simple tool so mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description covers the only parameter fully (100% coverage). Description adds no further meaning to the 'status' parameter beyond what schema provides. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states 'Get the currently active intent', distinguishing it from other intent tools like 'get_intent' (by ID) and 'search_intents' (list). Adds behavior of preferring approved intents with real content over stubs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use when needing the active intent without specifying an ID, but does not explicitly state when to use vs alternatives or mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single intent by ID with full details including objective, outcomes, constraints, edge cases, and relations.
| Name | Required | Description | Default |
|---|---|---|---|
| intentId | Yes | The intent ID to fetch |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true (safe read) and openWorldHint=true; the description adds value by specifying the return fields (objective, outcomes, etc.) beyond schema. It aligns with annotations and provides useful 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded and concise. Every word earns its place; no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with one parameter, the description covers the return fields adequately without output schema. However, missing aspects like error handling (e.g., if intent not found) could improve completeness. Annotations provide safety context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'intentId' is fully described in the input schema (100% coverage). The main description does not add extra meaning beyond 'the intent ID to fetch'. Schema coverage is high, so baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a single intent by ID, listing specific fields returned (objective, outcomes, etc.), which distinguishes it from siblings like list_intents (returns all) or search_intents (search-based).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (when needing full details of one intent) but lacks explicit exclusions or references to sibling tools. Sibling tools are numerous, so additional guidance would improve differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the dependency graph for a specific intent. Shows what it depends on, enables, or blocks.
| Name | Required | Description | Default |
|---|---|---|---|
| intentId | Yes | The intent ID to get relations for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and open-world hints. The description adds that the output shows dependencies, enables, and blocks, which provides some behavioral context beyond annotations, but does not detail potential side effects or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences efficiently convey the tool's purpose and output. No redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers the main purpose. However, it omits details like error handling for non-existent intents or the depth of the graph, and lacks output schema information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for 'intentId'. The tool description does not add additional meaning or context beyond the schema, so baseline score is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a dependency graph for a specific intent and explains what the graph shows (dependencies, enables, blocks). It distinguishes from similar siblings like 'get_intent' but does not explicitly differentiate from 'analyze_intent_graph'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. The sibling 'analyze_intent_graph' suggests a similar functionality, but the description does not clarify when to prefer one over the other.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get workspace details including strategy (vision, non-negotiables, architecture principles), active products, and constitution rules.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint: true and openWorldHint: true. Description adds context on content (strategy, products, rules) but does not disclose additional behavioral traits such as authentication needs or rate limits. Given annotations carry the burden, a score of 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence front-loaded with the tool's purpose. Every word contributes value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (no parameters, no output schema). The description adequately explains what is returned: workspace details including strategy, active products, and constitution rules. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema coverage is 100%. The description does not need to explain parameters. Baseline score for 0 params is 4, and no further information is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and the resource 'workspace', and specifies the included details: strategy (vision, non-negotiables, architecture principles), active products, and constitution rules. This differentiates it from sibling tools like 'get_constitution' or 'get_current_intent'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving workspace details but does not explicitly state when to use it versus alternatives like 'get_constitution' or 'get_current_intent'. No exclusions or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Export an intent spec as .cursorrules or CLAUDE.md section for AI agent consumption.
| Name | Required | Description | Default |
|---|---|---|---|
| format | Yes | Export format | |
| spec | Yes | ||
| path | No | Output file path. Defaults to .cursorrules or CLAUDE.md |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It states the tool exports to file formats but does not mention that it creates or overwrites files, the effect of the 'path' parameter default, or any side effects like filesystem modifications. This lack of detail for a file-writing operation is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's core function. It is front-loaded with the action and resource, with no redundant or superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is conceptually simple, the description does not clarify whether the export returns content or writes to a file, nor does it mention default paths. With no output schema, more explanation of the tool's effect and return value is needed. It provides basic completeness but leaves important details unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, which is moderate. The tool description ('Export an intent spec...') adds no additional meaning to the parameters beyond what the schema already provides (format, spec structure, path). Baseline 3 is appropriate as the schema carries most of the load, but the description could elaborate on parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Export' and the resource 'intent spec', specifying target formats '.cursorrules or CLAUDE.md section'. It distinguishes from siblings like 'export_context' and 'intent_save', making the tool's specific role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for exporting intent specs but provides no explicit guidance on when to use this tool versus alternatives like 'export_context'. No exclusions or prerequisites are mentioned, leaving the decision to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save an intent spec to intent.md in the project root. Called after building a spec through conversation.
| Name | Required | Description | Default |
|---|---|---|---|
| spec | Yes | ||
| path | No | File path relative to cwd. Defaults to intent.md |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the action, omitting details about file overwriting, permissions, error handling, or side effects. For a mutation tool, this lack of transparency could lead to misuse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that immediately state the action and context. There is no extraneous information, and the most critical details are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively complex with a deeply nested spec object, yet the description is only two sentences. It lacks information about return values, error conditions, or behavior when the file already exists. Given the lack of an output schema, this leaves the agent with insufficient context for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides descriptions for all parameters (spec and path), so the description adds little extra semantic value. It reinforces that the spec is built through conversation and that the default path is intent.md, which is helpful but not essential beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: saving an intent spec to a file (intent.md). It also provides context on when it is used ('after building a spec through conversation'), distinguishing it from general intent creation or update operations. However, it does not explicitly differentiate from siblings like `create_intent` or `update_intent`, leaving room for ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage in a specific workflow phase ('Called after building a spec through conversation'), giving some guidance on timing. However, it does not specify when not to use this tool, nor does it mention alternatives among the sibling tools (e.g., when to use `update_intent` instead). This leaves the agent with limited direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Link or unlink evidence items to/from an intent. Linking evidence to intents establishes traceability between user problems and planned solutions.
| Name | Required | Description | Default |
|---|---|---|---|
| intentId | Yes | The intent ID to link evidence to | |
| link | No | Evidence IDs to link to this intent | |
| unlink | No | Evidence IDs to unlink from this intent |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate non-read-only and non-destructive behavior. The description adds context about traceability but lacks details on side effects, such as whether linking overwrites existing links or requires permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the action, and efficiently conveys the tool's purpose without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and no output schema, the description is largely complete, though it could mention behavior for duplicate links.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description does not add significant meaning beyond what the schema already provides for the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (link/unlink), resource (evidence), and target (intent), distinguishing it from sibling tools like create_evidence or create_intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for establishing traceability but does not explicitly state when to use this tool over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all intents in the workspace. Returns an array of IntentSpecs with their status, objectives, and metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter by status: draft, validated, approved, shipped, verified |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. Description adds that it returns an array of IntentSpecs with specific fields, which is helpful but does not cover potential limitations like pagination or performance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, front-loaded with purpose. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (1 optional param, no output schema), description adequately covers purpose and return. Missing info on pagination or limits but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% with one optional filtered parameter, already described in schema. Description adds no additional parameter meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb (list), resource (intents), scope (all in workspace), and return contents (array of IntentSpecs with status, objectives, metadata). Distinguishes from siblings like search_intents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs alternatives (e.g., search_intents, get_intent). No mention of optional status filter or when filtering is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Record a technical decision or implementation note for an intent. Use this to document why you chose a specific approach.
| Name | Required | Description | Default |
|---|---|---|---|
| intentId | Yes | The intent ID to attach the note to | |
| note | Yes | The implementation note or technical decision |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and openWorldHint=true, meaning it may have side effects beyond a simple write. The description does not elaborate on these behaviors, such as whether notes are appended or overwritten, or what other effects might occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, 22 words, front-loaded with the verb. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two required params and no output schema, the description covers the basics but omits details like whether notes are appended or replaced, or what the response looks like. Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains both parameters. The description echoes the schema's 'technical decision or implementation note' but adds little new meaning. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Record a technical decision or implementation note for an intent.' It distinguishes from siblings like create_evidence and create_intent, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes explicit guidance: 'Use this to document why you chose a specific approach.' This tells the agent when to use it, though it does not mention when not to use it or point to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search evidence items (friction points, user quotes, observations, metrics, feature requests) by product, type, severity, or text. Returns matching evidence with IDs that can be linked to intents.
| Name | Required | Description | Default |
|---|---|---|---|
| productId | No | Filter by product (Space) ID | |
| type | No | Filter by evidence type | |
| severity | No | Filter by severity | |
| search | No | Text search across evidence content | |
| tags | No | Comma-separated tags to filter by | |
| limit | No | Max results (default 50, max 200) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint. The description adds useful context that the tool returns IDs that can be linked to intents, consistent with the safe read-only behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the verb and resource, no wasted words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers return format (IDs) and filtering; however, it does not mention pagination behavior (limit parameter). Still sufficient for a search tool with good annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 enumerates filter dimensions (product, type, severity, text) but does not add significant meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches evidence items with specific filter dimensions (product, type, severity, text) and returns IDs linkable to intents, distinguishing it from sibling tools like create_evidence and search_intents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching evidence but does not explicitly compare to alternatives or state when not to use. It provides clear context for its purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search intents by keyword. Searches across user goals, objectives, outcomes, and constraints.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search keyword or phrase | |
| status | No | Filter by status: draft, validated, approved, shipped, verified |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint. Description adds that it searches across multiple fields, which is helpful but not extensive. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no unnecessary information. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple search tool, but lacks mention of output format or pagination. However, no output schema exists, so description covers essential purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. Description does not add additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Search intents by keyword' and specifies fields searched ('goals, objectives, outcomes, and constraints'). Distinguishes from sibling tools like list_intents and get_intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for keyword-based search, but no explicit guidance on when to use vs alternatives like list_intents 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.
Update an existing intent's content. Provide only the fields you want to change. Does NOT change intent status (use update_intent_status for that).
| Name | Required | Description | Default |
|---|---|---|---|
| intentId | Yes | The intent ID to update | |
| title | No | New title | |
| objective | No | Updated objective | |
| outcomes | No | Replace all outcomes | |
| constraints | No | Replace all constraints | |
| healthMetrics | No | Replace all health metrics | |
| edgeCases | No | Replace all edge cases | |
| verification | No | Replace verification plan | |
| problemSeverity | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotent and open-world behavior. The description adds that only provided fields are updated and that status is not changed, which are useful behavioral traits beyond annotations. However, it doesn't disclose error handling or side effects, keeping it from a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first clearly states purpose, second provides usage guidance and points to sibling. Every word earns its place; there is no redundancy or fluff. Perfectly front-loaded and concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal given the tool's complexity (9 parameters, nested objects, no output schema). It highlights the key distinction from a sibling but omits expected response, error handling, or behavior on missing intentId. While annotations and schema cover much, the description could be more complete for an agent to use it reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (89%) with detailed parameter descriptions. The description adds no new parameter-specific information beyond the schema; it only reinforces the partial update concept. Baseline 3 is appropriate as the schema already does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an existing intent's content' with a specific verb and resource. It further distinguishes from sibling tool 'update_intent_status' by explicitly stating it does not change status, making the purpose unambiguous and differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Provide only the fields you want to change.' It also clearly states when not to use (for status changes) and directs to the alternative tool 'update_intent_status', fulfilling the criteria for explicit when/when-not/alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update the status of an intent. Use this to mark an intent as shipped after implementation, or verified after testing. For shipped/verified transitions, the response includes a verification checklist of outcomes, constitution rules, and health metrics that should be confirmed.
| Name | Required | Description | Default |
|---|---|---|---|
| intentId | Yes | The intent ID to update | |
| status | Yes | The new status |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotent and non-destructive; description adds response details for shipped/verified transitions, though doesn't mention behavior for other statuses.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three focused sentences covering purpose, key usage, and notable behavior; no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers main use cases and important behavior for shipped/verified, but lacks detail on other status transitions or error handling; output schema absent but partially compensated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already provides clear descriptions for both parameters (100% coverage); description does not add extra parameter-specific meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates intent status and specifies key use cases like marking shipped or verified, distinguishing it from siblings like update_intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use (shipped/verified transitions), but does not explicitly exclude other statuses or compare with alternative tools like update_intent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
AI-grade your implementation against the intent spec. Checks each outcome, constraint, constitution rule, and edge case. Returns pass/fail per item with reasoning and an overall score. Also logs the result as an implementation note.
| Name | Required | Description | Default |
|---|---|---|---|
| intentId | Yes | The intent ID to verify against | |
| summary | Yes | Description of what was implemented and how | |
| codeChanges | No | Summary of code changes (file list, key modifications) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate not read-only and not destructive. Description adds that it logs results as an implementation note, which is a side effect. No contradictions. Adds useful behavioral context beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is two sentences, front-loaded with the core function, then adds details and side effect. No wasted words, efficiently conveys essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and no output schema, the description adequately covers return format (pass/fail per item with reasoning and score) and side effect (logging). No missing critical information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter. The tool description does not add extra meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool verifies implementation against intent spec, checking outcomes, constraints, rules, and edge cases, and returns pass/fail with reasoning and overall score. This distinguishes it from siblings like log_implementation_note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for verification but does not explicitly state when to use vs alternatives or provide caveats. Given siblings like create_evidence and analyze_intent_graph, some guidance would help, but the purpose is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.5.0analyze_intent_graphcreate_evidencecreate_intentexport_contextget_agent_promptget_constitutionget_current_intentget_intentget_intent_relationsget_workspaceintent_exportintent_savelink_evidencelist_intentslog_implementation_notequery_evidencesearch_intentsupdate_intentupdate_intent_statusverify_implementationMost tools have distinct purposes (e.g., create_intent vs list_intents; get_intent_relations vs analyze_intent_graph). However, there is some overlap between export_context, intent_export, and intent_save, and between get_intent_relations and analyze_intent_graph, which could cause confusion for an agent.
The majority of tools follow a verb_noun pattern (e.g., create_intent, list_intents, update_intent). However, a few tools break this pattern (e.g., intent_export, intent_save, get_current_intent), introducing minor inconsistency.
With 20 tools, the set is on the heavy side of the typical range. While each tool serves a specific function, some could potentially be consolidated (e.g., intent_export vs export_context). The count is not excessive but warrants a slightly lower score.
The tool set covers most lifecycle operations for intents and evidence (create, read, update, search, link, export). However, there are notable gaps: no tools to delete intents or evidence, and no tool to manage products beyond workspace retrieval.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Turn PRDs and product ideas into structured specs so coding agents build your intent, not theirs.
Persistent, governed institutional memory for Claude Code — specs, decisions, learnings.
Source-checked CLI guides and model-aware planning for Claude Code, Codex, and Grok Build.
Cross-agent artifact workspace with provenance across Claude Code, Codex, Cursor, LangGraph.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/pathmodeio/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
