get_document

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

No annotations are provided, so the description bears the full burden of behavioral disclosure. It discloses only the operation itself — it does not state what the response contains, how not-found cases behave (e.g., 404 vs empty result), or whether archived documents are retrievable given that archive_document/unarchive_document exist among siblings. 'From IT Glue' provides source-system context but no behavioral traits.

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 nine-word sentence with zero filler. The verb, resource, and identifier method are front-loaded, and every word contributes meaning.

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 itself is simple — two fully documented parameters, no nested objects, no output schema — so a short description is defensable. However, the large sibling list includes closely related document tools (search_documents, create_document, list_document_sections, publish_document) and the description gives the agent no help choosing among them, nor any indication of what the returned document object looks like. Adequate for basic invocation, but with clear gaps.

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%, with both 'id' and 'organization_id' already documented in the input schema. The description's 'by ID' phrasing merely echoes the schema's 'The document ID' without adding format, syntax, or relationship details, so the baseline of 3 applies — the schema 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 states a specific verb ('Get'), a resource ('document'), and an identification method ('by ID'), making the core operation unambiguous. However, it does not explicitly differentiate itself from the sibling tool search_documents — the implicit contrast between 'specific document' and 'search' is present but not made explicit.

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 alternatives. The sibling list contains search_documents, which is the obvious alternative for when a document ID is not known, but the description never references it or states any when/when-not conditions. The phrase 'by ID' faintly implies the caller must possess an ID, but this is inference rather than explicit guidance.

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