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

Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description discloses two critical behaviors: approving locks the period's worklogs against further edits, and the tool requires user confirmation — either via the client's confirmation prompt or a two-step fallback returning a confirmToken that must be echoed. This is exactly the kind of consequence and protocol disclosure that annotations cannot convey.

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 sentences with no filler: purpose in sentence one, the locking consequence in sentence two, and the confirmation protocol in sentence three. Information is front-loaded correctly. The only blemish is the cryptic "see MCP_CONFIRM_MODE" reference, which assumes environmental knowledge the agent may not have.

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 explaining the response contract, and it does: the two-phase flow (preview + confirmToken on first call, execution on repeat) effectively defines what the caller should expect. Combined with 100% parameter coverage and annotations declaring destructiveness, this is nearly complete; minor gaps are unspecified error cases (already approved, not yet submitted) and the final success response shape.

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% and each parameter already carries rich semantic descriptions (e.g., 'to' defaults to the period containing 'from', 'from' points to tempo_get_periods, confirmToken explains the two-step fallback, reviewerAccountId points to tempo_get_timesheet_approvals_waiting). The description's mention of the confirmToken flow reinforces the schema without adding much beyond it, 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?

The description opens with a specific verb and resource — "Approve a user's submitted timesheet for the given period" — and immediately frames it as a "Reviewer action," which separates it from sibling tools like tempo_submit_timesheet, tempo_reject_timesheet, and tempo_reopen_timesheet. The added locking consequence further pins down what this specific action does versus its approval-family 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?

The description establishes a clear usage context: this is a reviewer's action against an already-submitted timesheet for a given period, with a mandatory confirmation protocol. It does not explicitly name alternatives or exclusions (e.g., use tempo_reject_timesheet to reject, tempo_reopen_timesheet to undo), so it falls short of 5, but the reviewer/submitted framing provides clear enough context for an agent to select it over the submission and retrieval 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?

The description meaningfully explains the confirmation flow: a native confirmation prompt where supported, otherwise a two-phase preview/confirmToken fallback. This goes beyond the annotations, which only indicate mutation/destructive potential, and gives the agent critical interaction context.

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 carry the full purpose and the non-obvious confirmation behavior. The content is front-loaded and every word earns its place; no filler or repetition.

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 description is complete for selection and invocation: it states the action, covers the confirmation behavior, and the schema covers all 9 parameters and their constraints. The only minor gap is that it does not describe the final success response, but with no output schema this is a small 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?

Schema description coverage is 100%, so the schema already documents every parameter, including confirmToken's special role. The description adds a useful high-level view of the confirmation flow but does not add new per-parameter meaning beyond what the schema already provides.

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 opens with 'Create a new Tempo account,' which names a specific verb and resource. This clearly distinguishes the tool from siblings like tempo_update_account and tempo_delete_account, leaving no ambiguity about what the tool does.

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 makes the intended use evident: use this tool when creating a new Tempo account. It does not explicitly name alternative tools or exclusion conditions, but the verb 'create' plus the sibling set gives clear contextual 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description discloses a significant behavioral trait: the tool requires user confirmation, and in non-elicitation environments the first call returns a preview and confirmToken rather than executing. This is exactly the kind of behavioral context an agent needs to avoid prematurely invoking a destructive operation.

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 deliver the core purpose, the confirmation behavior, the fallback mechanism, and the confirmToken repeat-call rule. Every clause earns its place and the most important behavioral caveat is front-loaded.

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 15 parameters, 100% schema coverage, and no output schema, the description covers the essential operational flow well: confirmation, preview, and confirmToken handling. It does not describe the success response shape, but the confirmation behavior is the critical missing piece that the description supplies, making it sufficiently complete for an agent to invoke the tool 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?

The schema already documents all 15 parameters with 100% coverage, so the baseline is 3. The description adds a little semantic framing by tying 'user or generic resource' to assignee types and 'issue or project' to plan item types, but it does not add detail beyond what the schema already provides for individual parameters.

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 ('Create'), a specific resource ('a new Tempo plan'), and the planning context ('resource allocation for a user or generic resource against an issue or project'). It clearly distinguishes this from worklog creation and from tempo_update_plan by framing it as creating a plan rather than modifying one.

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 clear context for when this tool is used: when a new plan needs to be created. It also gives crucial operational guidance about the confirmation flow, including the two-step fallback with confirmToken. It does not explicitly name alternatives like tempo_update_plan, but the 'Create a new' framing makes the usage context unambiguous.

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 description discloses a complete confirmation protocol not visible in the annotations: client-supported prompt first, otherwise a preview plus confirmToken on the first call, followed by a repeat call with the same arguments only after explicit user approval. This goes well beyond the readOnlyHint=false/destructiveHint=true signal. The destructiveHint label is semantically loose for a create operation, but the description's confirmation-first behavior is compatible with it, so there is no contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The purpose is front-loaded in a short first sentence, and the second sentence packs the entire confirmation fallback into a few clauses. It is somewhat dense and parenthetical, but no sentence 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 5-parameter create tool with no output schema, the description explains the essential interaction: confirmation, preview, and token-based second call. It does not describe the success response shape or the contents of the preview, but the reference to MCP_CONFIRM_MODE and the schema's confirmToken field cover the main invocation requirements.

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 input schema documents all five parameters at 100% coverage, including a detailed confirmToken description. The tool description adds process-level context about confirmToken usage but no parameter-specific meaning beyond the schema, so the baseline of 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?

The description opens with the specific verb-resource pair 'Create a new Tempo team,' which clearly identifies the action and target. This distinguishes it from sibling creation tools like tempo_create_worklog, tempo_create_plan, and tempo_create_account solely by the resource type, even without naming them.

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 first sentence explicitly states the trigger: creating a new Tempo team. It does not enumerate when-not-to-use conditions or alternatives, and the confirmation flow is operational context rather than usage guidance, but the purpose is clear enough to select this tool among the create_* 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?

Explicitly discloses a non-obvious two-phase confirmation behavior: a confirmation prompt where supported, otherwise a first call returns preview and confirmToken, and only a repeat call with that token proceeds. This adds significant value beyond the readOnlyHint=false and destructiveHint=true annotations.

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 with no filler: the purpose is front-loaded and the confirmation behavior follows immediately. The second sentence is dense but each clause earns its place by conveying a distinct part of the flow.

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 tricky confirmation flow is fully covered and all parameters are documented in the schema. However, since there is no output schema, it would help to state what a successful final call returns; the description also omits guidance on when to choose this over sibling worklog tools.

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%, and every parameter already has a meaningful description, including a thorough confirmToken explanation and the HTTP 400 warning for required attributes. The main description adds little parameter-level meaning beyond referencing the confirmation flow.

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 a new Tempo worklog.' The word 'new' clearly distinguishes it from update/delete siblings, and the description leaves no ambiguity about the operation being performed.

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 explicit when-to-use or when-not-to-use guidance, and no alternative is named. The schema's attributes parameter wisely points to tempo_get_work_attributes for required-attribute discovery, but the main description does not explain how this tool relates to tempo_update_worklog or other worklog tools.

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 flag this as destructive and not read-only, but the description adds valuable behavioral detail: it surfaces the confirmation requirement, explains the preview-plus-confirmToken fallback flow, and clarifies that a repeat call with the token is required when the client lacks support for a confirmation prompt. This goes well beyond the structured annotations.

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 primary action, followed by a compact explanation of the confirmation flow. Every clause contributes necessary information about a destructive operation, 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 destructive two-step deletion flow with no output schema, the description explains the confirmation mechanism, the preview token, and the requirement to repeat the call with the same arguments. An agent has enough information to invoke the tool correctly and to guide the user through confirmation.

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 both `key` and `confirmToken` thoroughly, including the token's restrictions. The description adds process-level context but does not materially enrich the meaning of the parameters beyond what the schema states.

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 opens with the specific verb-resource pair 'Delete a Tempo account' and identifies the required selector ('by its key'). It clearly differentiates from sibling delete tools like tempo_delete_worklog, tempo_delete_plan, and tempo_delete_team by naming the exact resource type.

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 clear operational context: it is used to delete a Tempo account, and the user must confirm before deletion occurs. It does not explicitly name alternatives or exclusions, but no competing delete-account sibling exists, so the guidance is sufficient for an agent selecting 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 mark destructiveHint=true, but the description adds crucial behavioral detail: the two-step confirmation fallback, the preview and confirmToken mechanism, and the requirement that the token come from the phase-1 response. This goes well beyond the annotations and meaningfully informs the agent's calling sequence.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the action and resource, and then provides the necessary confirmation details without 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?

The description covers the destructive action, both confirmation modes, and the token-based fallback, which is the core complexity of this tool. It does not describe the post-deletion response or error cases, but the essential calling contract is present and the annotations cover the destructive nature.

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 100%, and the confirmToken parameter already has a detailed description covering its lifecycle and restrictions. The tool description adds only a reference to MCP_CONFIRM_MODE and the notion of a preview, so it does not materially exceed what the schema already provides.

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 action ('Delete'), a specific resource ('Tempo plan (resource allocation)'), and the key selector ('by id'). This clearly distinguishes it from sibling tools like tempo_update_plan, tempo_get_plan, and tempo_delete_worklog.

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 clearly explains the confirmation protocol: the first call triggers a prompt or preview, and only a repeat call with the confirmToken proceeds. It does not explicitly contrast with alternative tools, but the delete action and confirmation flow provide clear context for when and how to invoke it.

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 mark this as destructive and non-read-only. The description adds the critical confirmation requirement and the two-step token fallback, which are not derivable from the annotations. This is valuable behavioral context beyond structured data.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no filler: it front-loads the core action and then explains the confirmation behavior. Every clause earns its place, and the reference to MCP_CONFIRM_MODE is appropriately placed.

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 destructive delete with no output schema, the description sufficiently explains the non-obvious confirmation behavior and token handling. It does not detail post-deletion effects or permissions, but those are not essential for the agent to invoke the tool 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 100%, and the schema already thoroughly documents both id and confirmToken, including the token's 'ONLY for the two-step confirmation fallback' semantics. The tool description only briefly references the token's role, adding little beyond 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?

The description opens with 'Delete a Tempo team by id', a specific verb+resource statement that clearly separates it from the many read/update siblings. Even without the title, the purpose is immediately 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?

The description gives explicit context for how and when the deletion proceeds: confirmation first, with a preview/confirmToken fallback for clients without elicitation. It does not enumerate alternatives or exclusions, but the core usage is clear and the confirmation flow is a strong form of 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 flag destructiveHint, but the description adds substantial behavioral context: the bypass flag can 'rip' a worklog out of an approved timesheet, and the confirmation flow prevents accidental deletion. This discloses high-risk consequences and operational requirements beyond the annotation.

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 dense sentences carry essential information: the core action, the dangerous bypass flag, and the full confirmation protocol. Every sentence earns its place, with safety warnings appropriately front-loaded before the procedural details.

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 destructive tool with no output schema and a two-step confirmation requirement, the description covers the confirmation modes, preview response, confirmToken handshake, and the bypass flag's consequences. It doesn't specify success/failure response details, but that is acceptable given the complexity and the existing coverage.

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 100% schema coverage the baseline is 3, but the description adds meaning beyond the schema by explaining the real-world impact of bypassPeriodClosuresAndApprovals and the confirmToken's role in the two-step process. This enriches understanding of when and how to set these parameters.

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 opens with 'Delete a Tempo worklog by id,' which is a specific verb+resource statement that clearly distinguishes this tool from tempo_create_worklog, tempo_update_worklog, and the various get/search siblings. The required id parameter leaves no ambiguity about the target 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?

The description gives clear context on when the tool is used (to delete by id) and explains the two confirmation modes and the bypass flag's implications. It doesn't explicitly name alternatives or state when not to use the tool, so it's clear but lacks explicit 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 readOnlyHint=true, and the description presents a read-only retrieve operation with no contradiction. It adds the useful key-vs-id routing caveat, but it does not disclose other behavioral traits such as auth requirements, rate limits, or what happens for a nonexistent id. This is acceptable but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences with no wasted words. It front-loads the core purpose in the first sentence, then adds the essential routing caveat in the second. It does not duplicate schema content.

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 single-account getter with fully documented parameters and a readOnly annotation, the description is complete. It states the operation, the identifier type, and how to convert a key to an id. The return value is obvious from the verb and resource, so the lack of an output schema is not a significant 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 100%, so the schema already explains both id and view in detail. The prose repeats that id is numeric and not a key, but adds little beyond the schema's existing description. It does not provide additional parameter semantics, so the baseline of 3 is appropriate.

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 first sentence names a specific verb ('Retrieve'), a specific resource ('a single Tempo account'), and the lookup criterion ('numeric id'). It also distinguishes this tool from key-based account operations and from tempo_search_accounts, so an agent can tell it apart from siblings 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 description explicitly tells the agent when this tool is not appropriate: if it has a key, it should first call tempo_search_accounts with keys to get an id. It also notes that update/delete operations are key-based, which prevents misuse. This is clear when-to-use and when-not-to-use 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=true, and the description adds the useful behavioral fact that the endpoint is not paginated. It does not disclose auth requirements, error behavior, or return shape, but with the read-only annotation covering safety, this is adequate though not rich.

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 no filler. The primary action is stated first, and the important non-pagination note is included without extra verbosity.

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 fully documented parameters and a read-only annotation, the description is nearly complete. The only small gap is that it does not clarify whether an id query returns an object or a list, though the schema's 'empty list' wording hints at the latter.

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%, and the schema already documents the id parameter's behavior ('empty list if it does not exist') and the 'view' parameter's compact/full semantics. The description's mention of a single category when id is given adds little beyond 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?

The description uses a specific verb ('Retrieve') with a clear resource ('all Tempo account categories') and an explicit variant ('or a single category when id is given'). This makes it easy to distinguish from sibling tools like tempo_get_accounts and tempo_get_account even 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 description notes that the endpoint is not paginated, which is useful context for when this tool is appropriate. However, it gives no explicit guidance about when to prefer this tool over sibling tools or any exclusions, so usage guidance is mostly 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?

The annotations already declare readOnlyHint=true, and the description adds the useful scope detail that both open and closed accounts are returned. No behavioral traits like pagination behavior or response envelope are disclosed, but with the read-only annotation covering safety, the description contributes adequate additional context without contradiction.

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 that states the action, resource, and scope with zero redundancy. 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 read-only list tool with a fully documented schema and a read-only annotation, the description is adequate. It clearly communicates the 'all accounts' scope, and while it doesn't explicitly route to alternatives, the sibling list makes that easy to infer. Nothing critical is missing for calling the tool 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 100%: all three parameters (view, limit, offset) have meaningful descriptions, including the compact/full distinction and defaults. The tool description adds no parameter-level information beyond the schema, so the baseline score of 3 is appropriate.

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 uses a specific verb ('Retrieve') and resource ('a list of all Tempo accounts'), and the parenthetical '(OPEN and CLOSED)' clarifies the scope, distinguishing it from a filtered account search. It does not explicitly name sibling tools like tempo_search_accounts or tempo_get_account, 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?

The description implies use when you need the full account list without filtering, and the sibling set contains tempo_search_accounts and tempo_get_account as possible alternatives. However, there is no explicit when-to-use or when-not-to-use guidance, so the usage context is only implied.

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 readOnlyHint annotation already signals a safe read operation, and the description's 'Retrieve' is consistent with that. It adds the scoping cue that the response covers global configuration rather than a project- or user-specific resource, but it does not disclose response format, authentication requirements, or other behavioral traits. With annotations present, this is an adequate but minimal addition.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded sentence with no redundant content. It is appropriately sized for a simple read-only getter, though it omits usage guidance that could have been included without bloating 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 tool with one optional parameter and no output schema, the description is minimal but not misleading. It states the resource and read-only nature, but it does not hint at the shape of the returned configuration or indicate that the view parameter affects the response. The schema fills in parameter details, but the description itself leaves the context sparse.

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 only parameter, 'view', is fully documented in the input schema with detailed semantics about compact/full response shapes and field projection. Schema description coverage is 100%, so the tool description does not need to compensate. The description adds no parameter-specific meaning, leaving the schema to carry the weight.

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 action ('Retrieve') and a specific resource ('global Tempo configuration settings'). No sibling tool targets global configuration, so an agent can distinguish it from the list. However, it does not elaborate on which settings are included, making it slightly vaguer than a fully specified purpose.

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 guidance about when to use this tool versus alternatives. It does not mention that it is the only global-configuration tool, nor does it indicate any conditions, exclusions, or prerequisites. An agent must rely solely on the name to infer usage.

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, and the description's 'Retrieve' aligns with that. The description adds no further behavioral detail such as response shape, pagination, or date-range semantics, but for a simple read-only getter the annotation covers the safety profile.

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?

Single sentence with the verb and resource front-loaded, and no redundant words. The parenthetical earns its place by clarifying the domain.

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, the description plus fully documented schema and readOnlyHint cover the essentials. It could be slightly more explicit about returning a list of periods across the from/to range, but the name and schema make that clear.

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%; both date parameters and the view enum have descriptions. The tool description itself adds no parameter semantics, 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?

The description uses a specific verb ('Retrieve') and resource ('Tempo period definitions'), and the parenthetical 'used for timesheet approval cycles' adds useful domain context. No sibling tool targets periods, so it is readily distinguishable despite being terse.

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 parenthetical gives context (timesheet approval cycles) but does not explicitly state when to prefer this tool over alternatives or when not to use it. There are no direct sibling period tools, but the usage guidance remains implied rather than explicit.

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 readOnlyHint annotation already establishes that this is a safe read operation, so the description's job is lighter. The parenthetical 'resource allocation' adds useful domain context, but the description doesn't disclose behavior such as not-found handling, response shape, or any server-side quirks. This is acceptable but not richly transparent.

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 states exactly what the tool does with no filler. Every element earns its place, and the key constraint ('by id') comes early.

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 get-by-id tool with a read-only annotation and a well-documented view parameter, the description is nearly sufficient. The lack of an output schema is partially mitigated because 'plan' is defined as 'resource allocation', but an agent still has no explicit statement of what the response will contain.

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 both 'id' and 'view' thoroughly. The tool description adds no parameter-level detail beyond what the schema provides, which is fine given the high coverage; this is the baseline case.

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 uses a specific verb, 'Retrieve', names the resource ('a single Tempo plan'), and clarifies that a plan is a resource-allocation object. It clearly distinguishes this tool from list-oriented siblings like tempo_get_plans by emphasizing retrieval by id.

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 makes the usage context clear: use this when you have a plan id and want that single plan. It doesn't explicitly name alternatives or exclusion conditions, but the 'by id' and 'single' wording gives enough context to route an agent away from collection-fetching operations.

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, so the safety profile is covered. The description adds that from/to dates are required, which is a useful constraint, but does not disclose pagination behavior, default view behavior, or potential performance implications of broad queries.

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 states the verb, resource, and a key requirement without any filler. It is efficient and immediately conveys the core purpose.

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 tool with 15 parameters and no output schema, the description is minimal. It covers the essential purpose and required fields but omits guidance on pagination (limit/offset), the meaning of the 'view' parameter (though schema covers it), and typical usage patterns. Given the schema's thoroughness, it's adequate but not comprehensive.

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 all parameters are documented in the schema. The description only adds 'matching the given parameters' and 'requires from and to dates', which restates schema info without adding new semantic value. Baseline 3 is appropriate.

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 tool retrieves a list of Tempo plans (resource allocations) and requires from/to dates. It distinguishes from the singular 'tempo_get_plan' by using 'list' and 'matching parameters', but does not explicitly name alternatives or scope limitations.

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?

It implies usage for fetching multiple plans with filters, but provides no explicit when-to-use vs. alternatives, no exclusions, and no guidance on pagination or view selection. The required dates are stated, but the description lacks a clear 'use this when' 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?

The annotation readOnlyHint=true already declares the operation as read-only, so the description doesn't need to repeat that. The description adds no further behavioral context (e.g., not-found behavior, response shape). Since annotations cover the safety profile, this is a baseline 3; no contradiction 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?

The description is a single, front-loaded sentence containing only essential information. There is no filler or redundancy; it earns its place perfectly for a simple get-by-id 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 single-resource retrieval tool with read-only annotation and fully documented parameters, the description is complete. It covers what the tool does and how to invoke it. The absence of an output schema is acceptable since the tool's return is straightforward and not described elsewhere.

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%, and both parameters ('id' and 'view') are already documented in the schema, including the detailed semantics of the 'view' enum. The description adds no additional parameter meaning, so a baseline 3 is appropriate.

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 a specific verb ('Retrieve'), a resource ('a single Tempo Financial Manager project'), and the key discriminator ('by id'). This distinguishes it from the plural 'tempo_get_projects' sibling without needing to open either schema. The intent 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 word 'single' and the requirement of an 'id', which contrasts with the plural 'tempo_get_projects'. However, the description does not explicitly state 'use this when you have a project ID; use tempo_get_projects to list projects' or mention any alternatives. It's adequate but relies on inference rather than explicit 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 declare readOnlyHint=true, which already covers the safety profile. The description adds the paginated-list behavior and the 'all' scope, but does not disclose additional details like default pagination bounds or response shape. With the annotation present, this level is adequate.

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 filler, front-loading the verb and resource. Everything present is necessary and no redundant detail is included.

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 three well-documented parameters, the description is nearly complete. It communicates the resource (projects), the pagination behavior, and scope, though it does not describe the return payload shape in detail—acceptable given the absence of an output schema and the low complexity.

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 parameters (view, limit, offset) are fully documented in the schema. The description mentions 'paginated list', loosely implying limit/offset, but adds no new semantic meaning beyond the schema's own descriptions. 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?

The description uses a specific verb ('Retrieve') and resource ('paginated list of all Tempo Financial Manager projects'), clearly distinguishing it from siblings like tempo_get_project (singular) and from all worklog/timesheet tools. The plural 'all projects' signals the list scope without ambiguity.

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 when to use the tool: when you need the full project list, as opposed to tempo_get_project for a single project. However, it does not explicitly state exclusions or name the alternative, leaving the choice to the agent's 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?

readOnlyHint already establishes the safe read profile, and 'Retrieve all' adds a scoping fact consistent with that annotation. The description does not mention pagination, response size, or auth, but these are less critical for a low-complexity read endpoint.

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 four-word sentence with no filler; it starts with the action verb and states the resource immediately. Every word earns its place and the size is appropriate for a no-required-arg read.

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 only one optional enum parameter and a schema that already explains response shaping, the short description is nearly sufficient. There is no output schema, so the exact shape of a role is left to the agent, but that is a minor gap for a simple enumeration read.

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 sole parameter view is fully documented in the schema, including compact/full behavior, so schema coverage is 100%. The tool description adds no parameter-level meaning beyond what the schema already provides, matching the baseline.

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 ('Retrieve') and a precise resource/scope ('all Tempo roles'). No sibling tool targets roles, so an agent can distinguish it from the many worklog, team, account, and timesheet tools without opening schemas.

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 intended use is clear when a caller needs the full role collection, and 'all' signals an unfiltered retrieval. It does not explicitly name alternatives or exclusions, but no sibling tool offers role retrieval, so the omission is not costly.

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, covering the safety profile. The description adds no additional behavioral context—no mention of what happens on missing id, error handling, or response shape. For a simple get-by-id tool, this is adequate but not enriching; it does not contradict annotations.

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, direct sentence with no filler. The verb and resource are front-loaded, and every word earns its place. It is appropriately minimal for the tool's simplicity.

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 get-by-id tool with two well-documented parameters and a readOnly annotation, the description is nearly complete. It does not explicitly state the return value (the team object), but that is implicit in the verb 'Retrieve'. The absence of an output schema is not critical here because the tool's purpose is unambiguous.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both id and view fully documented. The description adds no parameter meaning beyond the schema. Baseline of 3 applies because the schema carries the semantic weight.

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 ('Retrieve') and resource ('a single Tempo team') and identifies the primary key ('by id'). It clearly distinguishes from sibling tempo_get_teams (plural, likely a list) through singular/plural usage, so an agent can tell them apart 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 description gives no guidance on when to use this tool vs. alternatives. It does not mention tempo_get_teams for listing, nor any conditions or prerequisites. The context is implied only by the tool name and singular resource, not explicit.

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 readOnlyHint annotation already signals this is a safe read operation. The description adds the crucial scoping constraint (single team) and points to the sibling for broader queries. It does not disclose response format or pagination, but for a simple list operation with annotation coverage, this is adequate.

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 with zero filler. The primary purpose is stated first, followed by the alternative-routing condition. Every word earns its place, and the structure is front-loaded for quick comprehension.

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 two well-documented parameters and an explicit alternative, the description is nearly complete. It lacks explicit mention of return format or pagination, but the absence of an output schema and the simplicity of the operation make this a minor gap. The description fully covers what an agent needs to decide whether to invoke it and how to do so 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 100%, with both parameters already documented in the input schema. The view parameter has a detailed explanation of compact vs full behavior, and teamId is described as 'Tempo team id'. The description adds no parameter information beyond what the schema provides, so a baseline 3 is appropriate.

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 uses a specific verb ('Retrieve'), names the resource ('all memberships for a single Tempo team'), and immediately distinguishes itself from the sibling search tool by scoping to a single team. This leaves no ambiguity about what the tool does or how it differs from tempo_search_team_memberships.

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 when to use this tool (single team) versus when to use the alternative (filter across teams, by account or role) and names the alternative tool. This is a clear routing instruction that helps the agent pick the correct tool without needing to open schemas.

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 annotation already declares readOnlyHint=true, so the agent knows this is a safe read operation. The description adds some context by enumerating supported filters, but it does not disclose pagination behavior, default limits, or response shape beyond what the schema already provides.

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 concise sentences with no filler. The first states the core action and resource, and the second summarizes the filtering capability, making the description easy to scan and act on.

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?

Given the read-only annotation and complete parameter schema, the description plus structured data is sufficient for an agent to select and invoke this tool correctly. It could add response shape or pagination details, but for a straightforward list endpoint this is not a major 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 100%, so the baseline is 3 even though the description adds little parameter detail. The description restates the three primary filters but does not meaningfully enrich the schema's own parameter descriptions.

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 opens with 'Retrieve a list of Tempo teams', giving a specific verb and resource. The plural 'list' clearly separates it from the sibling tempo_get_team, and the filter options (name, member account ids, team ids) further define the tool's scope.

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 clearly indicates this is the tool for listing/filtering Tempo teams, which is enough context for an agent to select it over the singular tempo_get_team. It does not explicitly name alternatives or exclusions, but the plural resource and filter list make the intended use evident.

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 provide readOnlyHint=true, and the description's 'Retrieve' is consistent with that. It adds useful context about the returned aggregation (who submitted, is open, or approved), but does not disclose behavior like pagination, period boundaries, or response shape beyond the schema. No contradiction with annotations.

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 that states the action, scope, and reviewer perspective without filler. The em-dash clause adds meaningful context about what the caller will see.

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 tool with only two required parameters and no output schema, the description communicates the resource, period, and expected approval status categories. It is functional on its own, though explicit guidance about sibling timesheet-approval tools would make it more complete.

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?

All four parameters are fully described in the schema with types, formats, defaults, and an enum for view. The description only refers to 'the given period' generically, so it adds little semantic value beyond the schema, which already carries the burden.

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 names a specific action (Retrieve), resource (every team member's timesheet approval for a period), and perspective (reviewer's view of submitted/open/approved states). This clearly distinguishes the tool from related timesheet tools by scope and viewpoint.

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 the reviewer audience but never states when to use this tool versus alternatives such as tempo_get_timesheet_approvals_waiting or tempo_get_timesheet_approval_status. No explicit conditions or sibling routing are provided.

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 readOnlyHint annotation already establishes that this is a safe read operation, and the description's 'Retrieve' aligns with that. The description adds no additional behavioral context such as response shape, error behavior, or default period handling beyond what the schema already provides. There is no contradiction with annotations, so a mid-range score is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the verb and resource, contains no filler, and conveys the core purpose immediately. It is appropriately sized for the tool's simplicity.

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 status lookup, the description combined with the fully descriptive schema and readOnlyHint annotation covers the essential inputs and safety profile. With no output schema, the description could arguably say more about what the returned status looks like, but the core call requirements are clear and complete.

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 all four parameters (accountId, from, to, view) are documented in the schema, including the default behavior for 'to' and the compact/full distinction for 'view'. The description itself adds no parameter-level meaning beyond the phrase 'in the given period,' which restates what the schema already covers.

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 uses a specific verb and resource: 'Retrieve the current timesheet approval status for a user in the given period.' It clearly identifies what the tool does and the target scope. However, it does not explicitly differentiate this tool from sibling tools like tempo_get_timesheet_approvals_waiting or tempo_get_timesheet_approvals_by_team; the distinction is semantic 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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention sibling tools, exclusions, or conditions under which another timesheet approval tool would be more appropriate. The usage context is only implied by the tool's name and resource.

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 declare readOnlyHint=true, and 'Retrieve' aligns with that. The description adds the 'waiting for approval' status context, but does not disclose additional behavioral details such as scope, pagination, or response format. No contradiction with annotations.

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 states the action, resource, and condition efficiently, and the schema handles the one parameter.

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 tool with one optional enum parameter fully documented in the schema, the description is mostly complete. It could add more specificity about global scope or return shape, but nothing critical is missing for basic selection and invocation.

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%, and the view parameter's description is already detailed in the schema. The tool description adds nothing about parameters, which is acceptable because the schema carries the full burden.

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 uses a specific verb and resource ('retrieve all timesheets') and identifies the result state ('currently waiting for approval'). It is clear, though it does not explicitly differentiate itself from close siblings like tempo_get_timesheet_approvals_by_team or tempo_get_timesheet_approval_status.

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 phrase 'currently waiting for approval' implies when the tool is relevant, but there is no explicit guidance about when to choose it over the many approval-related sibling tools. No alternatives, exclusions, or prerequisites are mentioned.

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, so the safe read-only nature is covered. The description adds the behavioral context that the result is a list of reviewer users and that it feeds downstream approval actions, but it does not disclose response shape, pagination, or error behavior. With the annotation covering the safety profile, a 3 is appropriate.

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 with zero waste. The core purpose is front-loaded, and the usage guidance is packed into the second sentence without 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?

For a simple read-only lookup with one required parameter and full schema coverage, the description is nearly complete. It clearly ties the tool into the approval workflow. The only minor gap is that it doesn't describe the response shape or whether multiple reviewers can be returned, but the output schema is absent and the description's workflow context is sufficient for correct invocation.

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 both parameters. The description adds the semantic context that `accountId` identifies the timesheet owner and that the result supplies `reviewerAccountId`, but it does not add format or syntax details beyond the schema. Baseline 3 is correct when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Retrieve'), a specific resource ('the users who can review a given user's timesheet'), and immediately distinguishes it from sibling approval actions by naming its output as the source for `reviewerAccountId`. This makes the tool's purpose unmistakable and differentiates it from the many timesheet approval 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?

The description explicitly says when to use this tool: to source `reviewerAccountId` for `tempo_submit_timesheet` and the other approval actions. This is direct usage guidance that routes the agent to the correct workflow context and implies it should be called before those actions.

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, so the safety profile is established. The description adds context about the return content ('planned working hours per day') but does not disclose additional behavioral traits such as timezone handling, pagination, or empty-schedule 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, front-loaded sentence that states the core purpose without any filler or redundant restatement. Every word contributes to understanding the 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?

The schema fully documents all parameters and the annotation confirms read-only behavior. The description conveys the primary return concept, though the absence of an output schema means an agent might want more detail about the exact response structure. Overall, this is sufficient for a straightforward schedule lookup 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 100%, so the parameter meanings are fully documented there. The description itself adds no parameter-level detail beyond what the schema already provides, so a baseline score of 3 is appropriate.

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 uses a specific verb ('Retrieve') and identifies the exact resource ('work schedule for a user') along with a concrete detail ('planned working hours per day'). This clearly differentiates it from worklog-related siblings and leaves no ambiguity about the tool's function.

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 guidance on when to use this tool instead of similar alternatives such as tempo_get_worklogs_by_user or timesheet tools. There is no mention of exclusions, prerequisites, or comparative scenarios.

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 declare readOnlyHint=true, and the description's 'Retrieve' is consistent with that. It adds minimal context beyond identifying the resource as work attributes/custom fields; it does not disclose pagination behavior or response shape even though limit/offset parameters exist. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single front-loaded sentence with no filler. The parenthetical adds precise clarifying context without bloating the text.

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?

This is a simple read-only list with no required parameters, so the description is minimally sufficient for a basic call. However, it does not describe return values, pagination semantics, or when to prefer this over related tools, and there is no output schema to fill that 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 schema already documents all three parameters with 100% coverage, including a detailed explanation of the view enum. The description adds no parameter-level meaning, so the baseline 3 is appropriate.

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 uses a specific verb ('Retrieve') and names a concrete resource ('all Tempo work attributes') with a clarifying parenthetical ('custom fields on worklogs'). This distinguishes it from the many worklog/plan/team siblings in the tool family, though it does not explicitly name any alternative tool.

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 guidance on when to use this tool versus alternatives, no exclusions, and no conditions. The only signal is the resource name itself, so an agent must infer when this tool is appropriate rather than being told.

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, so the description does not need to restate safety. It adds a small amount of behavioral context by clarifying this returns a single record rather than a collection, but it does not go further (e.g., error behavior, response format). No contradiction 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 sentence with no filler. The core action, resource, and lookup criterion are front-loaded and 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 read-only lookup tool with 100% schema coverage and a readOnlyHint annotation, the description plus schema is sufficient for correct invocation. The view parameter's detailed response-shape explanation lives in the schema, so nothing critical is missing, though a brief mention of the view option in the description would make it even more self-contained.

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 id and view parameters are already fully documented in the schema. The description adds no parameter detail beyond repeating 'id', which meets the baseline but does not exceed it.

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 uses a specific verb ('Retrieve'), identifies the exact resource ('single Tempo worklog'), and specifies the lookup key ('by its id'). This clearly distinguishes it from the many list-oriented siblings like tempo_get_worklogs and tempo_get_worklogs_by_project.

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 that this tool is appropriate when you already have a worklog id, but it never explicitly states when to prefer this over alternative retrieval tools or enumerates any exclusions. Usage context is present but only by 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?

The readOnlyHint annotation already marks this as a safe read operation, and the description matches that by saying 'Retrieve a list.' It adds minimal behavioral context by naming supported filter dimensions, but it does not disclose behavior such as the default limit, offset behavior, or what happens when all parameters are omitted. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences with the main action front-loaded and no irrelevant content. It is concise, though the second sentence is slightly redundant with 'search parameters' and the phrase 'and more' is vague.

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?

Given the rich input schema and read-only annotation, the description is minimally sufficient for invoking the tool, but it leaves important context gaps. It does not clarify how this generic list tool differs from the many sibling worklog-list tools, nor does it describe expected behavior with no filters, pagination defaults, or response characteristics in the absence of an output 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?

Since schema description coverage is 100%, every parameter already has an explanatory description. The tool description only paraphrases a few parameter concepts (project, issue, date range) without adding new semantic detail, so the baseline score of 3 is appropriate.

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 a specific action ('Retrieve a list') and resource ('Tempo worklogs'), then names the main filtering dimensions. It is not a tautology and does not confuse it with a single-item fetch, but it does not explicitly distinguish it from the many sibling worklog-list tools such as tempo_search_worklogs or tempo_get_worklogs_by_project.

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 phrase 'Supports filtering by project, issue, date range, and more' implies this tool is for flexible multi-dimensional searches, so a capable agent can infer when to use it. However, it gives no explicit when-not guidance or alternatives, even though there are heavily overlapping siblings like get_worklogs_by_project, get_worklogs_by_issue, and search_worklogs.

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 provide readOnlyHint=true, so this is known as a safe read operation. The description adds the account-key association context. It does not describe pagination behavior, default limit implications, or the response shape. The 'view' parameter description is unusually detailed about response shape, which adds some behavioral transparency, but the main description is thin. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The primary description is a single concise sentence, front-loading the core behavior. The schema's 'view' description is lengthy but earns its place with critical disambiguation. No fluff or repetition.

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?

Given 7 parameters, no output schema, but rich schema descriptions, the description is mostly complete. Missing: no explicit statement about defaults (e.g., limit default 50), no guidance on how 'from'/'to' interact with 'updatedFrom', and no mention of what happens if accountKey has no worklogs. But the schema carries much of the weight.

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 100%, so the schema already documents all 7 parameters. However, the description adds value through the 'view' parameter's unusually explicit explanation of what 'compact' vs 'full' mean, and the 'accountKey' example. The main description doesn't add parameter details beyond the schema, but the schema descriptions are rich enough to push this above baseline.

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 ('Retrieve') and resource ('Tempo worklogs associated to a Tempo account key'). It is specific enough to indicate the tool's scope, though it doesn't explicitly contrast with sibling tools like tempo_get_worklogs_by_user or tempo_get_worklogs_by_project. The name alone distinguishes it, and the description confirms the behavior.

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 usage: use this tool when you need worklogs filtered by an account key. It doesn't explicitly mention when to use alternatives (e.g., by user, by issue, by team), but the singular 'associated to a Tempo account key' gives clear context. No exclusions or alternative routing are provided.

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 readOnlyHint annotation already covers that this is a read operation, and the description adds no behavioral context beyond that. It does not mention pagination behavior, default limits, or response characteristics, even though the schema provides limit/offset parameters. Since the annotation covers safety but the description fails to add any additional behavioral transparency, this scores below the baseline.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence with no filler. It is front-loaded with the action and resource, and every word contributes to defining the tool's purpose. This is an appropriate size for a simple retrieval 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?

Given the presence of seven parameters and no output schema, the description should provide more context about how the tool behaves, such as default pagination, time-range semantics, or what 'all' means in relation to the from/to parameters. The schema covers parameters but the description does not explain the tool's overall behavior or how it differs from sibling retrieval tools, making it incomplete for an agent to invoke correctly without external hints.

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 all seven parameters have descriptions in the schema. The description itself does not add meaning beyond what the schema already provides. Baseline 3 is appropriate because the schema does the heavy lifting; the description only restates that worklogs are for a specific issue, which is already implied by the required issueId 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?

The description clearly states the action (retrieve) and the resource (Tempo worklogs for a specific Jira issue). While the resource is specific, it does not differentiate from sibling tools like tempo_get_worklogs_by_project or tempo_get_worklogs_by_user. The name and required issueId parameter clarify the scope, but no explicit differentiation from siblings is given.

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 is provided on when to use this tool versus alternatives such as tempo_get_worklogs, tempo_get_worklogs_by_project, or tempo_search_worklogs. The description does not mention any conditions, prerequisites, or limitations that would help an agent choose this tool over its 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 declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds 'all worklogs' scope but doesn't disclose pagination behavior, default date range, or whether the response is ordered. With annotations covering the safety profile, a 3 is appropriate – the description adds some value but not rich behavioral context.

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 clear sentence that states the verb, resource, and scope with zero waste. It is front-loaded and easy to parse, though it could have added a hint about optional filters without becoming verbose.

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 100% schema coverage, the description is mostly adequate. However, it doesn't mention that 'from'/'to' are optional, what the default time range is, or how pagination works. The output schema is absent, so a brief note on return shape would have helped.

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 all 7 parameters. The description adds no parameter-level meaning beyond what the schema provides. Baseline 3 is correct when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Retrieve') and resource ('all Tempo worklogs for a specific Jira project'), which clearly distinguishes it from sibling tools like tempo_get_worklogs_by_user or tempo_get_worklogs_by_issue. It doesn't explicitly name a sibling alternative, but the resource scope is clear enough to differentiate.

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 usage context: use this when you need worklogs filtered by project. It doesn't explicitly state when not to use it or name alternatives like tempo_search_worklogs for more flexible filtering. The sibling list provides context, but the description itself offers no 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 mark readOnlyHint=true; the description adds no behavioral context such as pagination, date filtering, scope of 'all', or response shape. The word 'all' is ambiguous relative to from/to and limit/offset parameters, and no further disclosure is provided.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence with no filler or redundancy. It is front-loaded but also minimal; it is concise though it could carry more useful detail.

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?

Despite full schema coverage, the tool has 7 parameters including date ranges, pagination, and view shape, and no output schema. The description does not explain what 'all' means, how pagination works, or when to choose this team-specific endpoint over the many worklog siblings. This leaves an agent under-informed for correct invocation.

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 all parameter semantics are carried by the schema; the description adds no extra meaning beyond reaffirming 'team' which maps to teamId. 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?

The description uses a specific verb 'retrieve' and resource 'Tempo worklogs', scoped to 'a specific Tempo team', which distinguishes it from worklog-by-user/project/issue/account siblings. However, it does not explicitly name any sibling or contrast itself, so it is clear but not maximally differentiating.

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 is provided on when to use this tool versus alternatives like tempo_get_worklogs_by_user or tempo_get_worklogs_by_project. The description only states the purpose, leaving the agent to infer the appropriate context without exclusions or alternatives.

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 readOnlyHint annotation already establishes that this is a safe read operation. The description adds only the scope of the results (worklogs for a specific user), but does not clarify how 'all' interacts with the optional date range, limit, or offset, or what the response shape looks like.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused sentence that front-loads the verb and resource. There is no repetition of the name, title, or schema details.

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?

This is a simple read tool with a rich parameter schema and a read-only annotation, so it is minimally callable. However, there is no output schema and the description does not explain pagination behavior, return shape, or how 'all' relates to the limit/offset parameters, leaving some ambiguity for an agent.

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 input schema covers 100% of the parameters with descriptions, so the baseline is 3. The tool description itself adds no parameter-specific meaning beyond what the schema already provides.

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 action ('Retrieve') and resource ('Tempo worklogs') and scopes the result to a specific Atlassian user, which makes it recognizable among the many worklog siblings. It does not explicitly compare against alternatives like by-project or by-issue, but the user dimension is the key differentiator.

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 guidance on when to choose this tool over tempo_get_worklogs_by_project, tempo_get_worklogs_by_issue, or the generic tempo_get_worklogs. It also does not mention whether this is the appropriate tool for filtered or unfiltered user worklog retrieval.

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 mark the tool as read-only and idempotent, and the description adds substantial behavioral detail beyond that: it never returns the credential, it distinguishes 'no credential' from 'credential rejected' from an api.tempo.io-side problem, and it reports round-trip time. This is exactly the kind of context an agent needs.

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 sentences carry exactly the necessary information: what it does, what it reports, and when to call it. It is front-loaded with the core mechanism and contains no filler or repetition beyond the useful read-only credential-safety note.

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 parameterless diagnostic tool, the description covers the operational behavior, security-relevant credential handling, output elements, and invocation conditions. The annotations cover safety and idempotency, so nothing needed for correct use 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?

With zero parameters and 100% schema coverage, there are no parameter semantics for the description to clarify. The description appropriately concentrates on behavior instead, which is the right choice for a parameterless tool.

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 diagnostic action: resolve the credential, make one authenticated request to api.tempo.io, and report which hop failed. This clearly distinguishes tempo_healthcheck from the many sibling data tools by describing a verification/diagnostic purpose rather than a CRUD or query operation.

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 final sentence explicitly instructs when to invoke it: 'Call this when a real tool fails and you want to know which hop broke.' This gives an agent a direct decision rule for choosing this tool over ordinary Tempo operations.

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 destructiveHint=true, so the description adds value by explaining the state change (returning to OPEN) and the mandatory confirmation mechanism (either a prompt or a two-step token fallback). This goes beyond the annotation's simple destructive flag, providing concrete behavioral context. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loading the purpose before the confirmation flow. It is efficient and avoids redundancy, though the confirmation logic is dense and could be slightly restructured for readability. Overall, 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?

The tool lacks an output schema, and the description does not describe what the response will contain after a successful recall (e.g., the recalled timesheet data or a success message). It also does not mention any post-action state beyond returning to OPEN. While the confirmation flow and preconditions are covered, the missing response information leaves an agent uncertain about the tool's return value.

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 100% and each parameter has a detailed description, including the confirmToken's intricate behavior. The tool description itself adds no new parameter-specific meaning beyond what the schema already provides, so the baseline of 3 is appropriate.

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 ('Recall'), a resource ('timesheet'), and a precise condition ('submitted but not yet approved'), along with the expected outcome ('returning to OPEN'). This clearly differentiates it from sibling tools like tempo_approve_timesheet, tempo_reject_timesheet, and tempo_reopen_timesheet, which involve different actions on different states.

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 conveys when to use the tool (for a user's submitted-but-unapproved timesheet needing correction) and details the confirmation flow, including how clients without elicitation should proceed with a preview and confirmToken. It does not explicitly name alternative tools or say 'use this instead of X', but the specific condition inherently guides selection.

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?

Discloses the confirmation prompt, the two-step preview/confirmToken fallback, and references MCP_CONFIRM_MODE. Annotations already declare destructiveHint=true and readOnlyHint=false, so the description adds procedural context about the tool's non-idempotent, token-gated 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 sentences with the main purpose front-loaded and no filler. The confirmation details are dense but necessary; the MCP_CONFIRM_MODE pointer is efficient, though slightly terse.

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 purpose, effect, actor role, comment requirement, and the confirmation/token flow, which is enough for most invocation paths. No output schema exists, so return details are absent, but the tool's behavior is well-enough explained for the agent to act 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 100%, and each parameter already has a thorough description (e.g., confirmToken's usage rules). The main description only restates the confirmToken flow in general terms, adding no new parameter-level meaning beyond what the schema provides.

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 ('Reject'), resource ('user's submitted timesheet'), and time period, while defining the outcome ('sending it back to the user for changes'). This clearly distinguishes it from sibling actions like approve, submit, reopen, and recall.

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 identifies the actor as a 'Reviewer action' and requires a comment explaining why, which sets expectations for when the tool is appropriate. It also explains the confirmation flow, though it doesn't explicitly contrast with approve/reopen/submit alternatives.

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?

Beyond the annotations (readOnlyHint=false, destructiveHint=true), the description discloses that the action undoes an approval, returns the timesheet to OPEN, and requires user confirmation. It also explains the two-step fallback behavior involving a preview and confirmToken, which is critical behavioral context that annotations alone do not provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences long, front-loads the core action and outcome, and then provides essential confirmation-flow detail. Every sentence earns its place, and there is no redundant or filler content.

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 destructive, confirmation-gated tool with no output schema, the description covers the essential behavior, the confirmation mechanism, and the fallback token flow. It could additionally describe the final success response or required permissions, but the reference to 'Reviewer action' and the detailed confirmation instructions make it sufficiently complete for correct invocation.

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 100%, so the baseline is 3, but the description adds meaningful context beyond the schema: it explains that confirmToken is only for the two-step fallback and must never be sent on the first call, and it references tempo_get_periods for finding valid period boundaries. This helps the agent use the parameters correctly without relying solely on 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?

The description names a specific verb ('Reopen'), a specific resource ('a user's already-approved timesheet'), and the resulting state ('returning it to OPEN so worklogs can be edited again'). It also explicitly frames the action as a 'Reviewer action' that 'undoes an approval,' which clearly distinguishes it from siblings like tempo_approve_timesheet, tempo_reject_timesheet, and tempo_submit_timesheet.

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 clearly states this is a reviewer action that undoes an approval, giving the agent the key condition for when to invoke it. It also provides explicit guidance on the confirmation flow, including the two-step fallback with confirmToken and the instruction to call again with the same arguments. It does not explicitly name alternative tools or state when not to use it, but the reviewer/undo framing makes the usage context clear.

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 provide readOnlyHint=true, so the safety profile is already known. The description adds meaningful behavioral context: the 'view' parameter behavior is explained in detail (compact strips image/avatar URLs, full returns payload untouched, no field projection). This goes beyond the schema enum and explains why there is no field projection, which is valuable for an agent deciding how to invoke the tool.

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 purpose and a practical routing hint. The second sentence earns its place by pointing to the sibling tool that needs the resolved id. No wasted words.

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 search tool with 100% schema coverage and no output schema, the description is nearly complete. It explains the key cross-tool dependency (resolving keys to ids for tempo_get_account) and the view behavior. It does not describe pagination defaults beyond what the schema says (limit default 50, offset), but the schema already covers that. The only minor gap is not explicitly stating that results are a list, but that is implied by 'Search' and the filter parameters.

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 all 7 parameters. The description adds the key insight that this tool resolves account keys to numeric ids, which is not in the schema. However, it does not add much beyond that for the individual parameters, so the baseline 3 is appropriate.

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 ('Search') and resource ('Tempo accounts'), and enumerates the filter dimensions (id, key, status, global flag). It also distinguishes itself from tempo_get_account by explicitly noting this is how you resolve an account key to the numeric id that tempo_get_account needs. This clearly differentiates it from the sibling tempo_get_accounts and tempo_get_account.

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 a clear use case: resolving an account key to a numeric id for tempo_get_account. It implies this is the search/filter tool among the account siblings, but it does not explicitly state when to prefer tempo_get_accounts over this tool or vice versa. The context is clear enough for an agent to select it for search/filter scenarios, but explicit exclusions are absent.

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 readOnlyHint annotation already covers safety, and the description adds the behavioral trait that inactive memberships are included, which is valuable and not in annotations. However, it does not disclose other behaviors such as response shape, pagination, or how filters combine. Given annotations carry the safety burden, this is a moderate addition, but not rich enough for a higher score.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded with the action and resource, containing two short sentences with no redundancy. It could have included usage guidance without losing brevity, but as written it is tightly structured and efficient, earning a high score for conciseness.

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?

Given the tool's moderate complexity (six optional parameters, no output schema) and the presence of annotations for safety, the description covers the core operation and notes inactive membership inclusion. However, it lacks guidance on how it differs from the closely related sibling 'tempo_get_team_memberships', which is a significant contextual gap. The schema handles parameter details well, but the description could be more complete by addressing the sibling relationship.

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?

All six parameters have descriptions in the schema (100% coverage), and the description adds no parameter-specific meaning beyond what is already in the schema. For instance, it mentions 'across teams, accounts, and roles' which maps to teamIds, accountIds, and roleIds, but these are already explained as filters. The description provides no additional semantic value, so the baseline of 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?

The description clearly states the action (search) and resource (team memberships) and indicates scope across teams, accounts, and roles. However, it does not explicitly contrast with the sibling 'tempo_get_team_memberships', which also retrieves memberships, leaving some ambiguity about the distinction between search and get. The verb 'search' implies filtering, but a clear differentiation would strengthen the purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus the very similar sibling 'tempo_get_team_memberships' or other search tools like 'tempo_search_accounts'. The description does not state conditions like 'use this for multi-criteria filtering' or 'use get for a single membership'. This omission is notable given the direct sibling overlap, leaving the agent to infer usage from the name alone.

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, and the description is consistent with that. It adds valuable context beyond the annotation: permission requirements, a PII warning (account ids, reviewer actions), and the pagination behavior via nextPageToken. This gives an agent meaningful operational expectations that structured fields alone would not.

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 with zero waste: purpose first, then safety/permission caveats, then pagination mechanics. Each sentence carries distinct, necessary information and nothing is repeated from 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 an optional-parameter search tool with no output schema, the description covers the key operational concerns: permission prerequisites, PII sensitivity, and pagination. The view parameter's schema text fills in response-shape details. It stops short of describing the returned log entry fields or any sort ordering, but the essentials an agent needs before invoking are present.

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 all five parameters, including a rich explanation of the view enum and date formatting for updatedFrom. The description adds only the pagination behavior already reflected in nextPageToken's schema text, so it stays at the baseline rather than adding new parameter-level 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?

The description opens with a specific verb+resource ('Search timesheet approval audit logs'), and the word 'audit logs' clearly separates this tool from the approval-lifecycle siblings such as tempo_get_timesheet_approval_status, tempo_get_timesheet_approvals_waiting, and tempo_approve_timesheet. An agent can distinguish the historical audit-trail intent from current-status or mutation tools 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?

The 'audit logs' framing implies this is for historical investigation rather than checking current approval state, but no alternative sibling is named and no when-to-use vs. when-not-to-use condition is stated. The PII and permission warnings hint at appropriate contexts, but the agent must infer the routing versus the many approval-status 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=true, so the description need not restate safety. It adds the behavioral detail that the tool uses a POST body, which is useful because it signals an unusual HTTP method for a read-only operation. It does not describe return behavior, but that is partially covered by the schema's view parameter.

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 focused sentences: the first states the action and key filters, the second names the precise alternatives for unsupported filter types. 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?

The description is adequate for a search tool with fully documented parameters and read-only annotations. It could be more complete by also referencing simpler worklog siblings like tempo_get_worklogs_by_project or tempo_get_worklogs_by_user, but the core usage and routing guidance are sufficient.

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 baseline is 3. The description adds no parameter-specific meaning beyond naming author ids, issue ids, project ids, and date range, all of which are already documented in 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?

The description clearly identifies the tool as a worklog search with advanced filters across author, issue, project, and date range. It distinguishes itself from the team- and account-filtered siblings, though it does not explicitly contrast with the simpler by_user/by_issue/by_project list 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?

The description explicitly directs team- or Tempo-account-filter needs to tempo_get_worklogs_by_team and tempo_get_worklogs_by_account. It does not state when to prefer this over related worklog-getting tools, but the 'advanced filters' framing provides a reasonable implied use 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 state destructiveHint=true, so the description doesn't need to repeat that. The description adds critical behavioral details: confirmation prompt behavior, the two-step fallback with confirmToken, and that the token must be from phase-1 and not invented. This goes beyond annotations and helps the agent understand the non-trivial side effects of invoking this tool. However, it doesn't describe what happens if the user confirms (e.g., irreversible submission) beyond the state change, which is partially covered by the description.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: the first states the core action and state transition; the second explains the confirmation mechanism. It is front-loaded with the main purpose and then procedural detail. No filler words, but the second sentence is somewhat long and could be split for readability. Overall, efficient and 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?

Given the tool's complexity (confirmation flow, multiple modes), the description covers the essential behavioral aspects: confirmation prompt, MCP_CONFIRM_MODE, and the token-based fallback. It doesn't explicitly state the return format (but no output schema is present), and it assumes the agent understands the domain (e.g., 'OPEN' state). The description is sufficient for an agent to call it correctly, especially with schema covering parameter details.

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 schema descriptions cover 100% of parameters, explaining formats and defaults (e.g., 'to' defaults to period containing 'from', 'from' references tempo_get_periods). The description adds value primarily for confirmToken by explaining its purpose and usage constraints, which the schema already touches on ('ONLY for the two-step confirmation fallback...'). Since schema coverage is high, the description doesn't need to repeat parameter details; it does add some clarity on confirmToken's usage flow.

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 ('Submit a user's timesheet for the given period for approval'), the resource (timesheet), and the state transition (OPEN to WAITING_FOR_APPROVAL). This is distinct from sibling tools like tempo_approve_timesheet, tempo_reject_timesheet, and tempo_recall_timesheet, so an agent can differentiate it without ambiguity.

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 explains the confirmation flow, mentioning MCP_CONFIRM_MODE and the two-step fallback, which tells the agent when to use it. It doesn't explicitly list when not to use it compared to alternatives, but the state transition (from OPEN) implies submission is for timesheets not yet in approval, and the mention of reviewer account hints at the approval workflow. Minor gap: no direct reference to 'use tempo_approve_timesheet instead' for already-submitted timesheets.

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 description goes far beyond the sparse annotations (destructiveHint=true) by disclosing the read-modify-write behavior, the merge of omitted fields, the refusal if the resource changes between preview and confirm, and the two-phase confirmation mechanism. This is exactly the behavioral depth an agent needs to avoid destructive mistakes.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense but every sentence earns its place. It front-loads the core purpose, then explains the essential merge semantics and confirmation mechanics in a logical order. There is zero redundancy, and despite its length, it remains tightly scoped.

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?

Given the complexity of an update tool with conditional confirmation and potential data loss, the description covers all operational essentials: what fields to provide, how merging works, what triggers a refusal, and how the two-step fallback works. No output schema exists, but the description explains the response phases sufficiently. Nothing an agent needs to call this safely 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?

While the schema covers 100% of parameters with descriptions, the tool description adds critical global semantics: the merge behavior for omitted fields and the precise role of confirmToken (never on first call, never invented). This is indispensable meaning that the schema alone does not convey.

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 opens with 'Update an existing Tempo account by its key,' which is a specific verb (update), a clear resource (Tempo account), and the identifying key. This unambiguously distinguishes it from sibling tools like tempo_create_account, tempo_delete_account, and tempo_get_account, so an agent can immediately recognize its purpose.

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?

It explicitly instructs to 'Supply only the fields to change' and explains the critical merge behavior, including the underlying reason (Tempo's PUT replaces the whole resource). It also details the confirmation flow and the two-step token fallback, leaving no ambiguity about when and how to invoke the tool correctly.

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?

This is a strong disclosure of non-obvious behavior beyond the destructiveHint annotation. It explains that despite Tempo's PUT replacing the entire resource, the tool performs a read-merge-write, that a preview shows the full merged body, that concurrent modifications cause refusal rather than overwrite, and that confirmation can take two forms depending on client capability. These are exactly the behavioral traits an agent cannot infer from the schema or annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every sentence carries essential operational information. The most important guidance — update by id, supply only changed fields — is front-loaded, and the confirmation/token complexities are explained in a logical sequence. There is no filler or repetition of schema details.

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 16-parameter mutation with no output schema, the description covers what matters most: partial-update semantics, preview behavior, conflict refusal, and the full confirmation protocol including the fallback token path. An agent has enough information to call the tool correctly and handle both the elicitation-supported and fallback confirmation modes. The absence of an output schema is mitigated by the detailed description of what the preview and confirmation responses contain.

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 100%, so the schema already documents every parameter. The description adds meaningful parameter-level semantics on top: omitting a field preserves its current value, only changed fields should be supplied, and confirmToken has strict lifecycle rules including 'same arguments' on the repeat call. This goes beyond the baseline expected when the schema already covers 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?

The description opens with a specific verb and resource: 'Update an existing Tempo plan (resource allocation) by id.' It clearly distinguishes this from sibling create/delete/get plan tools by emphasizing that only changed fields are supplied and that the resource must already exist. The target object (Tempo plan) and the operation (in-place update with merge semantics) are 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?

The description explicitly tells the agent when and how to use the tool: only for updating existing plans, supply only changed fields, expect a confirmation flow, and in the fallback path require a confirmToken from a prior preview only after explicit user approval. It also warns the caller against inventing, reusing, or sending confirmToken on the first call, and notes when it is ignored. This provides clear context for using the tool and the two-step flow, though it does not spell out trivial exclusions like 'use create_plan for new plans' — the 'existing plan' wording makes that implicit.

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 description thoroughly discloses the read-merge behavior, why the tool reads before updating, the concurrency refusal when the resource changes, and the confirmation/token flow. This goes far beyond the annotations' destructiveHint and readOnlyHint, and no contradiction 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?

The description is dense and front-loaded with the core action, but it is fairly long. Each clause earns its place by explaining a necessary behavioral subtlety, though the run-on chain could be slightly tightened.

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 a complex confirmation flow, the description is complete: it covers partial update semantics, preview behavior, confirmToken usage, concurrency protection, and client-mode fallback. An agent has enough context to call the tool 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 100%, so the schema already documents every parameter. The description adds useful behavioral context about omission/merge, but it does not add per-parameter semantics beyond what the schema already states, including for confirmToken.

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 opens with a specific verb and resource: 'Update an existing Tempo team by id.' It cleanly distinguishes this from sibling tools like tempo_create_team, tempo_delete_team, and tempo_update_account by naming the exact operation and target.

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?

It gives clear operational guidance: supply only changed fields, omitted fields keep current values, and confirmation is required. It does not explicitly name alternatives or exclusion conditions, but the context makes when to use this tool obvious.

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 mark destructiveHint, and the description adds substantial context: a preliminary read occurs, the preview shows the merged body, concurrent changes are refused, and a confirmation prompt or confirmToken flow is required. No contradiction with annotations.

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 dense sentences, front-loaded with the core operation. The later sentences earn their place by explaining merge behavior, concurrency protection, and the confirmation flow, 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 10-parameter destructive mutation with no output schema, the description covers the confirmation flow, concurrency guard, and merge behavior. It does not fully specify the response format, but the preview/confirmToken mechanism is described enough for an agent to invoke the tool 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?

The input schema already documents all 10 parameters (100% coverage), so the baseline is 3. The description adds the crucial global merge semantics—omitted fields keep current values because Tempo's PUT replaces the whole resource—which meaningfully changes how every parameter should be used.

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 (existing Tempo worklog by id), making it unambiguous versus create/delete/get/search siblings. The first sentence alone is enough for an agent to select this tool correctly.

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 explicit usage guidance: supply only changed fields, omitted fields keep current values, and warns about Tempo's PUT-replace semantics. It does not explicitly name alternatives or when-not-to-use conditions, but the update-by-id framing plus merge instructions provide clear context.

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