Leemu OKRs

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

Annotations already disclose the safety profile (non-read-only, non-destructive, non-idempotent, closed-world). The description adds a useful behavioral trait beyond annotations: comment visibility to everyone who can see the objective.

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?

Two short sentences with the action front-loaded and no wasted words. The visibility note is a concise, relevant second sentence.

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 simple two-parameter mutation tool with annotations covering safety and no output schema, the definition is minimally adequate. It leaves parameter semantics and return behavior unstated, which is a gap but not critical given the simple schema.

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%, so the description must compensate for two required parameters. 'To an objective' loosely maps to objectiveId, but there is no explanation of content format, constraints, or objectiveId sourcing beyond the schema's raw type and length limits.

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 (Add) and resource (comment) with the target (an objective). No sibling tool adds comments, so the action is unambiguous.

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 by the action and target, but there is no explicit when-to-use guidance or mention of alternatives. Since no sibling tool duplicates this behavior, the lack of exclusions is less harmful.

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

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

The annotations already mark this as destructive and non-idempotent. The description adds valuable context beyond that: it clarifies the operation is a soft delete, that it is reversible from the web app, and that permanent deletion is not available through MCP. This meaningfully informs the agent about the actual impact.

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?

Two short sentences, front-loaded with the core action and immediately followed by the key behavioral constraint. Every phrase earns its place with no redundancy.

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 core mutation behavior (soft delete, reversibility, no permanent delete) is covered, which is important for a destructive tool. However, the unexplained 'archived' parameter is a notable gap in a 2-parameter tool, and there is no guidance on repeated invocation or related siblings.

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?

With 0% schema description coverage, the description must compensate, but it does not explain the 'archived' boolean parameter (e.g., archived=false for unarchiving) nor the 'keyResultId' format. Only the implicit resource is mentioned, leaving the parameters largely undocumented.

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 specific action ('Archive') and resource ('a key result'), and distinguishes itself from read/update siblings like get_key_result and update_key_result. It does not explicitly differentiate from archive_objective, but the resource difference is obvious.

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: use this to remove/hide a key result, and permanent deletion is not available through MCP. However, it doesn't state when to choose this over updating or other alternatives, nor does it mention any prerequisites or when-not conditions beyond the deletion limitation.

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

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

Annotations declare destructiveHint=true and readOnlyHint=false, which alone would suggest irreversible loss; the description meaningfully overrides that impression by disclosing soft-delete semantics, retention, and restorability. It does not address idempotency (annotations say idempotentHint=false) or permission requirements, so it is strong but not exhaustive.

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?

Three short sentences, front-loaded with the action and the key semantic caveat, with no redundant restatement of the tool name. Each sentence carries distinct information.

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 two-parameter tool with no output schema and annotations covering safety, the description supplies the essential behavioral context (soft delete, retention, no hard delete via MCP). It omits side effects on child key results and any permission prerequisites, which would round it out.

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 50%: the archived flag is self-documented, but objectiveId has no description in either place. The description adds no parameter-level detail, and its statement that restore happens 'from the web app' is slightly at odds with the schema's archived=false restore path via MCP.

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?

'Archive an objective' is a specific verb+resource, and the description immediately narrows the meaning of 'archive' to a soft delete, which is the one thing an agent could get wrong here. It is clearly distinguishable from siblings such as archive_key_result and update_objective by resource and effect.

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 (call this to archive an objective) and it usefully rules out permanent deletion via MCP, but there is no explicit guidance on when to archive vs. update or delete-adjacent siblings. The restore path is mentioned only for the web app, so the agent gets no routing guidance for the 'unarchive' case.

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

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

Annotations already declare the write profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), but the description adds the concrete side effect: it stores the update and, when a value is provided, moves the key result to that value, which is not derivable from the annotations alone. It stops short of describing return data or conflict 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?

Two sentences, front-loaded with the core action and then the conditional guidance. No filler, though the second sentence packs two separate ideas (side effect and field guidance) that could be split for sharper scanability.

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 an 8-parameter mutation tool with 38% schema coverage and no output schema, the description covers the primary behavior and two optional fields but omits how the other fields (comment, achievements, keyResultId) are expected to be used and says nothing about what the call returns.

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 only 38% across 8 parameters; value, progress, and confidence are already documented in the schema. The description adds usage context for blockers and nextSteps, but achievements, comment, and keyResultId remain unexplained in both the schema and the description, so it only partially compensates for the coverage gap.

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 ("Submit a progress check-in on a key result") and clarifies it is the primary mechanism for recording weekly progress, which separates it from siblings like add_comment or update_key_result_value. It does not explicitly name an alternative, so it stays short of a 5.

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?

"This is the primary way to record weekly progress" implies when to reach for this tool, and "include blockers and next steps when the user mentions them" gives a conditional trigger. However, no alternative tool is named and no when-not guidance is offered, leaving the agent to infer the split with update_key_result/update_key_result_value.

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

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

Annotations already declare this is a non-idempotent, non-destructive write, so safety is covered. The description adds useful domain constraint context by stating key results must be quantifiable and require initial, target and direction values, but it says nothing about return format, ownership/permission needs, or validation failures beyond the schema's ownerId note.

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?

Two short sentences, well front-loaded with the primary action followed by the quantifiability requirement. No filler, though the second sentence could be tightened or expanded into more concrete field guidance.

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 9-parameter mutation tool with no output schema and very low schema description coverage, the description is thin: it omits what the created result looks like, defaults for unit/weight, and the enum meanings. Annotations cover the safety profile, but the parameter surface remains largely unexplained.

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 only 11% across 9 parameters, so the description must carry weight. It does clarify three parameters in domain terms (initial value, target value, direction of travel), but leaves unit, weight, title, objectiveId and description entirely to the raw schema, so it only partially compensates.

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 ('Add a measurable key result to an existing objective'), which clearly separates it from create_objective and the update_key_result family. It stops short of naming those siblings, so the agent must infer the boundary itself.

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?

'to an existing objective' implies the precondition that the parent objective must already exist, giving some implied usage context. However, there is no explicit guidance on when to choose this over create_objective or update_key_result_value, and no stated exclusions.

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

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

Annotations already declare this is a non-read-only, non-destructive, non-idempotent write. The description adds meaningful behavioral context the annotations lack: authorization requirements per level and the atomic, all-or-nothing creation of inline key results. It does not warn about duplicate creation (relevant given idempotentHint=false) or the 10-key-result cap.

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?

Three tight sentences with the core action front-loaded and no padding. The opening 'Create an objective' slightly restates the title, but the remaining content is dense and every clause carries information.

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 an 11-parameter mutation with no output schema and very low schema coverage, the description is only partially complete. Level semantics and atomic key results are covered, but the majority of optional fields (dates, owner, cycle, parent, strategic goal) are left unexplained, and nothing describes what the call returns.

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 only 18% across 11 parameters, so the description must carry weight. It explains the level enum semantics and their permission implications and clarifies inline keyResults behavior, which is useful. But cycleId, ownerId, parentId, startDate, endDate, description, and strategicGoalId receive no explanation anywhere, leaving most of the surface undocumented.

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 ('Create an objective') and adds a scope distinction by noting that key results can be supplied inline and are created atomically, which implicitly separates it from the create_key_result sibling. It stops short of naming the alternative explicitly, so the differentiation is inferable rather than stated.

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?

Gives clear precondition guidance for the level parameter: PERSONAL needs nothing extra, TEAM requires team membership, COMPANY requires admin rights. That is genuine when-to-use context. It does not cover when to create a standalone key result instead of inlining it, nor any exclusions.

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

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

Annotations already declare this is a non-read-only, non-idempotent, non-destructive write. The description adds two meaningful pieces beyond that: the company-admin permission requirement and the direct-vs-reviewed semantics. It does not mention duplicate-creation risk from non-idempotency, which is a minor remaining gap.

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?

Three short sentences, front-loaded with the core action, then the permission prerequisite, then the alternative-path guidance. No filler.

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?

Covers the action, permission requirement, and alternative path, which is enough to invoke the tool, but with 0% schema description coverage and no output schema the description leaves the meaning and effects of status/priority/targetDate entirely unstated. Adequate 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 0% across 5 parameters, so the schema provides only names, types, and constraints with no meaning. The description adds nothing about title, status, priority, targetDate, or description semantics, so it does not compensate for the coverage gap beyond the required 'title'.

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 ('create') and resource ('strategic goal'), and explicitly distinguishes itself from the propose_strategic_goal sibling by contrasting direct creation with a review path. An agent can tell this apart from other create_* tools (create_objective, create_key_result) by the goal resource.

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?

Gives an explicit condition for choosing the alternative path: 'Use propose_strategic_goal instead if the goal should be reviewed first.' This is clear when-to-use/when-not guidance tied to a named sibling, leaving little to inference.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed world), so the bar is lower. The description still adds meaningful context: results are permission-scoped ('OKRs you can see') and the output is aggregated/rolled up rather than raw records. It stops short of describing report size, pagination, or aggregation rules.

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?

Two short sentences, no filler, with the action and scope front-loaded ahead of the use case. The trailing quoted question is mildly redundant but earns its place as a routing cue.

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?

There is no output schema, so the description should ideally carry more of the return-shape burden; the rollup dimensions hint at structure but the two undocumented parameters (level, teamId) and the absence of any default-behavior statement leave gaps for a filtering report tool.

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 only 33% (only cycleId is documented), so the description must compensate and does not. It name-drops 'level' and 'team' as rollup dimensions without explaining that they are filters, and 'status' is mentioned even though no such parameter exists, which risks misleading the agent.

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 ('Generate a progress report') plus scope ('across the OKRs you can see') and the rollup dimensions (level, team, status). It is distinguishable from the many get_*/list_* siblings, though it never names an alternative to contrast against.

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 line 'Use this to answer "how are we tracking?"' gives a concrete usage scenario, so context is implied rather than absent. However, it offers no when-not guidance and never mentions why an agent would pick this over get_at_risk_okrs, get_okr_tree, or get_check_in_compliance.

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

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

Annotations already declare the safe read-only, idempotent, non-destructive profile, so the bar is lower. The description adds genuine behavioral value by defining what counts as at-risk via the four criteria, though it does not describe the returned shape, ordering, or severity of the flagged OKRs.

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?

Two tightly packed sentences: the purpose and criteria are front-loaded before the usage hint. No filler or redundancy.

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 annotations carrying the safety profile and no output schema to explain, the description is largely sufficient for a read-only query tool. The 'approaching end date' criterion, which has no corresponding parameter to tune, is mentioned but its handling is left unstated.

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%, so the schema already documents staleDays, progressThreshold, and confidenceThreshold with defaults and ranges. The description's criteria loosely echo those parameters but add no syntax or interpretation beyond what the schema provides, so baseline 3 applies.

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 (identify at-risk OKRs) and enumerates the four qualifying signals (low progress, stale check-ins, low confidence, approaching end date). Clear and concrete, but it never explicitly names or contrasts a sibling like get_check_in_compliance or get_my_week, so the distinction is left to inference.

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?

"Use this to prepare for a review meeting or a weekly nudge" gives a clear situational trigger for invoking the tool. It stops short of naming alternatives or stating when another tool is the better choice, so no explicit exclusion guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so safety is covered. The description adds one genuinely useful behavioral detail — results are limited to 'the OKRs you can see' (permission scoping) — but says nothing about the shape of the report or how teams interact with results.

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?

Two tight sentences with the core purpose front-loaded and the use case trailing. No wasted words, though the second sentence is soft guidance rather than critical information.

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 read-only reporting tool with no output schema and only two params, this is roughly adequate — the agent knows what it gets (a compliance report over a window). It falls short on teamId semantics and on any indication of what the report contains.

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 only 50%: 'days' is documented in the schema, but 'teamId' has no description anywhere. The description's phrase 'in a given period' loosely gestures at the look-back window but never explains team scoping or what happens when teamId is omitted.

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+resource ('Report who has and has not submitted check-ins') and scopes it to a period and to visible OKRs. It contrasts implicitly with the raw 'list_check_ins' sibling by reporting compliance rather than listing entries, though it never names the sibling explicitly.

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?

'Useful for a weekly team review' hints at when to reach for it, but there is no explicit when-to-use vs. when-not, and no mention of the obvious alternative 'list_check_ins' or 'get_my_week'. Usage is implied rather than directed.

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

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

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so the safety profile is fully covered and the description adds no contradicting behavior. However, it says nothing about edge behavior (e.g. what is returned when no cycle is active) or what the resolved cycle object contains, so added value is modest.

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?

Two short sentences, zero filler, with the core action stated first and the usage hint second. Nothing could be removed without losing information.

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 trivial zero-param getter this is close to sufficient, but with no output schema the description should say what comes back (cycle id/name/dates) or what happens if no cycle is in progress; that missing edge case is the main 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?

Zero parameters, so the baseline of 4 applies and there is nothing for the description to disambiguate. It correctly implies the tool is callable with no arguments.

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+resource ("Get the OKR cycle") with a scoping qualifier ("currently in progress") that separates it from list_cycles and the other get_* siblings. An agent can pick this tool without opening the schema.

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?

Explicitly states the motivating scenario: resolving vague time references like "this quarter" into a concrete cycle. That is clear when-to-use guidance, but it never names the alternative (list_cycles) or states a when-not-to-use condition.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile needs no restatement. The description does add useful payload context ('full check-in history'), but says nothing about pagination limits, ordering of check-ins, or behavior when the ID isn't found — gaps that matter given no output schema.

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 verb and resource and wastes no words. Slightly compact for the amount of unexplained behavior underneath, but structurally clean.

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 correctly sketches the return (the key result plus its check-in history), which is the single most important thing an agent needs. However, it omits how checkInLimit bounds that history and what happens on a missing ID, so a calling agent can't fully predict the response.

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%, so the description carries the full burden, yet it never mentions keyResultId or checkInLimit. The phrase 'full check-in history' actually sits in tension with the checkInLimit default of 10, leaving the agent unaware that history may be truncated.

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 ('Get') and resource ('one key result') and adds scope ('with its full check-in history'), which implicitly separates it from the plural list_key_results. It stops short of explicitly contrasting with siblings, but an agent can distinguish it from list_key_results without opening the schema.

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 trailing clause 'so you can see how the metric has moved over time' implies the intended use case (trend inspection) but gives no explicit when-to-use criteria, prerequisites, or named alternatives aside from the implicit singular/plural distinction. Adequate but leaves the agent to infer routing.

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

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

Annotations already cover the full safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds real value by enumerating what the summary contains (owned KRs due for check-in, at-risk objectives, recent activity), which is the only signal into return shape since no output schema exists. It omits any mention of scope ('my' implies the authenticated user) or how staleDays reshapes results.

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?

Two tight sentences, purpose front-loaded, zero filler. Every clause contributes content the agent needs to decide relevance.

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 no-output-schema composite tool, the description partially compensates by listing summary contents, but it leaves the one parameter unexplained and gives no sense of scope or result size. Adequate but with a clear gap given the schema carries no param documentation.

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 single parameter staleDays (default 7, range 1-90) is completely absent from the description. With low coverage the description must compensate, and it does not — an agent gets no hint that a staleness window controls what appears in 'recent activity.'

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 aggregation: key results due for check-in, objectives at risk, and recent activity — an agent can tell this is a composite 'attention/status' view rather than a raw list. However, it never names or contrasts with the obvious siblings it aggregates (get_at_risk_okrs, list_check_ins), so differentiation is left to inference.

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?

'Ideal starting point for a weekly update' gives an implied usage context, but there is no explicit when-not-to-use guidance and no routing to alternatives like get_at_risk_okrs for a deeper at-risk view. Usage is suggested rather than prescribed.

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

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.

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is fully covered. The description usefully reveals the hierarchical return shape, but says nothing about auth, scope, or how deeply the tree is populated.

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?

Two tight sentences with the purpose front-loaded and the use case second. No filler, though it is fairly terse for a hierarchy tool.

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 read-only, no-output-schema tool, the description adequately conveys the tree structure an agent gets back. The omission of any mention of cycleId's role leaves a small gap, but the core need is met.

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 only 50%: rootObjectiveId is documented in the schema, but cycleId has no description anywhere. The tool description mentions no parameters at all, so it fails to compensate for the undocumented cycleId.

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 ('Get the OKR hierarchy as a tree') and describes the structure returned (company → team → personal). It implicitly contrasts with flat siblings like list_objectives and get_objective by emphasizing the tree form, but never names an alternative explicitly.

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?

Gives a use context ('understanding organizational alignment and spotting orphaned objectives') but no explicit when-to-use versus alternatives or when-not-to-use. The agent can infer intent, but routing against list_objectives/get_objective is left to inference.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety behavior is covered by structured data. The description adds one genuinely useful behavioral note: objectives you lack permission to view are silently omitted, which is not derivable from annotations. It does not, however, cover error behavior for a bad ID or return shape.

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?

Two short sentences, front-loaded with the core action, and the second sentence carries the access-control caveat. Nothing wasteful.

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?

There is no output schema, so the description should convey return behavior; it hints at embedded objectives but not overall shape. The permission-based omission caveat is valuable, but for a one-param tool with no schema docs and no output schema, more detail on identifier format and returned structure would help.

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% for the single required 'strategicGoalId' parameter, yet the description never mentions the parameter, its expected identifier format, or where to obtain it. With one undocumented parameter the description should compensate but entirely omits parameter meaning.

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 (Get) and resource (strategic goal) and distinguishes it from the sibling list_strategic_goals by specifying retrieval of a single goal. An agent can immediately tell this is the single-item fetch, not the list.

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 implies you call it when you need one strategic goal with its aligned objectives, but it offers no explicit when/when-not guidance or named alternatives like list_strategic_goals or get_objective. Usage is inferable but not spelled out.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered by structured data. The description adds the useful scope fact that members and objectives are bundled into the response, but says nothing about permissions, error behavior, or missing-team handling.

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 front-loaded sentence with no filler. It is efficiently sized for the tool's simplicity, though it is arguably too terse to carry the parameter and routing information the schema omits.

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-only lookup with no output schema, the description covers what the tool does and what it returns, which is close to sufficient. The unresolved teamId semantics are the main completeness 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 description coverage is 0%, so the description carries the full burden for teamId, yet it never identifies the parameter or its expected format/origin. The only hint is the implied singular lookup, which leaves the agent guessing where a valid teamId comes from.

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 and resource ('Get one team') and adds the composition of the response (members and objectives), which distinguishes it from list_teams and list_team_members. It does not, however, name or contrast with those siblings, so it falls short of a 5.

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 statement of when to use this tool versus list_teams or list_team_members, nor any prerequisite such as needing a teamId from list_teams first. Usage is only weakly implied by 'one team.'

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the visibility scope ('OKRs you can see') but says nothing about ordering, pagination, or result shape.

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?

Two tight sentences with the resource and scope front-loaded and the use case immediately after. No filler, though it is quite short for a four-parameter tool.

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 read-only list tool with no output schema, the description covers purpose and intent but omits result ordering, pagination behavior, and any explanation of the filter parameters. It is adequate but has visible 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 only 50%, and the description mentions no parameters at all. It does not clarify the default/limit semantics, the 'me' shortcut for createdById, or the since/keyResultId filters, leaving the agent to read the schema.

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 clear verb+resource (list check-ins) and a scope qualifier ('across the OKRs you can see'). It does not name or distinguish itself from siblings like create_check_in or get_check_in_compliance, so it stops short of a 5.

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?

'Use this to review progress updates, blockers and confidence trends' gives a genuine use context, but offers no when-not guidance and does not point to alternative tools for narrower queries (e.g., compliance or single-KR lookups).

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

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

Annotations already establish the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false, openWorldHint=false), so the description only needs to add context. It adds the workspace scoping but says nothing about ordering, filtering by status, or pagination 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?

A single sentence with no waste, and the resource is front-loaded. It is perhaps slightly too terse for a tool with an undocumented filter parameter, but it is well structured.

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 simple read-only list tool with no output schema, the description covers the resource and workspace scope adequately. However, it leaves the status filter and the nature of the returned list (ordering, whether archived cycles are included) entirely unexplained.

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 single status parameter has 0% schema description coverage, so the description must compensate, and it does not. It never mentions the status filter, its four enum values, or what happens when it is omitted (all cycles presumably).

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?

Clearly states a specific verb (List) and resource (OKR cycles), and even clarifies what a cycle is (quarters, halves) plus its scope (your workspace). It does not explicitly differentiate from the sibling get_current_cycle, but the resource is concrete enough to distinguish on name alone.

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?

No guidance on when to use this versus alternatives such as get_current_cycle (for the active cycle) or list_objectives. The agent gets no signal about whether this is for browsing cycle definitions or fetching the current one.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds permission scoping ('visible to you') and notes that progress is included, but says nothing about pagination, default limits, or archived-handling 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?

Three short sentences, front-loaded with the core action, with the routing hint last. Nothing is wasted, though the ownerId sentence partly duplicates the schema.

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 read-only list tool with no output schema, the description conveys scope, filtering, and that progress is returned. Missing details on pagination/limit and archived results keep it from full completeness.

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 only 25% (only ownerId is documented, and the description repeats it). The description explains the owner/objective filter axis but leaves limit and includeArchived completely unaddressed in both schema and prose.

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+resource ('List key results') plus scope ('visible to you') and returned content ('current progress'). It is distinguishable from list_objectives and get_key_result, though it doesn't explicitly name those siblings.

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?

Gives clear filtering contexts ('Filter by objective or owner') and a concrete routing tip for the 'me' ownerId case. No explicit when-not-to-use or named alternatives, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered by structured data. The description adds one genuinely useful behavioral fact — results are hard-scoped to the caller's permission scope and never leak outside it — but omits pagination/limit behavior and how archived objectives are handled by default.

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?

Three short sentences, front-loaded with what the tool returns, then the filter capability, then the permission caveat. No filler, no restating of the tool name, and each sentence adds new information.

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 and seven all-optional parameters, the description carries more burden than it takes on: 'with progress' is not explained (per-object percentage? key-result rollup?), the default exclusion of archived objectives and the 100-item limit cap go unmentioned, and there is no hint of result ordering or pagination.

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 only 14% (just ownerId), so the description must compensate. It does: it names five of the seven filter dimensions (level, status, cycle, team, owner), which maps cleanly onto level, status, cycleId, teamId and ownerId. It leaves limit and includeArchived undocumented, but the coverage of the filter axis is the more important semantic gap to fill.

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+resource ('List objectives') plus two value-adds: progress inclusion and permission scoping. Distinguishable from sibling get_objective (single) and list_key_results (different resource), but it does not explicitly name an alternative or state how it differs from get_okr_tree beyond the resource noun.

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 filter list implies the usage context (browse objectives by level/status/cycle/team/owner), but there is no explicit when-to-use guidance, no named alternative such as get_okr_tree or get_objective, and no statement of when a caller should prefer this over those siblings.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and closed-world scope, so safety is covered. The description adds the useful scoping fact that results are limited to proposals the user created and include review status, but says nothing about pagination, ordering, or default filtering.

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 front-loaded sentence with no filler: verb, resource, scope, and returned attribute. Every word earns its place.

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?

No output schema exists, so the description could carry more about the shape of returned proposals, and the status filter's default behavior is undocumented. For a one-parameter read-only list tool with full annotation coverage this is adequate but leaves real 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 coverage is 0% for the single status parameter, but its enum values (DRAFT, ACCEPTED, REJECTED, CREATED) are largely self-explanatory. The description hints at 'review status' without explaining how the status filter maps to those enum values or what happens when it is omitted.

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 (list proposals) and narrows scope to OKR and strategic goal proposals 'you have created' with their review status. It does not differentiate itself from siblings like list_objectives or list_strategic_goals, so an agent must infer the boundary.

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 gives no when-to-use guidance, no alternatives (e.g., list_objectives for accepted objectives), and no mention of prerequisites or the default filter behavior. The 'you have created' phrasing implies a personal scope but never states when to prefer this tool.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and closed-world behavior, so the safety profile is covered. The description adds domain context about what a strategic goal is relative to objectives, but does not disclose filtering behavior, pagination, default status, or auth requirements.

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 sentence, front-loaded with the action and resource, with no filler. Every word earns its place.

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 simple list tool with rich annotations and no output schema, the description is adequate but leaves a notable gap: the only parameter (status) is unexplained in both schema and description. It also does not mention ordering, pagination, or default filtering behavior.

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 single optional status enum parameter is not mentioned at all in the description. The enum values in the schema give raw options, but the description adds no meaning about what status filtering does or how it interacts with the returned goals.

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+resource ('List the multi-quarter strategic goals') and adds hierarchy context ('that objectives roll up into'), which helps distinguish the entity from objectives. However, it does not explicitly differentiate this tool from siblings like get_strategic_goal, list_objectives, or create_strategic_goal.

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 provides no when-to-use guidance, no prerequisites, and no alternatives. An agent must infer that this is the bulk-listing tool versus the singular get_strategic_goal or the objective-listing sibling.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description only adds that roles are returned alongside members, which is useful context but modest given how much the annotations carry.

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?

Two short sentences, no filler, with the core purpose front-loaded and the use case following. Every clause earns its place.

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 simple, non-destructive read with a fully documented single optional parameter and annotations covering safety, the description is essentially complete; 'with their roles' gestures at the return content even without an output schema. Sibling disambiguation is the only meaningful omission.

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?

With a single parameter and 100% schema description coverage, the schema already documents teamId, including the 'omit to list across all teams' behavior. The description adds no parameter-level meaning beyond what the schema provides, so the baseline 3 applies.

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 ('List members of a team') plus a returned attribute ('with their roles'), so the operation is unambiguous. It does not differentiate itself from the nearby siblings list_workspace_members or list_teams, which a careful agent would want spelled out.

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?

'Useful for assigning owners when creating objectives or key results' implies a usage context but never states when to prefer this over list_workspace_members, nor any prerequisites or exclusions. The guidance is suggestive rather than directive.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, non-destructive). The description adds genuine behavioral context beyond them: results are permission-scoped, so an admin's result differs from a regular member's. It does not mention pagination or ordering, which keeps it short of a 5.

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?

Two short sentences, no redundancy, and the core purpose is front-loaded ahead of the visibility caveat. Every clause earns its place.

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 zero-parameter list tool with no output schema, the description covers the one nuance an agent needs — that the returned set depends on the caller's role. Minor gaps remain (no mention of result size, ordering, or pagination), but nothing critical is missing.

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 takes zero parameters, so the schema imposes no semantic burden and the baseline is 4. The description correctly adds no parameter discussion, and its visibility note is about result scope rather than inputs.

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 ("List teams") plus the scoping rule that governs the result set. It is clear what the tool returns, though it does not explicitly distinguish itself from siblings like get_team or list_team_members.

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 — call this to enumerate teams — but there is no explicit when-to-use guidance or routing to alternatives such as get_team for a single team or list_team_members for membership detail. Adequate but leaves the agent to infer.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds the admin-permission requirement, which is genuine value beyond the annotations, but says nothing about the return shape or whether results are paginated.

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?

Two short sentences with no filler; the core action is front-loaded and the permission constraint follows immediately. Nothing is redundant.

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 simple read-only list call with rich annotations and no output schema, this is minimally adequate. It is missing the one thing the structured data does not supply: an explanation of the includeInactive parameter and any indication of result size or pagination.

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?

There is one parameter (includeInactive) with 0% schema description coverage, so the schema does not explain it and the description ignores it entirely. The agent cannot tell from either source that this flag controls whether deactivated members appear in the result.

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 ('List all members of the workspace'), which is unambiguous on its own. However, it never distinguishes itself from the sibling 'list_team_members', leaving the workspace-vs-team scope boundary for the agent to infer.

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 'Requires workspace admin permissions' clause is a useful precondition, but there is no explicit when-to-use guidance and no mention of the obvious alternatives (list_team_members, whoami). Usage is implied rather than stated.

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

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

Goes well beyond the annotations: it discloses that the proposal is NOT applied immediately, that it lands in a human review queue, that it returns an approval link, and that a human can approve, edit or reject. The annotations only say this is non-read-only, non-destructive and non-idempotent; the description supplies the actual workflow semantics.

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?

Four tight sentences, front-loaded with what happens and what is returned, then the usage condition and the alternative. No filler or restated metadata.

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?

No output schema exists, and the description usefully explains the return (a review-queue link), so that gap is covered. But for a 6-parameter tool with a nested keyResults array and multiple enums, the absence of any parameter guidance or validation rules leaves the calling contract incomplete.

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 only 17% (just the timeline field), yet the description names no parameters at all. The nested keyResults shape, the level enum (COMPANY/TEAM/PERSONAL), teamId, and the unit/direction enums are left entirely undocumented, so the low-coverage schema is not compensated for.

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 ('propose') and a specific resource composite ('a complete objective with its key results'), and immediately clarifies the outcome. It is distinguishable from create_objective and update_objective without opening either schema.

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?

Explicitly says when to use it ('when drafting a new quarter's OKRs') and names an alternative for the opposite case ('for small edits to an existing objective, use update_objective instead'). It does not, however, disambiguate against the likely-confusable sibling create_objective or propose_strategic_goal, so the routing is not fully closed.

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

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

Annotations declare a non-read-only, non-destructive, non-idempotent mutation, and the description adds genuinely useful context beyond that: the goal is staged as a proposal and is not applied until an admin approves it in Leemu. It does not detail what happens on rejection or whether duplicate proposals are possible.

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?

Two sentences, front-loaded with the action and the key approval constraint, with no filler. Every sentence earns its place.

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 mutation tool with no output schema and 25% param coverage, the description adequately covers the approval workflow but says nothing about the required title/description inputs or what the caller receives back. It is minimally complete but has 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 coverage is only 25% — only 'priority' has a description in the schema. The description adds no meaning for title, description, or targetDate, so the undocumented parameters are left unexplained in both places.

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 (propose) and resource (strategic goal) with scope (multi-quarter) and purpose (for human review). It implies a distinction from create_strategic_goal via the 'review' framing but never names that sibling, leaving the differentiation implicit.

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 'for human review' framing implies when to reach for this tool rather than a direct create, but no alternative is named and no exclusions or prerequisites are given. Usage is implied rather than stated.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world. The description adds genuinely new context beyond them: 'reads no workspace data' clarifies there are no data prerequisites, and 'get concrete improvement suggestions' indicates the kind of output returned.

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?

Three short sentences, front-loaded with what the tool does, followed by side-effect profile and usage trigger. Every sentence earns its place with no filler.

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 simple, read-only, no-output-schema analysis tool, the description covers purpose, side effects, and timing adequately. The one real gap is the undocumented input parameters, which the description does not fill.

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 only 33% — only 'detailed' is documented, while 'title' and 'description' have no schema descriptions. The tool description never compensates for this, giving no hint about what 'title' vs 'description' should contain or their length limits.

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+resource ('Score a proposed objective') and the exact rubric applied (SMART), plus the concrete value delivered ('improvement suggestions'). No sibling tool performs scoring, so it is unambiguously distinct from the create/update/list tools in the set.

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?

Gives an explicit workflow trigger: 'Use it before proposing OKRs to raise their quality,' which ties it to the sibling propose_okr_set. It does not state when the tool is unnecessary or name a contrasting alternative, so it stops short of a 5.

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

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

Annotations only declare it is a non-readonly, non-destructive, non-idempotent write. The description adds nothing about partial vs full updates, what happens to omitted fields, whether changes require permissions, or reversibility. For a mutation tool with 8 params, this is thin.

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 efficient sentence that front-loads the verb and resource. No waste, though the terse field list leaves unexplained items.

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, no annotations of substance, 0% schema coverage across 8 parameters, and three enum/range-constrained fields, the description is far too thin to let an agent call this correctly.

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%, so the description carries the full burden. It names title, description, target, direction, unit, and weight, but says nothing about their semantics, allowed values, or ranges, and omits initialValue entirely while 'target' does not exactly match the targetValue parameter.

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 (update) and resource (key result definition) and lists the editable fields. It does not distinguish itself from the sibling update_key_result_value, which the agent must infer from the word 'definition'.

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?

No when-to-use guidance, no mention of the keyResultId prerequisite, and no routing to or away from update_key_result_value or get_key_result. The agent is left to infer the distinction between updating a definition and updating a value.

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

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

Annotations cover the safety profile (non-read-only, non-idempotent, non-destructive), and the description adds real behavioral context beyond them: this overwrites the value directly and does NOT create a check-in, so history is lost. It omits permissions/validation details, but for a simple field write this is solid.

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?

Two sentences, zero filler, with the core behavior ('only the current value', 'without creating a check-in') front-loaded before the alternative-tool routing.

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?

There is no output schema and no nested objects, so the description need not explain returns. It covers purpose, sibling routing, and the key side effect; only parameter format/validation detail is missing for a two-param mutation.

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%, so the description carries the full burden for two params. It implies keyResultId selects the target and currentValue is the new value, but gives no format, unit, range, or absolute-vs-delta guidance for the numeric value.

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 (update), resource (key result value), and explicitly bounds the scope to 'only the current value' versus full updates. An agent can distinguish it from both update_key_result and create_check_in without opening any schema.

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?

Names the alternative (create_check_in) and the exact condition that selects it (the user is describing progress), plus the reason (preserves narrative history). This is explicit when-to-use / when-not-to-use guidance rather than inferred.

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

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

Annotations already declare the write profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), so the baseline bar is lower, but the description adds nothing beyond them. It does not say whether this is a partial update (only objectiveId is required), what happens to omitted fields, or what side effects hitting key results or cycle alignment may have.

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 tight sentence, front-loaded with the verb and resource, with no filler. Slightly dense as a comma list, but every token carries a field name and nothing is wasted.

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 10-parameter mutation tool with no output schema and only baseline annotations, the description is thin. It omits partial-update semantics, permissions, and any side effects on key results or parent/child objectives, leaving an agent guessing about behavior after the call.

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% against 10 parameters, so the description must compensate, and it does name roughly eight of them (title, description, status, dates, cycle, parent, strategic goal). It adds no format or constraint detail, though — the status enum values, weight range 0-10, and objectiveId itself are left entirely to the schema.

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 ('Update') plus resource ('objective') and an enumeration of the mutable fields, so the agent knows exactly what changes. It does not differentiate from the sibling mutators update_key_result and update_strategic_goal, which is the only thing keeping it from a 5.

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 statement of when to use this versus update_key_result/update_strategic_goal, no prerequisites (e.g., permissions, objective must exist), and no note on read-before-write. The agent gets a field list but no routing guidance.

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

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

Annotations already establish this is a non-destructive, non-idempotent write (readOnlyHint=false, destructiveHint=false). The description adds a genuinely useful behavioral fact not in the annotations — that company admin permissions are required — but says nothing about partial-update semantics, reversibility, or side effects.

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?

Two short sentences with no filler, so it is efficient — but its brevity reflects under-specification rather than tight writing. Front-loading the verb is fine, yet nothing substantive follows it.

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 six-parameter mutation tool with no output schema, no nested objects, and 0% schema coverage, the description is far too thin. It never explains what the update changes, whether fields are optional, or what happens on success/failure.

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?

Six parameters with 0% schema description coverage, and the description names none of the updatable fields (title, status, priority, targetDate, description). An agent gets no help understanding what can be changed, whether the update is partial, or what the status enum means.

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?

"Update a strategic goal" is essentially a restatement of the tool name and title; it adds no scope, no fields touched, and no differentiation from siblings like update_objective or update_key_result. Only the permission clause adds any new information.

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?

No when-to-use guidance, no prerequisites beyond the permission note, and no routing to alternatives such as update_objective, update_key_result, or propose_strategic_goal. The agent must infer context entirely.

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

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

Annotations already establish readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely useful context beyond that: it enumerates the data exposed (role, memberships, effective permissions) and positions the call as an authorization-discovery step, which no annotation conveys.

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?

Two sentences, zero filler, and the highest-value guidance (call it first) is front-loaded in the second sentence. Every clause carries information.

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 carries the burden of return-value disclosure and does list the four categories of data returned, which is sufficient for a zero-parameter, read-only tool. Exact response shape or a sample payload is not provided, which is the only remaining 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. No misleading call-shape hints are given either.

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 (Return) plus a precise resource set (identity, role, team memberships, effective permissions) scoped to the authenticated user. No sibling tool returns caller identity, so it is trivially distinguishable from the surrounding OKR/team tools.

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?

"Call this first ... before attempting other operations" gives explicit sequencing guidance and a clear motivation (permission discovery). It lacks an explicit when-not clause, but there is no competing alternative among the siblings to name.

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