Timix.AI

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

No annotations provided, so the description carries full burden. It discloses the state transition, the confirm flag behavior (preview vs action), and role restrictions. Lacks mention of idempotency_key behavior, but that is covered in the schema. Overall good transparency for a mutation 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: first states purpose and effect, second provides usage and role guidance. No wasted words, information is front-loaded and easy to parse.

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, usage, roles, and behavioral effect. For a simple approval tool with three parameters and no output schema, this is sufficient. Could mention what happens after approval (e.g., notification), but not essential.

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 parameters are already described. The description adds context that confirm must be true to perform the action, and reinforces the role requirement, adding value 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 'Approve' and resource 'submitted timesheet period', clearly stating the effect 'transition to Approved'. This distinguishes it from siblings like reject_timesheet or 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?

Explicitly mentions when to use (on submitted periods), the required roles (Manager/Admin/Owner, excludes Finance), and that confirm=true is needed to proceed. Does not explicitly mention alternatives or when not to use, but the context is 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?

No annotations provided. Description adds constraints (cannot assign Owner) and idempotency key mention, but does not detail side effects (e.g., whether it replaces or adds assignments) or error conditions.

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; front-loaded purpose then requirements/constraints. No redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers purpose, parameters, and constraints well. Lacks details on return value and behavior on duplicate assignment, but sufficient for selection.

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 covers all 3 params (100%). Description adds value by clarifying org_user_id is not Firebase user ID and provides discovery methods, plus warns not to pass org ID.

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?

Clear verb+resource: 'Assign an organization member to a billing customer'. Distinguishes from sibling 'assign_user_to_project' and 'remove_user_from_customer'.

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 prerequisites (org_user_id, customer_id), how to discover them, and constraint 'You cannot target a user more privileged than yourself'.

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?

With no annotations, the description carries full burden. It discloses that the member will gain visibility and ability to log time, and explains idempotency key behavior. However, it does not specify whether reassignment overwrites existing assignments or what permissions are required.

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, each adding distinct information: action/effect, identification guidance, and organizational context. No unnecessary words, efficiently front-loaded with 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?

Given 4 parameters, no annotations, and no output schema, the description covers most needed context: effect, identification, idempotency, and fixed organization. It lacks details on re-assignment behavior or error scenarios, but overall complete for a mutation 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 coverage is 100%, so each parameter has a schema description. The tool description adds value by stating that email is preferred, explaining the purpose of the assignment, and clarifying the idempotency key's retry behavior. This goes beyond the schema's 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 clearly states the action ('Assign a member to a project') and the effect ('so they can see it and log time against its tasks'). It distinguishes from siblings like 'remove_user_project' and 'assign_user_to_customer' by specifying the resource and 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?

Provides explicit guidance on how to identify the member (email preferred, org_user_id alternative) and the project (project_id, with reference to 'find_billing_work' for ID discovery). Also warns against asking the user for IDs. However, it does not explicitly mention when not to use the tool or compare with 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?

With no annotations, the description adequately discloses key behaviors: entries attributed to user, partial failure handling (returns per-item results), and a maximum batch size of 50. However, it omits mentioning idempotency_key behavior, which is defined in the schema but not in 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 concise at 4 sentences, with the main action ('Create multiple time entries in one call') front-loaded. Every sentence adds necessary information 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?

Given the tool's complexity (nested array, partial failures, defaults), the description covers essential aspects. It lacks explicit return format details but mentions per-item results, which suffices without an output schema. Minor gap: no mention of idempotency_key effect on retries.

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 baseline is 3. The description adds significant value beyond schema: explains start_time default (09:00), hours range (>0 and ≤24), ownership attribution, partial failure reporting, and batch limit. This exceeds the schema's minimal 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 clearly states the verb ('Create'), resource ('multiple time entries'), and mechanism ('in one call' with an 'entries' array). It distinguishes from single-creation tools like create_time_report by emphasizing bulk 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 description specifies when to use this tool (batch creation) but does not explicitly mention when not to use it or suggest alternatives like create_time_report for single entries. The context is clear but lacks exclusionary 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?

Discloses that rate values are never echoed back, which is critical for an agent expecting a response. Also notes the effective date and organization-wide effect. However, with no annotations, it misses details like idempotency behavior (key present in schema) and authorization requirements, leaving some gaps.

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, no wasted words. Front-loaded with purpose and constraint. Each segment 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?

Covers purpose, key constraints, and behavioral nuance (no echo). Without output schema or annotations, the description is adequate for a mutation tool with 4 parameters. Lacks detailed error behavior or response format, but the core usage is well explained.

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 covers 100% of parameters, providing baseline 3. Description adds value by explaining the mutual exclusivity of adjustment_percentage and fixed_amount, giving examples (e.g., 5 for +5%), and clarifying the organization context (never pass an ID). This goes beyond the schema's property 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?

Clear verb ('Apply') and resource ('organization-wide adjustment to every member's hourly COST rate'). Specifies scope (organization-wide, effective from a date) and distinguishes from granular tools like set_user_cost_rate.

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: for organization-wide adjustments. Provides constraints: supply one of adjustment_percentage or fixed_amount, not both, and never pass an organization id. Does not explicitly name alternatives for individual rate changes, but sibling tool set_user_cost_rate implies the contrast.

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?

With no annotations, the description discloses key behaviors: batch nature, max 100 entries, returns per-id results, and partial failures reported. It does not detail idempotency (though idempotency_key param exists) or permissions, but covers the core 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?

The description is two sentences, front-loads the purpose, and contains no extraneous information. Every sentence adds value.

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 3-param tool with no output schema, the description sufficiently covers the operation, constraints, and failure behavior. Missing details like authorization or exact output format, but adequate for selection and basic 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 baseline 3. The description repeats 'ids' and 'text' with constraints (max 100, max 1000 chars) already in schema, adding no new meaning. The optional 'idempotency_key' is not mentioned. No additional value beyond 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 states the action ('Apply a common text description update') and the resource ('multiple of your own time entries'). It implicitly distinguishes from the sibling 'update_time_report' by emphasizing 'multiple' and 'own time entries', and mentions 'bulk' in the name.

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 indicates when to use the tool (updating many time entries with the same description). It does not explicitly exclude alternatives or mention when not to use, but the bulk vs single distinction is implicit given the sibling 'update_time_report'.

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 cancellation effect and preview mode, but lacks details on permissions, reversibility, or notification. Without annotations, the description carries full burden and omits these behavioral aspects.

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 waste; front-loaded with the core purpose. 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?

Covers main action but does not specify the return format of the preview or error conditions. With no output schema, the description should at least hint what the preview returns.

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

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

Schema coverage is 100%, baseline 3. Description adds value by explaining the preview behavior tied to the confirm parameter, which goes beyond schema 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?

Clearly states the action (cancel) and resource (pending invitation), and distinguishes from siblings like invite_user and resend_invite by specifying the effect (link no longer valid) and the ability to re-invite.

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?

Provides context on when to use (cancel pending invitation) and preview behavior (omit confirm for preview). No explicit exclusion or comparison to alternatives, but the preview guidance is helpful.

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?

With no annotations, the description carries full burden. It clearly discloses that the action is permanent deletion and requires confirmation. This is transparent about destructive behavior, though it doesn't detail side effects like cascading deletes.

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 no filler. It conveys essential information efficiently.

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 deletion tool, the description covers key aspects (purpose, requirement). It lacks mention of idempotency or preview behavior when confirm is false, but overall it is sufficiently complete given the tool's 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?

The input schema covers all parameters with 100% description coverage. The description adds minimal value beyond the schema, only reiterating the confirm requirement. 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 the action ('Permanently delete'), the resource ('scheduled report definition'), and a key requirement ('confirm=true'). This distinguishes it from sibling tools like create_scheduled_report and update_scheduled_report.

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 mentions the confirm requirement but does not explicitly state when to use this tool versus alternatives (e.g., temporarily disabling a report). Usage context is implied but not elaborated.

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?

No annotations are provided, so the description carries the burden. It discloses that elapsed time is lost, which is a key behavioral effect. However, it does not discuss idempotency or other edge cases, leaving some gaps for a mutation 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 short sentences convey purpose, effect, and argument expectations with zero waste. 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 tool with one optional parameter and no output schema, the description is complete. It covers the action, result, and argument expectations, requiring no further explanation.

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% for the single optional parameter, and the description adds 'No arguments needed' to clarify that no input is required. This reinforces the schema but does not add new semantic details beyond the parameter's description.

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 cancels or discards a running timer without creating a time entry. It distinguishes itself from similar tools like stop_timer by noting that elapsed time is lost, but does not explicitly name 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 implies when to use (when you want to discard time), but provides no explicit guidance on when not to use or alternatives. It does not mention any prerequisites or contraindications.

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?

Without annotations, the description discloses key behaviors: preview returns a token, requires confirm_token and idempotency_key for commit, token expiration (~10 minutes), and role escalation limits. Does not cover failure modes or reversibility, but sufficient for most use cases.

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?

Extremely concise: three sentences covering purpose, process, and constraints. No filler, front-loaded with key action. Every sentence adds value.

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 4 parameters and no output schema, the description covers the complete workflow including preview and commit. Could mention the return value structure (what preview returns beyond token) but overall adequate for correct tool 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%, baseline 3. Description adds meaning beyond schema: explains that org_user_id is not Firebase userId, confirm_token is obtained from preview, idempotency_key prevents duplicate actions, and new_role lists allowed values. Enhances schema documentation.

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?

Description clearly states it changes an organization member's role, outlines the two-step preview-commit process, and specifies constraints (cannot assign Owner, cannot escalate beyond own role). This distinguishes it from sibling tools like assign_user_to_customer or invite_user.

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?

Provides clear when-to-use context and explicitly states restrictions (cannot assign Owner, cannot escalate beyond own role). Does not compare with alternative tools, but the two-step commit process is well-explained.

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?

Since no annotations are provided, the description carries full burden. It discloses that the tool returns a boolean and a message, suggesting a read-only check. However, it does not explicitly state that the tool has no side effects, does not modify data, or require specific permissions. More behavioral clarity would be beneficial.

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 core purpose, and contains no unnecessary information. Every word contributes to clarity, making it highly efficient.

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 simplicity (2 params, no output schema, no annotations), the description adequately covers the tool's purpose, usage scenario, and return value. It is mostly complete, though it could mention that it is a safe, read-only operation. The lack of output schema means the description compensates sufficiently.

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 parameters have descriptions). The description adds marginal context by framing the hours as 'additional' within the logging scenario, but this builds on what the schema already provides. Baseline 3 is appropriate as the description does not significantly enhance parameter understanding.

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 ('Check'), the resource ('subtask budget limits'), and the specific scenario ('logging additional hours'). It effectively distinguishes this tool from siblings like 'get_budget_alerts' or 'get_budget_health' by focusing on a pre-logging check for a specific subtask.

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 before logging additional hours to verify budget limits, but it does not explicitly state when to use this tool versus alternatives (e.g., 'get_budget_health', 'set_budget_thresholds'). No 'when not to use' or alternative recommendations are provided, making the guidance 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?

Without annotations, the description discloses preview behavior, the confirm parameter's role, and that closing is not reversible. It stops short of detailing the preview's contents or idempotency behavior, maintaining a high but not complete transparency.

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, no filler. Every sentence adds information essential to understanding the tool's behavior.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, yet the description does not explain what the preview contains. Idempotency_key behavior is mentioned only in the schema, not in the description. Given the tool's complexity and missing output documentation, the description is somewhat incomplete.

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

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

The input schema covers 100% of parameters with descriptions. The description adds no new parameter-level meaning beyond what the schema provides; it only contextualizes the confirm parameter in the workflow. 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 ('Close') and the resource ('Open frame order'), and specifies the effect ('so no new invoices may link to it'). It distinguishes from sibling tools like delete_frame_order and update_frame_order.

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 a two-step workflow (preview then confirm) and warns about irreversibility, but does not explicitly state when to use this tool versus alternatives like delete_frame_order or update_frame_order. No '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?

Discloses the preview-commit flow, token expiration (~10 min from schema), idempotency key behavior, and reversibility. Without annotations, description carries burden well, though impact on invoicing/budgets is not mentioned.

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: purpose then workflow. Every sentence adds value, no fluff. Front-loaded with main verb.

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?

Describes core action and reversibility. Lacks return value or error detail, but for a commit tool it is sufficiently complete. Sibling 'reopen_month' provides related context.

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 covers all parameters (100% coverage). Description adds context: explains how confirm_token and idempotency_key are used in the workflow, enhancing meaning beyond schema alone.

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's purpose: 'Close a billing month so no further time can be logged or edited in it.' It also distinguishes itself from the sibling 'reopen_month' by noting reversibility.

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?

Provides clear two-step process: call without token to preview, then with confirm_token and idempotency_key to commit. Mentions reversibility only by reopening, but does not explicitly list scenarios where alternatives should be used.

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 that the tool creates work hierarchy (customers, projects, tasks, subtasks), which is a write operation. No annotations provided, so the description must carry this burden. It mentions idempotency, indicating safe retry. Does not mention potential side effects like overwriting, but the core behavior is clear.

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 wasted words. The first sentence states purpose and effect; the second gives a crucial usage hint. Well-structured and 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?

No output schema exists, yet the description does not mention what the tool returns (e.g., success status or created objects). For a tool that creates multiple entities, this missing detail reduces completeness. Adequate for the low complexity but could be better.

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% (both parameters have descriptions). The description adds no extra meaning beyond the schema: it reiterates the prerequisite for csv_content but provides no new details about syntax or format. 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 action ('Commit a bulk-import CSV') and the resource ('creating the work hierarchy'). It distinguishes from sibling 'validate_import' by implying a two-step process, with this tool performing the actual commit after validation.

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 instructs users to call 'validate_import first to verify the file', providing clear usage order. Does not elaborate on when not to use, but the guidance is sufficient given the sibling 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?

Discloses that entries are created as Draft and explains the weekday offset preservation. No annotations exist, so description fully carries behavioral disclosure. Mentions the 31-day constraint.

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 that effectively front-load purpose, then provide constraints and parameter format. 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?

Adequately describes the operation, constraints, and parameter usage. Lacks return value details, but acceptable for a copy tool without output schema. Meets completeness needs given 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 coverage is 100%. Description adds meaning by stating ISO 8601 format, mapping of source_start_date to target_start_date, and idempotency_key optionality. Exceeds baseline of 3.

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

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

Clearly states the tool copies time entries from a source to target date range while preserving weekday offset, using specific verbs and resources. Distinguishes from sibling tools like log_time or create_time_report.

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?

Specifies it copies 'your own time entries' and imposes a 31-day source range limit. Provides clear context for use, though lacks explicit when-not-to-use or alternative tool references.

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?

No annotations are provided, so the description must fully disclose behavioral traits. It mentions a role requirement but omits important details such as the idempotency key behavior, the preview mode via the 'confirm' parameter, potential side effects on invoice status, and any rate limits or audit logging. The preview behavior is only documented in the schema, not 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 extremely concise—one sentence plus a role requirement. Every word is meaningful 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?

Given the tool's complexity (5 parameters, required preview behavior, idempotency, no output schema, no annotations), the description is insufficient. It fails to explain the preview mode, idempotency key behavior, effect on invoice status, or what the tool returns. A more complete description would cover these aspects.

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 parameters. The description adds minimal extra meaning beyond stating the overall purpose (reducing amount owed). It does not clarify parameter usage or constraints 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?

The description clearly states the action ('Create a credit note'), the resource ('existing invoice'), and the effect ('reducing the amount owed'). It also mentions a role requirement, distinguishing it from sibling tools like issue_invoice or void_invoice.

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 specifies a prerequisite ('Requires Finance role or above') but does not provide explicit guidance on when to use this tool versus other invoice-modifying tools, nor does it mention conditions 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?

No annotations are provided, so the description carries the full burden. It states 'Create' (mutation) but does not disclose idempotency behavior (the schema includes an idempotency_key), success/failure conditions, or return value. The organization constraint is useful, but overall behavioral details are lacking.

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

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

Two short sentences, front-loaded with purpose. No redundant information. Every sentence is meaningful and earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so the description should ideally explain what is returned (e.g., created customer ID). It does not. Parameter count is moderate (6) and schema covers them, but behavioral details (errors, idempotency) are missing. Adequate but not 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 coverage is 100%, so baseline is 3. The description adds valuable semantic information beyond the schema: it clarifies that the organization ID is not to be passed (it's fixed by context). This compensates for the lack of parameter-specific details in the description.

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 verb 'Create', resource 'billing customer', and scope 'in your organization'. It distinguishes from siblings like 'update_customer' and 'delete_customer' by specifying creation. The constraint about not passing an organization ID adds specificity.

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 tells the agent when to use this tool (to create a new billing customer) and explicitly warns against passing an organization ID because it's context-fixed. While it doesn't list alternatives, the purpose and sibling list imply when not to use it (e.g., for updates use 'update_customer').

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?

Without annotations, the description covers behavioral traits like fixed organization, type constraints, and mandatory blocking. However, it omits idempotency behavior and does not mention error conditions or authorization requirements.

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

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

The description is concise (3 sentences), front-loaded with purpose, and contains no redundant or unnecessary information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (7 parameters, no output schema, no annotations), the description covers purpose, scope, key constraints, and behavioral impacts. However, it does not mention the return value or idempotency key behavior, which would improve completeness.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds value by clarifying the organization context, ListOfValues constraint, and mandatory field effect, but the schema already covers parameter details adequately.

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's purpose: defining a new custom field on a billing entity type. It includes specific verbs (Define), resource (custom field), and scope (billing entity types), and implicitly distinguishes from siblings like delete_custom_field and update_custom_field.

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 contextual guidance: organization is fixed (never pass ID), type constraints, ListOfValues requirements, and mandatory field effects. However, it does not explicitly compare to alternatives or state when to use this tool over others.

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?

With no annotations, the description carries full responsibility for behavioral transparency. It states that the tool saves a favorite and returns it, but it does not mention idempotency (despite an idempotency_key parameter), authentication requirements, or any side effects beyond the creation. This is insufficient for an agent to understand the tool's behavior fully.

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 extremely concise: two sentences that convey the core purpose and return value. There is no extraneous information, and every word serves a 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?

Given the tool has 7 parameters, complete schema coverage, no output schema, and no annotations, the description is minimally adequate. It explains what the tool does and what it returns, but lacks context about prerequisites, duplicate handling, or error conditions. For a creation tool, this is acceptable 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?

Since the input schema covers 100% of parameters with descriptions, the baseline is 3. The description adds no extra semantics beyond noting that it's a 'time-entry combination', which vaguely ties to the required entity IDs. It does not elucidate parameter relationships or constraints.

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 ('Save a time-entry combination as a favorite') and the resource ('favorite'). It also mentions the return value, which helps distinguish from sibling tools like delete_favorite, list_favorites, and use_favorite.

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. There are no usage scenarios or conditions mentioned, and no references to related tools (e.g., list_favorites or use_favorite) to help an agent decide which tool to invoke.

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?

With no annotations, the description bears the full burden. It discloses that the frame order is reversible (can be deleted while Open), but does not cover other behavioral details such as permissions, rate limits, or the exact state transition upon creation. The idempotency key behavior is in the schema, not 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 three sentences, conveying the core purpose, functionality, and a key behavioral note in a front-loaded manner. It is concise without wasted words, though the phrase 'blanket PO / commercial envelope' adds slight 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?

Given the complexity (10 parameters, no output schema), the description provides basic context but lacks details about the expected output (e.g., does it return the created frame order ID?), the required parameters (customer_id and reference are not emphasized), and the lifecycle beyond the Open state.

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. The description mentions 'contracted hours or amount cap' relating to total_hours and total_amount but adds no additional meaning beyond the schema. It does not explain reference uniqueness or idempotency key beyond what is already in the 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 clearly states 'Create a new Open frame order' and explains what a frame order is (blanket PO/commercial envelope) and its function (tracks contracted hours/amount cap). It effectively distinguishes the tool from siblings like update_frame_order and delete_frame_order.

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 mentions reversibility (can delete while Open) but does not explicitly state when to use this tool versus alternatives like update_frame_order or close_frame_order. No direct guidance on prerequisites or when not to use it is 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?

No annotations provided, but description discloses write behavior ('SAVE'), constraints on date sourcing, and holiday structure. Lacks details on return value or error conditions, but provides meaningful behavioral context beyond the schema.

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

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

Two concise sentences with all key information front-loaded. Every sentence adds value; no redundancy or fluff.

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, usage, parameter constraints, and source requirements. Missing return value info, but given no output schema and moderate complexity (7 params), the description is mostly complete for agent 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% with detailed descriptions. Description reinforces the structure of the 'holidays' parameter and the source constraint but doesn't add significant new meaning; baseline 3 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?

Description uses clear verb 'Create and SAVE' and specifies resource 'national-holiday profile for the organization for a specific year'. It distinguishes from sibling 'suggest_holiday_profile' by emphasizing this is the final save step after user confirmation.

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?

Explicit guidance: 'Only call this once the user has confirmed; do not call it to preview.' Also states holidays must come from suggest_holiday_profile or user, never invent. Clearly differentiates when to use this vs suggest_holiday_profile.

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?

No annotations provided, so the description carries full burden. It discloses the default behavior of create_general_activity and the idempotency_key, but does not mention permissions, side effects, or possible errors. Adequate 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?

Two sentences that cover purpose and usage guidelines without any redundant words. Highly efficient and 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?

Missing output format description and error handling details. For a creation tool, expected return value (e.g., created project object) is not mentioned, but the description covers core functionality adequately given schema 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?

Schema covers 100% of parameters (baseline 3). Description adds value by explaining the organization context, how to obtain ids (find_billing_work), and the behavior of create_general_activity beyond the schema's brief description.

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 explicitly states the action (Create), the resource (a new billing project), and the context (under one of your customers). It distinguishes from sibling tools like update_project and delete_project by specifying 'billing project' and the customer relationship.

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?

Provides clear guidance: customer_id must be in the organization, discover ids with find_billing_work, never ask the user for an id. While it doesn't explicitly list when not to use, the context is sufficient for correct 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?

With no annotations, the description must disclose behavioral traits. It mentions automated generation and emailing, but fails to note important aspects like idempotency behavior (only hinted via schema), error handling for invalid recipients, or return values. This leaves gaps for the agent.

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 extremely concise with two sentences, no redundant words, and the main action is front-loaded. Every part contributes to understanding the tool's 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?

Given moderate complexity (6 params, no output schema, no annotations), the description is adequate but incomplete. It lacks details on success/failure outcomes, idempotency semantics, and email behavior. For a tool with many siblings, more context would help.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds little beyond schema (e.g., 'on the configured cadence' but cadence is already described). It does not explain parameter interactions or constraints, so it stays at 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 clearly states the tool creates a new scheduled report definition and explains its purpose (generation and emailing on a cadence). It distinguishes from sibling tools like cancel_scheduled_report, update_scheduled_report, and list_scheduled_reports.

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 (e.g., when to update vs create) or any prerequisites. It lacks context for choosing among scheduled report 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?

No annotations provided, so description carries the burden. Describes that subtasks inherit billing type and that all time entries are logged against them. Does not cover permissions, idempotency behavior beyond schema, or error conditions. Adequate but not comprehensive.

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

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

Three short sentences, front-loaded with the main action. Every sentence adds value: purpose, contextual importance, and usage tip. No redundancy or fluff.

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 no output schema, return value is not explained, but typical for creation tools. Provides sufficient context for using the tool in context of sibling tools and overall workflow. Could mention common errors or prerequisites, but 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 coverage is 100% (all params described). Description adds value beyond schema by explaining that task_id should be obtained via find_billing_work and that subtask inherits billing type. This provides important context for correct parameter usage.

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

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

Clearly states 'Create a subtask under a task', specifies the resource and action. Distinguishes from siblings like update_subtask, delete_subtask. Explains the importance (time entries are logged against subtasks) and inheritance of billing 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?

Explicitly instructs to discover IDs with find_billing_work and never ask the user. Implies when to use (creating subtask, every task needs one). Does not give explicit when-not-to-use, but context is clear enough.

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?

No annotations provided, so description must cover behavioral traits. It explains inheritance of billing types and default activity creation. Missing details on mutation nature, permissions, or side effects, but covers key behaviors.

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, no fluff. Front-loaded with core function, then explanatory context, then actionable guidance. 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?

Covers parameter purpose and some behavioral context, but lacks response format or error conditions. For a create operation with no output schema, more details on return value would improve completeness.

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

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

Schema description coverage is 100% so baseline is 3. Description adds context about task purpose and ID discovery but does not significantly enhance meaning beyond schema 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?

Clearly states 'Create a task under a project' and explains tasks group subtasks. Does not explicitly differentiate from sibling tools like create_subtask, but the context of creating tasks vs subtasks is implied.

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?

Provides a specific guideline: 'Discover ids with find_billing_work - never ask the user for an id.' However, it does not discuss when to use this tool over alternatives or mention prerequisites.

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?

With no annotations provided, the description carries full burden. It covers key behavioral aspects: user attribution, default start_time, and required parameters. However, it does not explain idempotency behavior (though schema does), side effects, error handling, or response format, leaving some gaps.

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: purpose, attribution limitation, and key params with defaults. It is front-loaded with the action and contains no extraneous words, efficiently conveying essential information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 6-parameter create tool with no output schema and no annotations, the description is largely complete: it covers scope, user limitation, and key inputs. However, it does not specify what the response looks like (e.g., created object or success flag) and omits potential error conditions, leaving minor gaps.

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

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

Schema description coverage is 100%, providing baseline 3. The description adds minimal value beyond the schema: it reiterates the default for start_time and summarizes key params. It does not introduce new semantic meaning or clarify how parameters interact beyond what schema already 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 explicitly states the tool creates a time entry on a subtask for the current user. It uses a specific verb 'create' and resource 'time entry on a subtask', clearly distinguishing from sibling tools like bulk_create_time_reports or log_time by specifying scope and user attribution.

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 that entries are always attributed to the current user and cannot be created for others, providing a clear when-not-to-use condition. It implies usage for logging personal time on a subtask but does not explicitly mention alternative tools like log_time or bulk_create_time_reports, which could help further.

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 fully discloses the permanent and irreversible nature ('Permanently revoke', 'cannot be restored'), immediate loss of access, the two-step preview-and-commit process, expiration of the confirm_token (~10 minutes), and idempotency behavior. No annotations are provided, so the description carries the full burden and does so effectively.

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 concise sentences. The first states the action and consequences. The second explains the two-step process. Every sentence adds necessary information with no redundancy or 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?

Given the tool has 3 parameters and no output schema, the description covers the key workflow and consequences. It could optionally mention what the preview returns (e.g., the confirm_token and a preview of the key being deleted), but it is largely complete for effective use.

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 has 100% coverage, describing each parameter. The description adds significant value by explaining the two-step workflow: first call without confirm_token to get a preview, then commit with confirm_token and idempotency_key. It clarifies the purpose of the idempotency_key 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?

The description clearly states the tool's purpose: 'Permanently revoke one of your Integration API keys.' It uses a specific verb ('revoke') and identifies the resource ('Integration API keys'). It distinguishes itself from sibling delete tools by being specific to API keys and describing the two-step process.

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 want to permanently revoke an API key) and describes the two-step process. However, it does not explicitly state when not to use it or mention alternatives, but given the specialized nature, the guidance is adequate.

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?

No annotations are provided, so the description carries full burden. It discloses soft-delete, recycle bin, admin restore capability, and the preview/confirm mechanism. It does not mention permission requirements or idempotency behavior beyond schema.

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

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

Two sentences, no filler. The most critical information (action, hierarchy scope, confirm workflow) 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?

Given no output schema, the description adequately hints at a preview return. Sibling tools include many deletions, so the hierarchy soft-delete context is sufficiently distinguishing. Could mention admin requirement explicitly.

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 parameters are described in the schema (100% coverage). The description adds context by explaining that confirm toggles preview vs action and that idempotency_key prevents duplicates, which goes 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 clearly states the action ('Soft-delete'), the resource ('billing customer'), and the scope ('whole hierarchy including projects, tasks, subtasks'). It distinguishes itself from permanent deletion tools by specifying the recycle bin 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 explains the preview-then-confirm workflow, which guides usage. However, it does not explicitly mention prerequisites (e.g., admin role) or contrast with sibling tools like permanent_delete_entity or delete_project.

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?

With no annotations, the description fully discloses behavioral traits: destructive action, preview mode, rejection condition, and admin requirement. It does not detail idempotency key behavior, but that is in the schema.

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

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

Three concise sentences without fluff. Each sentence adds value: what it does, when it fails, and usage nuances. Perfectly 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?

Given three parameters, no output schema, and high schema coverage, the description covers key behavioral aspects (preview, rejection, admin role). It is sufficient for an agent to understand when and how to invoke.

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% with clear parameter descriptions. The tool description adds context about confirm's effect (preview vs actual delete), but does not substantially enhance understanding 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 clearly states the action: 'Delete a custom-field definition from the organization.' It uses a specific verb and resource, and distinguishes itself from sibling tools like create_custom_field and update_custom_field.

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 when deletion may be rejected (mandatory fields with stored values) and requires admin role. It also notes the preview behavior without confirm=true. However, it does not explicitly contrast with alternatives like update_custom_field or set_custom_field_value.

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

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

With no annotations provided, the description fully carries the burden. It discloses permanent deletion, the restriction to drafts, and the safe preview mode when confirm=true is not set. No contradictions.

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, no filler. The most critical information (delete, permanent, draft-only, preview) is front-loaded. Every sentence adds essential context.

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 no output schema, the description adequately explains the behavior (preview vs. deletion) and constraints. It is complete for an agent to understand when and how to invoke this 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 coverage is 100% with clear descriptions for each parameter. The description adds minimal value beyond the schema, only restating the confirm parameter's effect. 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 verb 'Delete', the resource 'DRAFT invoice', and the constraint 'Only draft invoices can be deleted; issued invoices are permanent records.' It effectively distinguishes from sibling tools like update_draft_invoice, issue_invoice, mark_invoice_paid, etc.

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 specifies that the tool should be used only for draft invoices and warns that issued invoices cannot be deleted. It also describes the preview behavior (confirm=true for actual deletion), guiding the agent on when to proceed vs. preview.

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?

With no annotations provided, the description bears full responsibility for behavioral disclosure. It mentions deletion but lacks details on whether it is irreversible, what the preview mode entails, or what happens after successful deletion. The description is too minimal for a destructive action.

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 with two sentences and no unnecessary words. However, it is somewhat under-specified given the tool's destructive nature; a bit more behavioral context would not harm 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 has 3 parameters and no output schema or annotations, the description should provide more context about return behavior, the preview mode, and the idempotency key. It fails to adequately prepare an AI agent 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%, establishing a baseline of 3, but the description adds no new semantic value beyond what the schema provides. The only addition is echoing the requirement for confirm=true, which is already clear in the parameter description.

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 'Delete' and the resource 'saved time-entry favorite', making the tool's purpose unambiguous. It effectively distinguishes from sibling tools like create_favorite and list_favorites.

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 specifies that 'confirm=true' is required to proceed, providing a clear usage condition. However, it does not provide guidance on when to use this tool versus alternatives, nor does it mention when not to use 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?

No annotations provided, so description carries full burden. It discloses soft-delete (restorable), blocked conditions, and preview behavior, giving a complete behavioral picture.

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: first states core action, second adds important caveats. No wasted words, information is front-loaded and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, but the description covers the essential context: action type (soft-delete), effect (recycle bin), prerequisites (no linked invoices), and confirm behavior. This is complete for a delete 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 coverage is 100% with descriptions for all parameters. The description reaffirms the confirm parameter's behavior but adds no new meaning beyond the schema, meeting 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?

The description states it soft-deletes an Open frame order into the recycle bin, which is a specific verb+resource. It distinguishes from siblings like permanent_delete_entity by specifying soft-delete and restorable by Admin.

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?

Provides explicit guidance: blocked when linked to Issued/Sent/Paid invoices, recommends voiding or unlinking first. Also describes preview vs confirm behavior, helping the agent decide when to use confirm=true.

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?

With no annotations, the description fully discloses behavioral traits: the preview-by-default behavior (returns a preview unless confirm=true), the admin role requirement, and the effect on time calculations. This goes beyond the structured schema and is highly 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?

The description is extremely concise with two sentences that front-load the action and key behaviors. Every sentence earns its place with no redundant or irrelevant 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 deletion tool with high schema coverage, the description is fairly complete—covering purpose, effect, admin requirement, and preview behavior. It could mention the return type or side effects more explicitly, but it is sufficient for most agents.

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 baseline is 3. The description adds some value by restating the confirm behavior and mentioning the admin role (which is not a parameter), but it does not significantly enhance understanding 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 verb 'Delete', the resource 'named national-holiday profile', and the organization scope. It distinguishes from sibling tools like create_holiday_profile or update_holiday_profile by explicitly mentioning deletion and its effect on time calculations.

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 to use the tool (to delete a holiday profile) and mentions the preview vs confirm behavior. However, it does not explicitly state when not to use it or suggest alternatives like update_holiday_profile for modifications, leaving some ambiguity.

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?

No annotations are provided, so the description fully carries the burden. It discloses key behaviors: members locked out, org hidden, retention window, preview-commit workflow, role requirement. This is comprehensive for a mutation 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 that pack all essential information: action, effect, usage flow, prerequisites. No filler words, front-loaded with the most critical point (soft-delete). 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?

Given the tool's complexity (two-step delete) and lack of output schema, the description covers preview and commit phases, token expiration, idempotency, role requirement, and consequences. Complete for an agent to use 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?

Despite 100% schema coverage, the description adds crucial context beyond schema: explaining the preview/commit flow, that confirm_token comes from first call and expires in ~10 minutes, and idempotency_key ensures safe retries. This adds significant semantic value.

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

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

The description clearly states 'soft-delete this organization', specifying the exact verb and resource. It distinguishes from sibling tools like permanent_delete_entity and other delete operations by highlighting the soft-delete nature.

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?

Explicit step-by-step instructions: preview with no token, then commit with confirm_token and idempotency_key. Also warns that owner role is required and that the organization is hidden until admin restore, which tells when to use this tool versus 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 description explicitly states 'soft-delete', recycle bin placement, admin restore capability, and preview behavior. It does not cover permissions or detailed side effects, but with no annotations, it provides good transparency.

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 consists of two concise sentences with no redundant information. The key action is front-loaded, and the preview behavior is explained immediately.

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?

Without an output schema, the description explains the return behavior (preview vs action). It covers the core functionality and distinguishes from sibling tools. Minor gaps: preview format not detailed, but acceptable.

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%, but the description adds useful context: the 'confirm' parameter controls preview vs action, and the 'idempotency_key' parameter is explained. It clarifies the effect of each parameter 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 clearly states the verb (soft-delete) and the resource (billing project and its task/subtask hierarchy). It distinguishes from siblings like permanent_delete_entity and restore_entity by specifying recycle bin and admin restore.

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 soft-delete behavior and the preview mechanism with confirm=true. It implicitly guides when to use this tool over permanent deletion, but lacks explicit when-not or alternative references.

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?

With no annotations provided, the description carries full burden. It discloses that deletion is soft and restorable, and that confirm=true is required for actual deletion. However, it omits potential prerequisites (e.g., admin role) or rate limits, keeping it slightly incomplete for full transparency.

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 pack essential information without redundancy. It front-loads the soft-delete concept and quickly addresses the preview/confirm distinction. Every sentence contributes meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the main behavior and parameter role, but lacks details on return value format (preview structure) and assumes understanding of 'recycle bin'. Given no output schema, a bit more context on what the preview contains would improve completeness.

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

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

Schema covers all 3 parameters (100% coverage). The description adds value by explaining the confirm parameter's role in preview vs action, which enhances understanding beyond the schema's boolean description. The idempotency_key is standard, and subtask_id is self-explanatory.

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 (soft-delete), the resource (billing subtask), and the effect (into recycle bin, restorable by admin). It also distinguishes the preview vs confirm behavior, making it specific and unambiguous among sibling delete 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 explains the soft-delete and preview behavior but does not explicitly guide when to use this tool over alternatives like permanent_delete_entity. The context of when-not-to-use or comparison to siblings is missing, though the behavior is 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 description transparently discloses that deletion is soft and reversible via admin, the preview mechanism without confirm=true, and hints at idempotency behavior. With no annotations, it carries the full burden well.

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 redundant information. The most critical information (soft-delete, hierarchy, preview, confirm) is front-loaded and concise.

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 no annotations and no output schema, the description covers behavior, parameters, and post-deletion state (recycle bin). Missing details about return preview specifics but is otherwise 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 coverage is 100%, so baseline is 3. The description adds value by explaining the effect of the 'confirm' parameter (preview vs. actual deletion) beyond the schema's description.

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 ('soft-delete') and identifies the resource ('billing task and its subtask hierarchy'), clearly differentiating it from siblings like 'permanent_delete_entity' and 'delete_subtask'.

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 for reversible deletion and mentions the preview mode, but does not explicitly contrast with 'permanent_delete_entity' or 'update_task' for status changes, nor state when to use this versus alternative deletion methods.

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?

No annotations are provided, so the description carries the full burden. It discloses the destructive nature, preview behavior, and permission rules. It adds context beyond schema about the two-step delete process.

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 efficient sentences ordered logically: purpose, permissions, preview/action. No fluff; every sentence adds essential info.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, so description should hint at preview response or soft-delete behavior. It omits whether deletion is permanent or goes to recycle bin, and what the preview returns. Adequate for basic use but incomplete for edge cases.

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%. The description restates the confirm behavior already documented in the schema but adds no new semantic meaning for time_report_id or idempotency_key. 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 'delete a time report entry' with a specific verb and resource. It also adds permission context (self vs. managers/admins) which helps distinguish from other delete 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?

Provides clear when-to-use: to delete a time report. It explains the preview pattern (call without confirm first) and permission constraints. However, it doesn't explicitly contrast with update_time_report or other 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?

With no annotations, the description effectively conveys the destructive nature of deletion, the fallback behavior for assigned users, the preview-by-default pattern, and the admin role requirement. Minor omission: no mention of irreversibility.

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 concise sentences that are front-loaded with the primary action. Every sentence adds value with no redundancy or fluff.

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 primary return behavior (preview vs confirm), required role, and consequence of deletion. No output schema exists, but the description addresses the main return pattern. Lacks details about the preview structure, but overall completes the tool's context.

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 baseline is 3. The description adds no additional meaning to individual parameters beyond what the schema already provides, but it does contextualize the overall tool behavior.

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 'Delete' and identifies the resource as 'named organization work schedule profile'. It clearly states what the tool does and distinguishes it from siblings like 'set_org_work_schedule' by focusing on deletion.

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 mentions that admin role is required and explains the preview-and-confirm mechanism. It does not provide explicit alternatives or when-not-to-use scenarios, but the context is clear enough for correct invocation.

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?

With no annotations, the description only partially discloses behavior: it states the effect (cannot sign in) and the preview vs. action flow. Missing details on side effects like session termination or data access.

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—first states purpose, second adds key details (reversibility, preview). No wasted words; effectively 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?

Covers core behavior and preview mechanism, but lacks return value details, error conditions, or post-action state. Given no output schema, the description is only moderately 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 coverage is 100%, but the description adds value by explaining the confirm parameter's preview role and idempotency_key's retry behavior, going beyond schema 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 uses a specific verb ('disable') and resource ('organization member'), clearly stating the tool's purpose. It distinguishes itself from sibling tools like 'enable_user' and 'remove_user' by noting reversibility.

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?

Provides context on when to use (to disable a user) and mentions the reversible nature and preview mechanism. Lacks explicit exclusions or alternatives but sufficiently guides 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?

In the absence of annotations, the description discloses key behaviors: the operation is a re-enable, requires the specific user ID, has a privilege restriction, and mentions idempotency via the optional key. It does not detail side effects or failure modes, but covers essential traits.

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

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

Three short sentences front-load the purpose, then immediately list requirements and constraints. No redundant information. Every sentence adds value.

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 has only 2 parameters, no output schema, and no nested objects, the description adequately covers purpose, requirements, constraints, and idempotency. However, it does not explain what happens if the user is already enabled or what the return value looks like (though output schema is absent).

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%, but the description adds meaning beyond the schema: it clarifies that org_user_id is required and explains the idempotency key behavior ('retrying with the same key returns the original result'), which is not fully captured in the schema description.

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 ('Re-enable'), the resource ('previously disabled organization member'), and the outcome ('so they can log in and use the platform again'). It distinguishes itself from sibling tool 'disable_user' by explicitly mentioning re-enabling.

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?

Provides explicit requirements ('Requires the org_user_id') and constraints ('organization is fixed by your context—never pass an organization id', 'You cannot target a user more privileged than yourself'). While it doesn't name alternative tools, the context implies not to use if user is not disabled or if lacking privilege.

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?

With no annotations, the description carries the full burden. It discloses that the tool 'Returns ids and names only,' which is valuable. It does not explicitly state it's read-only, but the context strongly implies it. No mention of rate limits or authentication, but that's acceptable for a simple search 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?

The description is two sentences, highly concise, and front-loaded with the core action. Every sentence adds value with no redundancy or fluff.

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 low complexity (3 optional params, no output schema, no nested objects), the description is sufficient. It explains the purpose, filtering, and return content. It could mention pagination or error cases but is complete enough for the use case.

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 has 100% coverage with detailed descriptions for all three parameters. The description adds little extra: it mentions optional name filtering (already in schema) and implies drilling into projects (project_id). Baseline 3 is appropriate given high schema coverage.

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's purpose: finding projects, tasks, and subtasks for time tracking. It specifies the verb 'Find', the resource (projects/tasks/subtasks), and the scope (where time can be tracked). It distinguishes from siblings like 'list_projects' by focusing on billable work items.

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 guidance: 'Use this to locate where to record work.' It implies the tool is for identifying work items before logging time. However, it does not explicitly mention when not to use it or suggest alternative 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?

With no annotations provided, the description discloses that the invoice is a draft (editable, deletable) but does not mention side effects like failure if no approved hours or idempotency behavior. Some transparency but gaps remain.

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 main purpose, and no unnecessary words. It efficiently conveys the core functionality and the draft nature.

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 8 parameters and no output schema, the description does not explain the return value or prerequisites (e.g., approved hours must exist). It lacks details needed for an agent to fully understand the tool's inputs and outputs.

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 parameters. The description does not add additional meaning beyond providing high-level context (e.g., 'billing period'). 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 the tool generates a draft invoice from approved billable hours over a billing period. It distinguishes it from sibling tools like 'issue_invoice' and 'create_credit_note' by emphasizing the draft state.

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 for draft creation but does not explicitly state when to use this tool versus alternatives like 'issue_invoice' or 'create_credit_note'. No guidance on prerequisites or when not to use 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?

With no annotations, the description carries the full burden of behavioral disclosure. It only states 'get billing summary' without mentioning read-only nature, required permissions, data scope, or any side effects. The agent cannot infer important traits like whether the call is safe or destructive.

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, which is concise but lacks structure. It misses the opportunity to front-load the most critical information and does not justify its brevity with completeness.

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 three required parameters and absence of output schema, the description is incomplete. It does not explain what a 'billing summary' contains, how results are formatted, or any constraints like date range limits, leaving the agent underinformed.

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 input schema fully describes each parameter. The description adds no additional meaning beyond that, earning the baseline score of 3.

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 the tool gets a billing summary for a customer over a date range, which is clear but generic. It does not distinguish 'billing summary' from sibling tools like get_budget_health, get_unbilled_time, or get_invoice, leaving ambiguity about what this specific report contains.

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. With many billing-related siblings, the absence of usage context or explicit exclusions makes it difficult for an agent to select the correct 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?

No annotations are provided, and the description does not disclose behavioral traits such as required permissions, data freshness, or whether alerts are organization-wide. For a read operation, it could mention lack of user-specific filtering or output format details.

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, well-structured sentence that front-loads the core purpose. Every word contributes meaning 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?

Given the simplicity of the tool (no parameters, no output schema), the description covers the basic action and result. However, it could elaborate on what the alerts contain (e.g., project names, budget amounts) to improve completeness.

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

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

The tool has zero parameters, so the baseline score is 4. The description adds no parameter information, which is acceptable since there are no parameters to describe.

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 specifies the verb 'Get', the resource 'budget alerts', and the scope 'for the organization showing projects that are over or near budget'. It effectively distinguishes from sibling tools like 'check_budget_limits' and 'get_budget_health'.

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 implicitly indicates when to use the tool: to retrieve alerts about over or near budget projects. It does not explicitly state when not to use or suggest alternatives, but the purpose is clear enough to guide selection among 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?

No annotations provided; description clearly indicates a read-only operation returning summary data. It could be more explicit about safety, but the nature is evident.

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, concise, front-loads purpose, 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?

No output schema, but description sufficiently explains return content (counts, hours, alerts). Low complexity, no missing 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?

No parameters in schema (empty object), schema coverage 100%, baseline 4 is appropriate. Description adds no parameter detail but none needed.

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 specific verbs (Get) and resources (overall budget health summary) and clearly distinguishes from sibling tools like get_budget_alerts by mentioning project counts by status and remaining hours.

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 for retrieving budget health overview but does not explicitly state when not to use it or suggest alternatives among 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?

With no annotations provided, the description carries full burden. It reveals required authorization but gives no indication of read-only nature, output format, or pagination. This is insufficient for full behavioral transparency.

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 cover purpose and authorization with no unnecessary words 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 tool is simple with one parameter, but the description omits expected output details (e.g., list of cost-rate entries). Given no output schema, more context on return shape would improve completeness.

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

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

The description directly mirrors the schema's parameter description for 'user_id' and adds no additional context. Since schema coverage is 100%, 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 uses a specific verb ('Get') and resource ('cost-rate history'), and specifies it is for a specific user. This clearly distinguishes it from sibling tools like 'set_user_cost_rate' or 'bulk_update_cost_rates'.

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 states a required role ('Finance role or higher'), but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions.

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

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

No annotations provided; description does not disclose behavioral traits like read-only nature, auth requirements, or side effects.

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

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

Single concise sentence with no fluff.

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?

Adequate for a simple retrieval tool with one parameter and no output schema; specifies returned data but lacks behavioral context.

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% for the single parameter; description adds no additional meaning 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 clearly states the tool retrieves detailed customer info including health score and portfolio, distinguishing it from sibling tools like create_customer, update_customer, and list_customers.

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 guidance on when to use this tool versus alternatives; intended use is implied by name and description but lacks explicit when-not-to-use 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?

No annotations are provided, so the description carries full burden. It only states it 'gets' metrics, with no mention of side effects, authentication needs, rate limits, or read-only nature. The description is too minimal for behavioral disclosure.

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 (12 words) with examples, no wasted words. Slightly improved conciseness but lacks structure for complex tools.

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 tool with one optional parameter and no output schema, the description covers the basic purpose. However, it does not describe return format, pagination, or scope limitations, which would be helpful for dashboard metrics.

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% with one optional parameter 'month' already well-described in the schema (format and default). The description adds no additional meaning beyond the schema, so 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 verb 'Get' and the resource 'organization dashboard metrics' with examples (utilization, revenue, active projects). It distinguishes from many sibling tools that are CRUD or specific operations, though it does not explicitly differentiate from other 'get' 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?

No guidance on when to use this tool versus alternatives like get_billing_report or get_hours_summary. No when-not-to-use or exclusion criteria 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?

No annotations provided, so description carries full burden. It discloses read behavior (returns report) and lookup flexibility, but does not mention permissions, caching, or error conditions. Adequate but not comprehensive for a tool with zero annotation coverage.

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, front-loaded with purpose, no wasted words. Effectively conveys core functionality in minimal space.

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 3 simple params and no output schema, description adequately explains return fields (target, actual, variance) and lookup behavior. Slightly lacking on error cases or date range limitations, but sufficient for typical use.

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 3 params described). Description adds context for employee_name (defaults to self, 'me' accepted), but adds minimal value beyond schema for start_date and end_date. Baseline 3 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?

Clear verb 'get' with specific resource 'employee timesheet report' and explicit output fields (target hours, actual hours, variance). Distinguishes from siblings like get_my_time_entries by offering lookup by employee name or defaulting to requesting user.

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?

Description implies use for obtaining timesheet reports with variance, and notes optional employee name, but does not explicitly state when to use instead of related tools like get_my_time_entries or get_hours_summary. Lacks when-not-to-use guidance 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?

No annotations are present, so the description must convey behavioral traits. It indicates a read-only report, which is clear from the word 'Report', but does not disclose other traits like permissions, data scope (all frame orders?), or whether it is safe or destructive. The description is minimally 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?

The description is a single sentence that front-loads the purpose and lists key metrics. It is concise with minimal redundancy, though slightly long for a one-sentence structure.

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 no output schema, the description covers the essential return information (metrics for hours and amount, utilization percentage) and optional filters. It lacks details on sorting, pagination, or default scope, but is adequate for a simple report tool.

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

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

Schema description coverage is 100% with adequate descriptions for both parameters (status, customer_id). The description only reiterates that filtering is optional, adding no new meaning beyond the schema. 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 clearly states the tool reports frame order utilization metrics (contracted cap, billed draw-down, remaining, utilization percentage) for both hours and amount, with optional filters. This is specific and distinguishes it from sibling tools like get_resource_utilization which likely focus on resources rather than frame orders.

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 mentions optional filters by customer and status, implying when to use it for filtered reports, but does not explicitly state when to use this tool versus alternatives or when not to use it. No guidance on prerequisites or exclusions is 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?

No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, authentication requirements, rate limits, or error handling. As an aggregation tool, the description should at minimum indicate that it aggregates existing data without modifications.

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 is concise and front-loaded. It contains no redundant information and efficiently communicates the tool's core function.

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 having no output schema, the description does not hint at the structure or contents of the returned summary (e.g., total hours, breakdown by day or user). This gap forces the agent to infer return format from the tool name, which may lead to incorrect assumptions.

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 input schema already describes all parameters fully. The description adds no new meaning beyond what is in the schema (e.g., 'for a user or team' is already captured by the 'scope' parameter description). 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?

Description clearly states verb (Get), resource (summary of hours logged), and scope (user or team over a date range). However, it does not distinguish this tool from siblings like get_my_time_entries, get_employee_timesheet, or get_resource_utilization, which could overlap in 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 implies usage for summarizing hours but does not explicitly state when to use this tool over alternatives. No guidance on prerequisites or exclusions is provided, leaving the agent to infer context from the tool name alone.

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

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

No annotations provided, but the description is straightforward and implies a safe read operation. Does not conceal any behavioral traits; however, it could mention whether the template is static or dynamic.

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 wasted words. Front-loaded with purpose, then provides usage advice.

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?

Completely describes the tool's purpose and how to use it in the broader workflow. No output schema needed; description suffices for a parameterless retrieval 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?

No parameters exist, so schema coverage is 100%. Description adds no parameter info beyond schema; baseline according to rule is 4.

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 it returns a CSV template for bulk-importing the work hierarchy, specifying verb 'return' and resource 'CSV template' with details on hierarchy levels (customers, projects, tasks, subtasks). It distinguishes from siblings like validate_import and commit_import.

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?

Provides explicit workflow: get template, fill it, then call validate_import before commit_import. Guides the agent on the correct sequence of tool calls.

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?

No annotations are provided, so the description must convey behavioral traits. It states the action is a read ('Get'), implying no side effects. However, it does not disclose authorization requirements, rate limits, or what constitutes 'full details'. This is adequate but minimal.

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 of 10 words, front-loading the purpose. Every word is necessary and there is no superfluous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (1 param, no output schema), the description is adequate but could be improved by specifying what fields are returned. It mentions 'full details' but that is vague. With no output schema, a bit more detail on return value would enhance completeness.

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

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

The schema covers 100% of parameters (just invoice_id) with a description. The tool description adds 'full details' but does not provide additional semantic meaning beyond the schema. Baseline for high schema coverage is 3.

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 the full details of a specific invoice by ID. It uses a specific verb ('Get') and resource ('invoice'), and the 'by ID' distinguishes it from list_invoices (which retrieves multiple).

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 for retrieving a single invoice by ID, contrasting with list_invoices for listing. However, it does not explicitly state when not to use it or mention any prerequisites 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?

No annotations are provided, so the description must carry the behavioral disclosure burden. It describes the return data structure but does not explicitly confirm read-only behavior, authentication requirements, rate limits, or handle edge cases (e.g., no data in date range). It is adequate but not thorough.

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, well-structured sentence that efficiently conveys the tool's purpose and output. No unnecessary 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?

Given no output schema and no annotations, the description covers the core purpose and return details adequately. It could mention that results are scoped to the current user (implied by name) or any pagination, but it is largely complete for a straightforward analytics 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 coverage is 100%, and both parameters have clear schema descriptions (ISO 8601 format). The tool description adds no additional semantic meaning beyond repeating 'date range', so it meets the baseline but does not enhance parameter understanding.

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 time entry analytics for the current user over a date range, listing specific breakdowns (project, customer, billable, target comparison). This differentiates it from siblings like get_hours_summary or get_dashboard_metrics.

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 for personal analytics, but does not explicitly state when to use versus alternatives like get_hours_summary or get_billing_report, nor does it provide exclusions or prerequisites.

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?

No annotations provided, so the description must convey behavioral traits. It states 'Get detailed project status', implying a read-only operation, but does not explicitly confirm idempotency, safety, authorization requirements, or any side effects. The description is minimally 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?

The description is a single sentence that is front-loaded and concise. Every word adds value 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?

Given the single parameter and no output schema, the description adequately explains the nature of the response. It mentions key components (budget, hours, task breakdown). However, given the number of sibling tools, additional context on what distinguishes this status from other reports would improve completeness.

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

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

Schema coverage is 100% with a clear parameter description for 'project_id'. The description adds context about what the response includes (budget, hours, task breakdown), but does not add meaning specific to the parameter itself. With high schema coverage, a score of 3 is baseline and adequate.

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 detailed project status covering budget, hours, and task breakdown. The verb 'Get' and resource 'project status' are specific. While it doesn't explicitly differentiate from siblings like 'get_hours_summary', the combined scope provides implicit differentiation.

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

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

No guidance on when to use this tool versus alternatives such as 'get_hours_summary' or 'get_budget_health'. The description lacks any when-to-use, when-not-to-use, or prerequisite information.

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?

With no annotations, the description bears full responsibility for behavioral disclosure. It explains that the tool outputs assigned and top contributing people by hours logged, and mentions budget overrun relevance. This provides adequate transparency about the tool's read-only and query-like nature.

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 well-structured, with three front-loaded sentences: first stating the core function, second specifying the use case, and third linking to budget alerts. There is no extraneous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema, the description sufficiently explains the return values (assigned and top contributors). It covers the primary use case effectively, though additional details on output structure or pagination would enhance completeness.

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

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

The only parameter, project_id, is well-described in the schema. The description adds value by noting that budget-alert results provide the project_id, aiding the agent in parameter resolution. The high schema coverage (100%) is complemented by this additional context.

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's function: retrieving people associated with a project, specifically assigned and top contributors. It distinguishes the tool by highlighting its use for answering 'who is responsible for / working on a project' and ties it to budget overrun scenarios, setting it apart from sibling 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 states when to use the tool, particularly for budget-alert contexts, and advises that budget-alert results contain the project_id for direct use. While it does not list alternatives, the context is clear enough for an agent to decide.

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?

Description indicates the output includes specific metrics but does not disclose read-only nature, authorization requirements, or aggregation level. Since no annotations are provided, the description carries the full burden, and it is minimally sufficient for a simple query 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?

Single sentence effectively conveys the tool's purpose without extraneous words. Could be slightly improved with a structured list of metrics, but current form is efficient and clear.

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?

Lacks important context such as whether results are per-user or aggregate, pagination, or response format. Given no output schema, the description should provide more detail to fully inform 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?

Schema coverage is 100% with both start_date and end_date already described in ISO format. The description does not add further meaning beyond the schema, meeting the baseline for high coverage.

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?

Description clearly specifies a 'Get' operation on 'team resource utilization summary' and lists the key metrics (target hours, actual hours, billable hours, utilization percentage). It distinguishes from sibling tools like get_hours_summary and get_billing_report by focusing on utilization, though no explicit differentiation 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 on when to use this tool versus alternatives such as get_frame_order_utilization or get_budget_health. The description implies usage for resource reporting but provides no exclusions or context for decision-making.

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?

With no annotations, the description must carry behavioral disclosure. It states the tool returns a summary with specific fields, but does not mention authentication needs, data freshness, organizational scope beyond the brief phrase, or any side effects. The 'aging information' hint is useful but insufficient.

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, direct sentence with no extraneous information. It front-loads the core function and list of included data points, earning maximum efficiency.

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?

While the description covers the basic output fields, it lacks details on aggregation level, time range, or update frequency. Given no output schema, more context would help the agent understand the exact structure and constraints.

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

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

The tool has zero parameters, so the schema is empty with 100% coverage. Per guidelines, baseline is 4. The description does not add parameter details as none exist, so this score 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 summary of unbilled time across the organization and lists specific fields (total hours, total amount, entries, aging). However, it does not explicitly distinguish this from sibling tools like get_billing_report or get_hours_summary.

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. The description lacks context on situations that favor this tool over siblings, e.g., get_billing_report for billed time.

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?

No annotations provided, so description carries the burden. It discloses key outcomes: email sent with acceptance link. But does not detail edge cases, rate limits, or idempotency (though mentioned in schema).

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

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

Two sentences with essential information front-loaded. Could be slightly more structured, but it is efficient and to the point.

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 no output schema, description explains the post-invocation outcome (email with acceptance link). It covers the main purpose and constraints, though missing success/failure 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?

Schema coverage is 100%, so baseline is 3. Description adds context about role hierarchy but does not significantly enhance parameter understanding beyond the schema descriptions.

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