Resolve an absolute project path to retrieve indexed project documentation from your local knowledge base. Access section-level details for context-aware assistance.
Resolve an absolute project path to its indexed project documentation.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| project_path | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden itself. 'Resolve ... to documentation' implies a read-only lookup and communicates that the documentation is indexed, but it does not disclose failure behavior, indexing prerequisites, or whether any side effects 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?
The description is a single tight sentence with no filler and the key constraint 'absolute project path' is front-loaded. However, it is slightly terse and does not structure the optional limit behavior into the description.
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 only one required parameter and an output schema, the description is minimally sufficient for a basic call. It falls short on sibling differentiation and the semantics of the optional limit parameter, but the core invocation path is understandable.
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 0%, so the description must compensate. It adds meaning to project_path by specifying 'absolute', but it says nothing about the limit parameter, which remains only a title and default value.
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 names a specific action and resource: resolving an absolute project path into its indexed project documentation. It clearly distinguishes this from generic search/read operations by focusing on project-level context, though it does not explicitly contrast itself with sibling 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 gives no guidance on when to use this tool versus kb_search, kb_read, or kb_status. It implies the input should be an absolute path, but it never states when path-to-documentation resolution is preferred over sibling operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.