Retrieve the documents in a Knowledge Agent's corpus by supplying its agent ID, so you can inspect available source material before querying or managing the agent.
List the documents in a Knowledge Agent's corpus.
Args: agent_id: Knowledge Agent ID, from list_knowledge_agents.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | 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?
readOnlyHint=true already tells the agent this is a safe read, so the description's burden is light but it adds essentially nothing behavioral: no mention of pagination, result ordering, corpus size limits, or whether all documents are returned in one call. The only added detail is the conceptual scoping to a single agent's corpus, which is really purpose rather than 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?
One summary sentence front-loads the operation and scope, followed by a compact Args block with zero filler. The Python-docstring "Args:" formatting is slightly out of place for a tool description but costs nothing in length.
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 one-parameter read tool with an output schema and a readOnlyHint, the essentials are present and the ID provenance is covered. What's missing is the enumeration contract an agent needs before calling — whether results are paginated/truncated and how they're ordered.
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% and the schema only supplies a regex pattern, so the description carries the load — and it does, identifying agent_id as the Knowledge Agent ID and telling the caller where to get it (list_knowledge_agents). Minor gap: it doesn't clarify that an ID (not a display name) is required beyond the wording.
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?
States a specific verb and resource with an explicit scope ("documents in a Knowledge Agent's corpus"), which distinguishes it from read_document, upload_document, get_document_status, and delete_document. It never explicitly names those siblings, but the list-vs-single-read distinction is inferable from the wording.
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?
Usage is implied only: you use it to enumerate an agent's documents, and the Args note routes the caller to list_knowledge_agents to obtain the ID. There is no statement of when to prefer this over read_document/get_document_status or any prerequisite/exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.