TrackingTime

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

Annotations already declare readOnly, idempotent, non-destructive, and open-world behavior, so the safety profile is covered. The description adds meaningful behavioral details beyond annotations: the 500-result cap and the fact that legacy PROJECT/TASK search paths may return null extra fields. It omits the multi-workspace account_id requirement, but overall adds solid context.

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

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

The description is front-loaded with the core purpose, then efficiently covers keyword scope, type behavior, and the API cap in three sentences. Every sentence contributes actionable information with no repetition 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?

For a read-only search tool with full schema coverage and explicit annotations, the description is nearly complete: it covers endpoint, keyword field scope, type modes, null-field caveats, and the result cap. It could mention the account_id multi-workspace requirement or filter semantics, but those are documented in the schema, so the remaining gap is minor.

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 real meaning beyond the schema by specifying which fields keyword searches across (project/task/customer/custom-field/list/subtask) and by explaining the functional difference between type=ALL and legacy type values, including the potential for null response fields. It does not add semantics for filter or account_id, but the added keyword and type context is valuable.

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

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

The description states a specific verb and resource: 'Searches projects and tasks using GET /search/advanced.' It also clarifies that keyword performs free-text search across multiple entity fields, which helps distinguish it from simple list siblings like list_tasks or list_projects. However, it does not explicitly name or contrast with those sibling tools, keeping it just short of a 5.

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

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

The description gives useful guidance on the type parameter, explaining when ALL versus PROJECT/TASK should be used and what trade-offs apply. It does not, however, say when to use advanced_search instead of list_tasks, list_projects, or other search-like siblings, nor does it state exclusions or prerequisites beyond what 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?

Annotations already declare destructiveHint=true and idempotentHint=false, and the description goes beyond them by flagging the operation as 'sensitive', naming the required permission (manage users) and the mandatory confirm=true guard. It stops short of saying whether locks can be released (no unlock sibling exists) or what happens to pre-existing locked entries, so it is strong but not complete.

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 compact sentences: action and scope first, payload format second, caveats third. No filler or repetition, though the 'Limitations:' label bundles unrelated facts (sensitivity, permission, confirm) into one clause.

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

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

With no output schema and a destructive, non-idempotent operation, the description covers the confirmation and authorization burden but omits what locking actually does (presumably freezes time events from edits) and how to recover from a mistake. For a destructive admin tool this leaves a meaningful gap, though the annotations and schema carry part of the load.

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 67%: the description restates the data entry shape (user_id + lock_date) and the YYYY-MM-DD format that the schema pattern already enforces, and confirms that confirm must be true. It never mentions the optional account_id parameter, which is the one field whose semantics (required for multi-workspace users) an agent might miss.

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

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

States a specific verb and resource ('Locks time events') plus scope ('for one or more users from the specified dates'), which is far more precise than the title alone. No sibling is named, but the lock concept is unique enough among the siblings (archive/update/delete_event, approve_timeoff) that an agent can distinguish it without help.

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?

Prerequisites are stated ('requires permission to manage users and confirm=true'), which implies the tool is a deliberate administrative action rather than a routine call. However, there is no guidance on when to prefer this over update_event / update_events_batch, no when-not condition, and no note on the effect of locking already-locked dates.

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

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

Annotations already establish readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds useful workflow context beyond annotations: the tool renders a confirmation card only after record resolution and before/after preparation, and the actual write still requires confirm=true.

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 tight sentences with the purpose and prerequisite front-loaded. Every sentence adds workflow information without repetition 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?

For a 20-parameter nested tool with no output schema and no schema descriptions, the description is far too thin. It covers the high-level confirmation workflow but does not explain how confirm_tool and confirm_args drive the card or what the many display fields mean.

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

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

There are 20 optional parameters with 0% schema description coverage, so the description must carry the burden. It only mentions before/after values and leaves critical fields such as confirm_tool, confirm_args, impact, details, labels, and messages unexplained.

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

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

The description states a specific verb and resource: renders a TrackingTime confirmation card for sensitive changes. This clearly distinguishes it from write tools and from other render_* siblings such as render_task_list or render_project_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?

It gives explicit sequencing: use after resolving the exact record and preparing before/after values, and notes that the target write tool must still require confirm=true. It does not state when not to use it or name an alternative confirmation mechanism, so it falls short of a 5.

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

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

Annotations already declare this as read-only, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds useful context with 'compact' and 'from prepared items,' implying the agent must supply already-assembled data rather than IDs to look up. It does not clarify what the rendered output actually is (markdown, UI component, JSON block) or how warnings/empty items behave, and there is no output schema to compensate.

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

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

Two short sentences, front-loaded with the core action, with no filler or repetition. It is efficient, though the trailing enumeration of entity types adds little since it neither constrains nor differentiates usage.

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

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

For a six-parameter tool with a nested item schema at 0% description coverage and no output schema, the description is far too thin — an agent must guess the shape of each item, the role of eyebrow/warnings/entity_type, and how the rendered result returns. The only thing it settles is that this is a read-only formatting operation.

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

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

Schema description coverage is 0% across six parameters, and the nested item object has seven undocumented sub-fields (id, name, title, badges, fields, subtitle). The description mentions only 'prepared items' and never explains title, eyebrow, subtitle, warnings, or entity_type, nor the item sub-structure, so it fails to compensate for the coverage gap.

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

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

The description gives a specific verb and resource: it renders a compact TrackingTime list card, and 'from prepared items' signals that it formats data rather than fetching it. However, it does not differentiate itself from the many specialized renderers in the sibling set (render_task_list, render_invoice_list, render_report_list, render_project_summary), so an agent cannot tell when this generic renderer is the right choice.

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

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

'Use for events, tasks, projects, customers, invoices, time off requests, or similar records' gives a surface-level context, but it overlaps directly with dedicated siblings like render_task_list and render_invoice_list without explaining which to pick. There is no when-not guidance, no prerequisites, and no stated relationship to the specialized renderers.

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

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive, so safety is covered. The description adds the workflow context (consumes prepared records) but doesn't state what the tool actually returns — presumably a UI/presentation payload — nor whether it has side effects, so it only modestly exceeds what annotations provide.

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

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

Two short sentences, purpose first then usage guidance, with zero filler. Every clause carries information.

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

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

For a tool with 7 parameters, nested array-of-object inputs at 0% schema description coverage, and no output schema, the description does far too little. It should clarify what 'prepared' means and what the render produces, which is exactly the information an agent would need.

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

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

Schema description coverage is 0% and there are 7 params including arrays of invoice objects and metrics objects. The description only vaguely gestures at 'prepared invoice records and billing metrics' and never explains the invoice object fields, metrics shape, warnings, or invoices_title, leaving the schema to speak entirely for itself.

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

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

States a specific verb+resource: renders a TrackingTime invoice list from prepared records and metrics. This distinguishes it from mutating siblings like create_invoice or list_invoices, though it doesn't explicitly contrast with the other render_* tools (render_entity_list, render_report_list).

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

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

Explicitly says when to use it: 'Use after listing invoices or fetching invoice details,' which establishes a clear workflow ordering. It doesn't name an alternative or state when not to use it, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safety profile is fully covered by structured data. The description adds the useful fact that this is a pure presentation step over already-prepared inputs (not a data-fetching step), but says nothing about what happens with omitted optional fields or what the rendered output looks like.

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

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

Two sentences, front-loaded with the verb and resource, with zero filler. Brevity here is appropriate, though the second sentence is thin given how much remains undocumented.

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?

A 17-parameter rendering tool with 0% schema coverage and no output schema leaves the agent guessing which fields to supply, whether all are optional, and what a 'card' output actually is. The low-risk read-only nature limits the damage, but the description is not complete enough for correct invocation.

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

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

Schema description coverage is 0% across 17 parameters, so the description must carry the load. It names only four of the seventeen (metrics, details, tasks, activity) in prose and gives no format, structure, or requiredness guidance for title, badges, status, eyebrow, customer, warnings, progress_percent, or the *_title fields.

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

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

States a specific verb ('Renders') and a specific resource ('TrackingTime project summary card'), and enumerates the ingredient inputs (metrics, details, tasks, activity). It is distinguishable from siblings like render_task_list or render_time_summary by the resource named, though it never explicitly contrasts itself with them.

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

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

'Use after fetching project data' gives a sequencing precondition, implying get_project / list_project_times should run first, but it names no alternative tool and states no exclusion (e.g. when to choose render_task_list instead). Guidance is 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?

Annotations already declare readOnlyHint, idempotentHint and non-destructive, so the safety profile is covered. The description adds useful context that this composes an already-prepared payload rather than fetching data itself, but says nothing about what the rendered output actually is or how warnings are surfaced.

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

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

Two short sentences, front-loaded with the action and resource. The trailing clause 'represented by docs' is opaque and does little work, but there is no padding overall.

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?

A 7-parameter tool with deeply nested report objects, zero schema descriptions and no output schema needs the description to explain the payload and the rendered result. Two sentences cannot cover that, leaving most of the input contract unexplained.

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

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

Schema description coverage is 0% across 7 parameters, so the description carries the full burden. It only implies the 'reports' and 'metrics' inputs via 'prepared report records and summary metrics' and never explains title, eyebrow, subtitle, reports_title, or warnings.

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

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

States a specific verb plus resource: renders a TrackingTime saved/shared report list from prepared records and metrics. That distinguishes it from render_entity_list, render_invoice_list and render_task_list by resource, though 'renders' leaves the output artifact implicit.

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

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

'Use after listing or fetching reports represented by docs' gives a sequencing hint that points at list_reports/get_report as the upstream step. It offers no when-not guidance and does not contrast with the other render_* siblings an agent could pick instead.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that rendering uses 'prepared task metadata, metrics, assignees, and recent activity,' but does not explain the output form, display behavior, or whether missing inputs are tolerated.

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

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

The description is a single front-loaded sentence with no filler. It is efficient, though its brevity contributes to the broader under-specification of a tool with 18 parameters.

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 renderer with 18 optional parameters, no required fields, no output schema, and no parameter descriptions, the definition is too thin. It does not explain how the card is assembled, which inputs are essential for a meaningful render, or what happens when optional fields are omitted.

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

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

Schema description coverage is 0% across 18 parameters, so the schema provides almost no semantic guidance. The description only names four broad input categories (metadata, metrics, assignees, activity) and leaves many parameters such as badges, status, details, warnings, progress labels, and title fields undocumented.

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

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

The description states a specific verb (Renders) and resource (TrackingTime task detail card), and it identifies the kinds of prepared data it consumes. It implies a distinction from list-oriented render siblings via 'detail card,' but does not explicitly differentiate from render_task_list or other render_* 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?

There is no guidance on when to use this renderer versus another render_* sibling, nor any prerequisite such as whether get_task must be called first. The word 'prepared' hints that the caller must assemble inputs, but the description does not state that workflow.

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

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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior. The description adds that it works from 'prepared task records' and produces a view, but it does not describe the returned view, formatting behavior, or what inputs are required to make rendering succeed.

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

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

Two short sentences with no filler, and the core purpose is front-loaded before the usage note.

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

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

For a tool with seven undocumented optional parameters and no output schema, the description is too sparse. It explains when to call it but not how to construct the task list view or what display metadata such as metrics and warnings are for.

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

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

Schema description coverage is 0% across 7 parameters, so the description must compensate but largely does not. 'Prepared task records' vaguely points to the tasks parameter, but title, eyebrow, metrics, subtitle, warnings, and tasks_title are entirely unexplained.

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

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

The description states a specific verb and resource: it renders a TrackingTime task list view from prepared task records. This distinguishes it from data-fetching siblings such as list_tasks, though it does not explicitly distinguish itself from other render_* tools like render_entity_list.

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

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

It gives clear usage context: 'Use after listing project, user, or account tasks.' That tells the agent this is a presentation step, but it names no exclusions or specific alternative render tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful context that the tool consumes prepared data from prior fetches rather than retrieving it. It does not explain what happens with missing sections or what the rendered view actually contains.

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

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

Two tight sentences with no waste. The purpose is front-loaded, followed immediately by the prerequisite workflow step.

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 rendering tool with no output schema and 11 optional inputs, the description covers the source data but not the rendered result, layout, or optional cosmetic fields. It is adequate to start but leaves real gaps about what the view will show and how omitted arrays are handled.

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

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

Schema description coverage is 0% across 11 parameters, and the description only maps four concepts: requests, balances, policies, and metrics. The remaining parameters (title, eyebrow, subtitle, warnings, and the three section titles) are unexplained in both schema and description. The description helps somewhat by saying these are prepared inputs, but it does not compensate for the coverage gap.

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

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

The description states a specific verb and resource: render a TrackingTime time-off view from prepared requests, balances, policies, and metrics. It is clearly distinct from render_time_summary and the invoice/report/list renderers, though it does not explicitly name an alternative it is not.

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

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

It gives explicit sequencing guidance: 'Use after fetching time off requests, balances, types, or policies.' That tells the agent when this tool belongs in a workflow. It stops short of stating when not to use it or naming a sibling alternative.

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

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

Annotations already declare read-only, idempotent, non-destructive and closed-world, so the safety profile is covered structurally. The description adds that it operates on already-prepared entries (no generation of data) and requires a prior fetch step. It says nothing about what the rendered output looks like or how it is delivered.

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, purpose first, usage/prerequisite second. No filler and nothing buried.

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 7 entirely undescribed parameters, a deeply nested entries object, and no output schema, the description is far too thin. An agent cannot know what metrics/warnings/eyebrow mean or what the rendered result is, and the presentation contract is left entirely implicit.

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

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

Schema description coverage is 0% across 7 parameters, so the description must compensate and it largely doesn't. 'From prepared time entries' gestures at the entries array, but title, eyebrow, subtitle, metrics, warnings, entries_title, and the nested entry fields (task, project, duration, time_range, badges, fields) are all undocumented in both places.

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

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

States a specific verb and resource: renders a TrackingTime timesheet view from prepared time entries. This distinguishes it from data-fetching siblings like list_timecards/get_timecard, though it doesn't differentiate itself from the closest presentation sibling, render_time_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?

'Use for daily or weekly work logs after fetching events' gives a clear usage context and a prerequisite ordering constraint. It stops short of naming alternatives (e.g., render_time_summary) or stating when this tool is the wrong choice, so it isn't a full 5.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds the useful point that this only formats already-prepared data rather than fetching it, but says nothing about output or validation behavior.

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

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

Two short sentences, front-loaded with the verb and resource, with zero filler. Its brevity is a problem for coverage, but that is penalized elsewhere, not here.

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?

A 7-parameter tool with no schema descriptions and no output schema needs the description to explain the remaining fields; it covers roughly two of seven. An agent cannot infer what 'eyebrow', 'warnings', or 'breakdown_title' should contain.

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

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

Schema description coverage is 0% across 7 parameters, so the description must carry the load, yet it only glosses 'metrics' and 'breakdown rows'. title, eyebrow, subtitle, warnings, and breakdown_title are entirely undocumented anywhere.

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

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

The description states a specific verb and resource ('Renders a TrackingTime time summary card') and clarifies the input is 'prepared metrics and optional breakdown rows'. It is distinguishable from most siblings (render_timesheet, render_project_summary) by naming a time summary card, though it does not call out those siblings explicitly.

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

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

'Use after fetching or computing summary data' gives a sequencing hint but no conditions for choosing this over other render_* tools, and no exclusions. The usage is implied rather than prescribed.

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