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

Annotations already declare read-only, idempotent, non-destructive behavior, so safety is covered. The description adds real value by disclosing the returned payload (key results, progress, alignment, recent comments), which is the main behavioral unknown since no output schema exists.

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?

A single well-formed sentence that front-loads the action and then qualifies the depth of the result. No filler, no redundancy with the title.

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?

With no output schema, the description's enumeration of returned content is exactly what is needed to make this call confidently. It falls short only on input guidance (ID format, not-found behavior), which for a one-parameter read is a minor gap.

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 coverage is 0% and the single required parameter objectiveId has no type or format documented anywhere. The phrase 'one objective' only vaguely implies addressing by identifier, adding no meaning about ID format, source, or lookup semantics.

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?

Specific verb ('Get') plus resource ('one objective') with an explicit enumeration of what 'in full' includes: key results, progress, alignment, and comments. It distinguishes itself from bare lookups, though it never names the sibling it contrasts with (e.g. get_okr_tree or list_objectives).

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 only implied by 'one objective in full' – an agent can infer this is the single-record deep-fetch versus list_objectives, but the description states no when-to-use condition, prerequisites, or preferred alternative such as get_okr_tree for hierarchical traversal.

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