knowledge_get

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the result includes brief file metadata and mentions file_id as an identifier, but it does not clarify the output structure or whether pagination or other limits apply.

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 concise sentence with the core action front-loaded. However, the trailing clause about file_id is ambiguous and slightly detracts from clarity despite the brevity.

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 1-parameter read-only retrieval tool, the description is minimal but lacks an explanation of knowledge_id, the relationship between knowledge_id and file_id, or when this tool should be used over knowledge_get_file. The missing output schema makes this gap more significant.

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 description does not explain the required knowledge_id parameter beyond the schema title. It introduces file_id, which is not an input parameter, potentially confusing agents rather than helping them understand what knowledge_id refers to.

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 states a clear verb ('Get') and resource ('a knowledge base'), and adds 'brief file metadata' to suggest its scope. However, it does not explicitly differentiate from the sibling knowledge_get_file, and the phrase 'brief file metadata' is somewhat ambiguous.

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?

There is no guidance on when to use this tool versus siblings like knowledge_list, knowledge_get_file, or rag_get_file. No alternatives or conditions are mentioned, leaving the agent to infer usage from the tool name alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.