list_namespacesList document corpus slices and their document counts to target queries to the correct area before asking for documents.
List the slices the document corpus is divided into, with how many documents each holds. Use this before ask_documents when a question clearly belongs to one area and you want to avoid another area answering it.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description is consistent with the annotations (readOnly, idempotent, non-destructive) and does not contradict them. It does not describe return format or potential errors, but for a simple listing operation, annotations already convey safety and idempotency. The description adds minor behavioral context (document counts) but nothing that misleads the agent. Given the strong annotations, this is sufficient.
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, consisting of two sentences. The first sentence states what the tool does, and the second provides a usage guideline. There is no redundant wording or unnecessary detail. The structure is clear and front-loaded with the primary purpose.
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 no parameters and a simple output (list of namespaces with counts), the description is complete. It states the action, the output content, and provides contextual guidance on when to use it. No output schema is provided, but the description implies a basic list structure. The tool's simplicity does not require further elaboration.
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 tool has zero parameters, so there is nothing to explain. The schema coverage is 100% with no required fields. The description correctly omits parameter details, and the baseline for no parameters is high. No additional parameter information is needed.
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 function: listing the slices (namespaces) of the document corpus along with document counts. It uses specific verbs ('List') and a concrete noun ('slices'), making the purpose unmistakable. It also differentiates from sibling tools by indicating when to use it ('before ask_documents'), which further clarifies its role.
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 provides a usage condition: 'Use this before ask_documents when a question clearly belongs to one area and you want to avoid another area answering it.' This direct guidance tells the agent exactly when to choose this tool over ask_documents, fulfilling the requirement for clear usage instructions. It effectively addresses the alternative scenario.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.