Fieldproxy

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful scope (limited to the last N days, default 30, and reports trail depth) plus a hint at an administrator audience, but says nothing about return shape or aggregation behavior.

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

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

A single front-loaded sentence with no filler; the scope (audit trail, time window) comes first. The awkward '(administrators)' aside slightly muddies an otherwise efficient 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?

For a one-parameter read-only aggregate with no output schema, the description covers the resource, the time window, and the main aggregation dimensions well enough to invoke correctly. The ambiguous audience note is the only real gap.

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

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

Schema coverage is 100% and the single 'days' parameter is fully documented, including '0 = all time'. The description's 'over the last N days' merely restates the schema, so the baseline 3 applies.

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

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

The description names the resource (audit trail) and the dimensions summarized (busiest tables, sources, people) plus the time window, so the agent knows roughly what it returns. However it is a noun phrase with no explicit verb, and the parenthetical '(administrators)' is ambiguous, so no crisp sibling differentiation from workspace_activity or ai_activity_log is provided.

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

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

There is no statement of when to use this tool versus the many adjacent summary/log tools (workspace_activity, ai_activity_log, workspace_usage). Usage must be inferred entirely from the description's scope.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. With no output schema, the description adds useful behavioral context by enumerating the returned sections and stating that the timeline is newest first.

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 that opens with the core resource and then compactly lists the payload. Every clause earns its place given there is no output schema to document return contents.

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 return contents well for a read-only detail tool without an output schema. However, it omits how to obtain the required task_number and gives no usage context relative to the sibling list tool, leaving a meaningful gap 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?

The single required parameter task_number has 0% schema description coverage, so the description must compensate but does not. It never explains the task_number format, source, or relationship to sibling tools like my_agent_tasks.

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 resource: 'One personal-agent task in full', and enumerates the returned contents (goal, linked records, status, notebook, notes, proposal, draft message, timeline). This clearly distinguishes a single-task detail lookup from list-oriented siblings such as my_agent_tasks, though it does not explicitly name that sibling.

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 explicit when-to-use guidance, no prerequisites, and no named alternative such as my_agent_tasks. The singular framing implies this is used after identifying a task, but that is left for the agent to infer.

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

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

Annotations already declare readOnlyHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful behavior beyond that: it aggregates two entity types (updates and proposals) and guarantees newest-first ordering. It does not disclose pagination, limits, or how identity scoping works.

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

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

A single front-loaded sentence with no filler; the resource, scope, window, and sort order all appear in one pass. It is a noun phrase rather than a verb-first statement, but nothing is wasteful.

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

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

With no output schema and only boilerplate annotations, the description should clarify the return shape and identity scoping. It covers the essentials for a low-parameter read tool (what is returned, over what window, in what order) but leaves owner_userid semantics and any volume/pagination expectations unaddressed.

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

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

Schema description coverage is 0%, so the description must carry both parameters. It conveys that 'hours' bounds the lookback window, but 'owner_userid' is never mentioned or explained (whose agents default, whether it's required, whether it names the agent owner or the task owner). Half the parameters remain undocumented.

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

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

States a specific resource (updates and proposals reported by the user's personal agents) and a scope (across their tasks, last N hours, newest first), which is concrete enough to distinguish it from a generic activity or proposal list. It stops short of naming which sibling to prefer (my_agent_tasks, list_proposals, activity_summary), so sibling differentiation is left to inference.

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

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

The recency framing ('reported recently', 'last N hours') implies the use case of reviewing a digest of agent output, but there is no explicit when-to-use, when-not-to-use, or pointer to the many overlapping siblings such as my_agent_tasks, list_proposals, or ai_activity_log.

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, non-destructive, closed-world, so the safety profile is covered. The description adds real value beyond that: it discloses the admin-only access requirement, the newest-first ordering, and the precise set of fields returned including error text and duration.

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

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

A single dense sentence that front-loads the resource and scope, then enumerates the returned attributes without filler. Nothing is redundant and the ordering constraint appears early.

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

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

With no output schema, the description does the work of describing the return shape (key, owner, tool, success/error, duration, argument summary), and it flags the admin restriction. The remaining gap is that the seven optional filters are not tied to those described fields, but the tool is otherwise well-covered.

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

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

Schema coverage is only 43%, so the description must carry more weight. It grounds the filterable dimensions by listing returned fields (key, owner, tool, worked/error, arguments), which maps loosely to key_id, user_id, tool, and status, but it does not explain filter semantics or the relationship between output fields and query parameters.

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

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

States a specific resource (AI connection activity in this workspace) and the exact events captured (tool calls and record reads), plus ordering (newest first). It is clear what the tool returns, though it never names a sibling like ai_usage_summary or workspace_activity to disambiguate.

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?

'(administrators)' signals the audience/permission context, which is useful, but there is no explicit when-to-use or when-not-to-use guidance and no routing to alternative activity/usage tools. Usage is only implied.

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

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

Annotations already establish readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact beyond the annotations: '(administrators)', i.e. an elevated-permission requirement. It says nothing about rate limits, freshness, or whether data is aggregated or sampled.

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

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

A single front-loaded sentence names the scope, the time window, the permission gate, and the breakdown dimensions with no filler. Nothing could be removed without losing information.

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

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

There is no output schema, so the description correctly compensates by stating what the result contains (calls and errors per key, per person, per tool). It does not explain return shape (e.g. totals vs. time series) or list the sibling tools it competes with, leaving a small gap for a single-parameter administrative report.

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

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

Schema description coverage is 100% and the single parameter already documents its bounds and default ('1–90, default 7'). The description's 'last N days' only restates the same window semantics without adding format, edge-case behavior, or default-handling guidance. 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 names the resource (AI connection use) and its aggregation dimensions (per key, per person, per tool), which clearly distinguishes it from sibling ai_activity_log's event-level logging. It lacks a stated verb, but the noun phrase is specific enough to identify the operation. No sibling is named explicitly for contrast.

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 when-to-use guidance and no reference to the nearby alternatives (ai_activity_log, list_ai_connections, workspace_usage). The only scoping signal is the implied 'over the last N days' window. An agent must infer the use case entirely from the noun phrase.

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, destructiveHint=false, openWorldHint=false, so safety and scope are covered. The description adds the output breakdown (created/sent/accepted/rate), which is genuinely useful, but says nothing about permissions, aggregation semantics, or empty-range 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 tight clauses with zero filler; the computed metrics come first and the usage hint second. Every phrase carries information.

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

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

With no output schema, the description usefully enumerates the returned funnel stages, which is what an agent needs to interpret results. Minor gaps remain around how 'accepted rate' is derived and whether results are aggregated or itemized.

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?

Both parameters are fully documented in the schema, including the YYYY-MM-DD inclusive format. The description only refers to 'a date range' and adds no syntax or boundary nuance beyond what the schema already states, so baseline 3 applies.

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

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

States a specific computation (quote-to-close funnel) over a defined scope (date range) and enumerates the metrics produced: quotes created, sent/pending, accepted, accepted rate. This is far more specific than a name restatement, though it does not explicitly name a sibling it is distinct from.

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 conversion rate / pipeline funnel' gives concrete user-intent triggers that map a request to this tool, which is useful routing guidance. It stops short of stating exclusions (e.g. when to prefer revenue_by_month or ar_aging 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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the useful output concept (unpaid invoices bucketed by days past due), which matters because there is no output schema, but says nothing about filters, scope, or result size.

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

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

One short defining clause followed by three compact trigger phrases; nothing is padded and the purpose arrives first.

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

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

For a parameterless read-only tool with no output schema, the description supplies an adequate picture of what comes back (unpaid invoices plus days past due). The only real gap is the unresolved overlap with get_ar_aging.

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

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

The tool takes zero parameters, so the baseline expectation is 4. The schema is trivially complete and there are no parameter semantics for the description to clarify.

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 resource and what it returns: 'unpaid invoices with how many days past due'. That is clearer than a bare name restatement, but it does not distinguish itself from the near-identical sibling 'get_ar_aging', which an agent could easily pick instead.

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 trigger phrases ('AR aging', 'overdue invoices', 'who owes us') that imply when to use it, but gives no exclusions and never mentions alternatives such as get_ar_aging or find_invoices for related invoice lookups.

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

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

Annotations already declare a safe, read-only, closed-world operation, so the safety profile is covered. The description adds genuine behavioral value by disclosing the detection logic: promises are cross-referenced against invoice on the job, follow-up job creation, payment receipt, or communication sent. It does not disclose return shape or limits, keeping it below 5.

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

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

A single sentence, front-loaded with the verb and resource, with the most important scoping constraint ('ONLY unfulfilled') saved for the end. The parenthetical enumeration of checks is dense but earns its place by defining 'fulfilled'; slightly long for one sentence.

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

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

There is no output schema, so the description carries the full burden of explaining return values; it conveys what is returned (unfulfilled promises) but not the record shape, pagination, or ordering. For a cross-referencing analytical query this leaves an agent with visible gaps.

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

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

Schema description coverage is 0% and the single parameter 'days_back' is undocumented in both schema and description. The description hints at a time window via terms like 'next week' but never defines the parameter's unit, default, or the window it controls. For a conventional single numeric parameter this is the minimal viable level.

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 ('Lists every tech note that says follow up...') and defines the exact scope of the result ('Shows ONLY the promises that were never fulfilled'). An agent can distinguish this from siblings like quotes_to_follow_up or overdue_tasks without inspecting schemas.

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

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

Usage is implied by the result definition (a report of unfulfilled promises), but the description never says when to prefer this over close siblings such as quotes_to_follow_up, list_email_followups, or overdue_tasks. No exclusions or prerequisites are stated.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, but the description adds real behavioral context beyond them: traffic is not factored in, results are not persisted or assigned, the 50-stop ceiling, and the 10-address-per-call limit. These are operational traits an agent cannot derive from the annotations or 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?

Dense and front-loaded: purpose and return shape come first, then input constraints, then the sibling hand-off. Every sentence carries information, though the opening sentence is long and packs several clauses that could be split.

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

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

There is no output schema, so the description carries the return-value burden, and it does so by naming exactly what comes back (ordered stops, time-after-start, total duration and distance). Combined with the limits, defaults, and sibling routing, nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 67%, and the description fills key gaps: the 50-stop maximum, the cap of 10 addresses per call, the per-stop optional id/label/service minutes, and the default round-trip behavior when home_base is omitted. Some of this (home_base shape) repeats the schema text, so it is additive but not exhaustive.

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 (calculate) and resource (route) with the exact deliverable: visiting order, elapsed time per stop, total drive time and distance. It also scopes the operation ('up to 50 stops by road, as a round trip') and names the sibling it is not (plan_day_routes), so an agent can separate it from the other routing tools without opening a schema.

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

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

Explicitly names the alternative ('to plan technicians' days, use plan_day_routes') and states the condition that selects it. It also covers the default mode of operation ('Without home_base the trip starts and ends at the first stop') and the constraint 'Nothing is saved or assigned', leaving little to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description usefully adds the output shape (flagged customer plus the exact triggering sentence and full context) where no output schema exists, but it says nothing about defaults, thresholds, or how keyword scanning behaves when churn_keywords is omitted.

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 front-loaded sentences with the data sources stated before the return shape, and no filler. The phrase 'both job-level and customer-level' is slightly wordy but carries real information.

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

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

For a two-parameter read tool with no output schema, the description covers the scan scope and return shape but omits parameter behavior entirely and offers no differentiation from the similar churn-feedback sibling, leaving real gaps an agent must guess at.

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

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

Schema description coverage is 0% and the description never mentions min_rating or churn_keywords. It does not explain the rating threshold meaning or whether churn_keywords is a comma-separated string or a single term, so it fails to compensate for the undocumented 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 states a specific verb (scans) and concrete resources (satisfaction ratings, written feedback, job-level and customer-level notes) and adds the processed result (flagged customers with the triggering sentence). It is clearly distinguishable from generic search tools, though it never names the near-identical sibling customer_churn_feedback_flags to disambiguate.

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 versus alternatives, despite a sibling (customer_churn_feedback_flags) that appears to cover overlapping ground. No prerequisites, no conditions, no exclusions are stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and a closed world, so the safety profile is covered. The description adds a genuine behavioral constraint not present in any structured field: the table must have history enabled for this to work. It stops short of 5 by not covering permissions or output shape.

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

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

One tight sentence with the core behavior front-loaded, followed by an illustrative example and a prerequisite. No filler; every clause earns its place.

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

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

For a read-only comparison tool with no output schema, the description conveys what is returned (field-level differences) and the key precondition. The main gap is that neither the return format nor the identity/type expectations for 'table' and 'record_id' are elaborated.

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

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

Schema coverage is 50%: 'from' and 'to' are documented in the schema, while 'table' and 'record_id' are not. The description usefully clarifies the time semantics ('between an earlier time and now (or between two times)'), confirming that 'to' defaults to now, but does not compensate for the undocumented table/record_id parameters.

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

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

States a specific verb+resource: computing how a record's fields differ across time, with a concrete example ('what changed on job 42 since Monday?'). It does not explicitly distinguish itself from the sibling record_history, which likely covers overlapping ground, so it stops short of a 5.

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

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

Provides a clear when-to-use scenario via the example question and states a real prerequisite ('The table must have history switched on'). It does not name an alternative tool or an exclusion, so it is clear context without explicit routing.

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

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

Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral detail beyond that: it returns the exact triggering sentence for written-feedback flags, and falls back to rating evidence when no sentence matches. It does not mention permissions or limits, keeping it from a 5.

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

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

A single, front-loaded sentence that puts the core search behavior first and the return-value behavior second. Dense but no wasted clauses; only slightly long for the amount of content it carries.

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

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

With no output schema, the description usefully sketches return values (triggering sentence or rating evidence), which is a real contribution. However, the lone required parameter's semantics remain undefined, which is a meaningful gap for an agent trying to call this correctly.

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

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

There is one required parameter (min_rating) with 0% schema description coverage, and the description never explains it. Worse, the phrase 'low satisfaction rating' implies a low-value threshold, which could conflict with or confuse the meaning of a 'min_rating' parameter, leaving its direction and semantics ambiguous.

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+resource: finding customers whose job feedback has churn-risk language or a low satisfaction rating, and it even specifies what is returned (the triggering sentence). It does not explicitly differentiate itself from the sibling 'churn_risk' or 'segment_customers', so it stops short of a 5.

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

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

Usage is implied by the description (job-feedback churn signals) but there is no explicit when-to-use/when-not guidance, no prerequisites, and no routing to or away from the related 'churn_risk' sibling. An agent must infer the context.

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, destructiveHint=false and a closed world, so safety is covered. The description goes beyond them by defining the selection criterion ('explicit dissatisfaction or churn signals') and by enumerating return fields, which is valuable since no output schema exists. It stops short of stating scan scope (whole workspace? time range?) or result volume.

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

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

A single front-loaded sentence that names the trigger condition before the returned fields, with no filler or restated boilerplate. It is efficiently sized for a no-parameter tool, though it is a fairly dense run-on rather than cleanly segmented.

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

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

For a zero-param tool the description covers selection criteria and return shape, which is the main thing needed given the absent output schema. But it omits scope (what data range/entity set is scanned), result limits, and any differentiation from the similarly named churn sibling, leaving real gaps for an agent deciding whether to call it.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description does not need to compensate for any schema gap here.

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 concrete verb+resource: it finds customer feedback sentences containing explicit dissatisfaction/churn signals and enumerates what it returns (customer, job, rating, triggering sentence). That is a clear, specific purpose. However, it does nothing to distinguish itself from the near-identical sibling `customer_churn_feedback_flags`, so the agent cannot tell which churn tool to pick from the name alone.

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

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

There is no explicit when-to-use guidance, no prerequisites, and no named alternative. With `customer_churn_feedback_flags`, `churn_risk`, and `priority_audit_from_text` in the sibling list, the definition should say what makes this sentence-level scan different, but it leaves the choice entirely to inference.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), so the description's value is in the return-shape disclosure: one line per table with name/description/first columns without `tables`, versus full column lists, types, foreign keys and notes with `tables`. That is meaningful behavior beyond the annotations, though it says nothing about pagination or failure modes.

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

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

Three tight sentences, no filler, with the purpose, the two operating modes, and the call trigger front-loaded in that order. Every sentence earns its place.

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

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

For a single optional-parameter introspection tool with no output schema, the description supplies both the call condition and the full shape of both return modes. Nothing an agent needs before invoking it or interpreting the result is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes further by explaining what the parameter changes semantically: omitted returns a condensed summary, supplied returns full detail. The max-20 limit lives in the schema rather than 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 uses a specific verb+resource ('describe the workspace's data tables') and immediately scopes it to readable tables, distinguishing it from write-side siblings like dispatch_query or run_sql. The two-mode behavior is stated up front so the agent knows what it gets.

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 an explicit call condition ('Call this before writing SQL'), which is decisive usage guidance. It stops short of naming an alternative tool or stating when not to use it, 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 readOnlyHint=true, destructiveHint=false and closed-world scope, so the safety profile is covered. The description adds real behavioral value beyond that: the availability mode is sorted lightest-first, and both modes return booked minutes plus job count. It does not mention pagination or limits, but for a read-only aggregate this is solid.

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

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

Front-loads the core value ("Per-technician capacity in ONE call") and then spends each following clause on mode-specific semantics. No filler, no repeated annotation 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?

Without an output schema, the description does the necessary work of naming the returned fields (booked minutes, job count) and the ordering for the availability mode. That is enough for correct invocation, though units or result-size expectations are unstated.

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

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

Schema coverage is 100%, so the required/optional relationship of date, from_date and to_date to each mode is fully documented in the schema. The description's mode-to-parameter mapping largely restates those schema descriptions and adds no format or constraint detail beyond them. Baseline 3 applies when the schema carries the load.

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 resource (per-technician capacity) and enumerates the two modes with their distinct inputs and outputs (booked minutes + job count, lightest first). It clearly separates itself from find_jobs by naming it as the alternative to looping. However, it does not distinguish itself from close siblings like tech_workload or get_tech_performance, which an agent could plausibly confuse it with.

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

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

Gives explicit mode-selection guidance: date for availability, from_date/to_date for workload, and the key directive "Use this instead of looping find_jobs per tech." That is a concrete when-to-use rule with a named alternative. It lacks a when-not-to-use note relative to the similarly named tech_workload sibling.

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

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint, destructiveHint=false). The description adds genuinely useful behavior beyond that: traffic is excluded from the estimate, and out-of-coverage places are refused with the region named. Lacks auth/rate-limit context, but this is solid added value.

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

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

Three tight sentences, front-loaded with the core capability, then the format, then the caveats. Every sentence earns its place with no redundancy.

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

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

For a two-param, no-output-schema tool, the description covers return semantics (minutes, km, one-way), accepted input forms, a limitation (no traffic), and failure behavior (coverage refusal). An agent has everything needed to call it correctly.

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

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

Schema coverage is 100%, so both parameters are fully documented in the schema. The description repeats the address-or-{lat,lng} form without adding syntax, validation, or ambiguity-resolution detail, so the baseline 3 applies.

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

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

States a specific verb+resource with units and scope: 'Road drive time (minutes) and distance (km), one way, from one place to another.' An agent can immediately tell this apart from geocode_address, nearest_technicians, or technician_route.

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

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

Usage is implied by the purpose (compute point-to-point drive time/distance), and the traffic caveat narrows expectations. However, no siblings are named and there is no explicit when-to-use/when-not guidance despite many adjacent routing tools (technician_route, plan_day_routes, zones_for_location).

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, destructiveHint=false, and openWorldHint=false, so safety behavior is covered. The description adds output-oriented behavior: results are split by dimension, sorted by biggest movers, and flagged when values appeared or disappeared. It does not cover pagination or performance limits, though limit is documented 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?

Front-loads the purpose in the first sentence, then gives compact invocation guidance and a useful iteration tip. The description is appropriately sized with no filler or unnecessary 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?

No output schema exists, but the description explains the output shape: change split by dimension, biggest movers first, flagged appeared/disappeared values. Combined with the rich parameter schema and read-only annotations, an agent has enough context to invoke this analytical tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents all 9 parameters in detail. The description restates key concepts like metric, dimension, date_column, and the baseline/comparison windows, but adds no syntax 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?

States a specific analytical action: explain why a number changed between two periods, split by a dimension, biggest movers first. The purpose is clear and specific, but the description does not explicitly distinguish this tool from sibling analytics tools such as compare_record, revenue_by_month, or run_sql.

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 implied usage context ('between two periods') and an iteration tip ('Try another dimension when the first doesn't explain it'). However, it gives no explicit guidance on when to choose this tool over alternative analytics or SQL tools, and no when-not conditions.

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

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false), the description discloses two real behavioral traits: a 10,000-row cap on the result and a publicly accessible download link with a sharing warning. That security/data-exposure note is exactly the kind of context annotations cannot convey. It stops short of 5 because permission requirements and query-timeout/error behavior are unstated.

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

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

Two sentences, zero filler, with the core action, the row limit, the return value, and the sharing caveat all front-loaded. Every clause earns its place.

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

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

With no output schema, the description correctly states the return (a download link) and adds the row cap and public-link caveat. For a two-parameter export tool this is nearly complete; only auth/permission context and behavior on invalid or oversized SQL are missing.

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

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

Schema coverage is 50%: only 'filename' is documented ('Without extension') while 'sql' is bare. The description partially compensates by stating the sql argument must be a single SELECT capped at 10000 rows, but says nothing about the filename parameter or naming rules. Adequate, not additive 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 gives a specific verb+resource+output: 'Run one SELECT and save the result as a CSV file (up to 10000 rows); returns a download link.' That is far more informative than a restated name. It never differentiates itself from query-running siblings like run_sql or dispatch_query, so it stops short of a 5.

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

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

Usage is only implied: an agent can infer this is the tool to reach for when a CSV deliverable is wanted, and the 'one SELECT' phrasing hints at a single-statement constraint. There is no explicit when-to-use vs. run_sql/dispatch_query guidance or any stated prerequisite (e.g., workspace scope or permissions).

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/openWorldHint/destructiveHint, so the safety profile is covered. The description adds real context beyond that: whole-corpus scanning scope, AI-based extraction, date resolution from relative phrases ('tomorrow'/'next week'), and a flag for owners who are not system users — meaningful behavioral detail.

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, purpose front-loaded, zero filler. The second sentence efficiently carries the output semantics that the absent output schema would otherwise leave blank.

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

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

With no output schema, the description partially compensates by naming the extracted fields (owner, action, resolved due date, non-system-user flag). For a zero-parameter, read-only analysis tool this is close to sufficient, though it says nothing about result volume, pagination, or how notes are sourced.

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

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

The tool takes zero parameters, so the schema imposes no semantic burden and the baseline is 4. The description correctly spends no text on inputs and instead describes the shape of the extracted rows.

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: scanning notes to extract follow-up promises, callbacks and deadlines from free text, and it clarifies the output shape (owner, action, due date). It does not, however, distinguish itself from close siblings such as broken_promises, quotes_to_follow_up or overdue_tasks, so the agent must infer the boundary.

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

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

It conveys scope ('Scans all notes') but gives no explicit when-to-use guidance, no exclusions, and no routing to alternatives among the many follow-up-adjacent siblings. An agent has to guess whether this or broken_promises/quotes_to_follow_up is the right call.

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, non-destructive, and closed-world, so the safety profile is covered. The description adds real behavioral scope beyond that: only sent messages are returned and drafts are excluded, which tells the agent what the result set excludes. It does not discuss ordering or result shape, keeping it short of a 5.

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

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

A single dense sentence with the sent-vs-draft distinction front-loaded and filtering compressed into a trailing clause. No filler sentences and nothing redundant with the schema.

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

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

For a three-parameter, fully documented, read-only lookup with no output schema, the description gives enough to call it correctly and distinguish its scope. Only minor gaps remain, such as result ordering and what fields are returned.

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 limit, channel, and customer_id are already documented in the schema. The description only restates the channel/customer filtering and adds no format or syntax detail (e.g. how customer_id relates to customers.id, or default paging behavior). Baseline 3 applies when the schema does the heavy lifting.

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

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

It names a concrete verb and resource ('Find SENT emails/SMS from the communications log') and immediately disambiguates the most likely confusion by excluding drafts. An agent can tell this apart from inbox-reading or draft tools without opening a schema.

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

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

The description states available filters ('Filter by channel and/or customer') which implies when the tool is useful, but it never names an alternative sibling (e.g. search_inbox, read_email_thread) or states when NOT to use it. Usage is implied rather than spelled out.

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

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

The readOnlyHint, destructiveHint=false, and openWorldHint=false annotations already define the safety profile. The description adds useful return-field information (id, customer name, status, end_date), but it omits pagination, sorting, or combined-filter behavior that would give richer behavioral context.

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

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

Two tightly written sentences: the purpose is front-loaded, and the return fields are given immediately after. Every sentence contributes useful 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?

For a simple read-only lookup with a fully documented schema and safety annotations, the description is nearly complete. It compensates for the absent output schema by listing returned fields, though it does not mention default limits or result ordering.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the input schema. The description's 'optionally expiring soon' lightly maps to expiring_within_days but adds no syntax, defaults, or format details 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 names a specific verb ('Find') and resource ('service contracts'), making its scope clear against most sibling tools. It does not explicitly differentiate itself from other find_* or list_* siblings, so it falls short of a 5.

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

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

Usage is implied by 'optionally expiring soon', which signals a valid filtering use case. However, it does not state when to use this tool versus alternatives like find_customers or find_invoices, and no exclusions or prerequisites are given.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds value by enumerating the returned columns (id, name, email, phone, city, lead_status), which matters because there is no output schema. No note on result ordering or truncation behavior.

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

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

Three short sentences, zero filler: purpose, return shape, and the alternative routing hint are all front-loaded in that order.

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, listing the return fields is the right compensating move, and the geo alternative covers the main sibling ambiguity. Minor gaps remain: no distinction from lookup_customers and no mention of result ordering or pagination behavior.

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

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

Schema description coverage is 100%, so both parameters (limit, search) are already documented, including defaults and max. The description's 'by name or company' only loosely mirrors the schema's broader match scope (first/last name, company, email), adding nothing beyond it. Baseline 3 applies.

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

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

States a specific verb and resource (find customers/leads) plus the match keys (name/company) and the returned fields. It partially differentiates from siblings by routing geo queries to search_freeform, but does not distinguish itself from the very similar lookup_customers sibling.

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 tells the agent to use search_freeform instead when filtering by geographic criteria (within N km, by city), which is a real routing decision. Beyond that one exclusion there is no guidance on when to prefer this over lookup_customers or segment_customers.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds valuable behavior beyond that by enumerating the return fields (id, invoice_number, totals, balance_due, due_date, status, customer name), which matters because there is no output schema. It does not mention pagination or default row counts.

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?

Compact and front-loaded: the verb+resource comes first, then the filter definitions, then the return fields. It is dense but every clause carries information, though the parenthetical predicate list is slightly run-on for a single sentence.

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

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

With annotations covering the safety profile and no output schema, the description fills the important gaps: filter predicates and return-field shape. The only unwritten piece is limit/pagination behavior, which the schema already documents, so the definition is nearly complete for this 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?

Schema coverage is 100%, which sets a baseline of 3, but the description goes further by defining the exact predicate behind each enum value (e.g. overdue = due_date<today AND balance_due>0 AND not paid/cancelled/refunded), replacing the schema's vague 'Invoice state filter.' That is meaningful added semantics the schema does not carry.

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 ('Find invoices') and immediately defines the three filter modes with exact predicates, so the agent knows precisely what the tool retrieves. It does not, however, distinguish itself from near-neighbors like get_ar_aging or ar_aging, which likely also surface receivables.

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

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

Usage is only implied by the tool name and filter semantics; there is no explicit statement of when to prefer this over ar_aging, get_ar_aging, or quotes_to_follow_up. The detailed filter conditions help the agent pick a mode once it has decided to call the tool, but they do not guide tool 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?

Annotations already declare readOnlyHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful non-annotation context: it discloses the return shape (id, job_number, title, status, schedule, names, coordinates) and that the id is a DB pk usable for navigation, which helps an agent chain calls.

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

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

Three tight sentences with zero filler: purpose first, return shape second, alternative routing last. Every sentence earns its place and the most decision-relevant content 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?

There is no output schema, so the description correctly compensates by enumerating the returned fields. For a read-only, no-required-param finder with full schema coverage, this is nearly complete; only pagination/limit behavior is left to the schema.

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

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

Schema coverage is 100%, with clear per-parameter descriptions and two enums, so the schema carries the semantic load. The description adds nothing about filter syntax or combination behavior; the phrase 'common filters' is generic. Baseline 3 is appropriate when the schema is this complete.

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 ('Find jobs') and immediately scopes it with 'with common filters.' It also enumerates the returned fields and explicitly names the sibling (search_freeform) it is not meant to replace, so an agent can distinguish it from find_customers/find_invoices and from freeform search without opening a schema.

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

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

Gives explicit routing: 'Use search_freeform for filters this tool lacks (e.g. by city),' which names the alternative and the condition that selects it. It stops short of stating exclusions for the other related listers (technician_jobs, todays_schedule), so it is clear but not fully exhaustive.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds real value by enumerating the returned columns (id, quote_number, status, total, valid_until, customer name) in the absence of an output schema, though it says nothing about ordering, pagination, or truncation beyond what the schema's limit parameter states.

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

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

Two sentences, front-loaded with the action and filters, followed by the return shape. Every clause carries information an agent needs and nothing is padded.

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

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

For a zero-required-parameter read-only list tool with no output schema, the description supplies both the filter surface and the result columns, which is close to sufficient. The remaining gap is behavioral detail around result ordering and how the 50/300 limit interacts with large result sets.

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

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

Schema description coverage is 100%, so all four parameters (limit, status, customer_id, expiring_within_days) are already documented in the schema with defaults, ranges, and semantics. The description only restates the filter categories at a higher level, adding no syntax, format, or edge-case detail 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?

States a specific verb (Find) and resource (quotes), plus the filter dimensions it supports and the fields it returns. The sibling set contains a near-neighbor (quotes_to_follow_up) that is never distinguished, so it falls short of a 5.

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

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

The word 'optionally' signals that filters are additive narrowing criteria, which implies usage, but there is no statement of when to prefer this over quotes_to_follow_up, find_invoices, or lookup_customers, and no 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?

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered by structured data. The description adds useful context that userid is the value to use for assignment, but says nothing about pagination behavior or total-count semantics beyond what the schema's limit parameter implies.

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 resource and followed by the most decision-relevant detail (userid for assignment) and the optional filters. 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?

There is no output schema, so the description carries the burden of describing returns and does so by naming userid, username and mobile. It is nearly complete for a simple lookup, missing only result-volume/pagination and any hint about the default active_only behavior's impact.

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 limit, search and active_only, making 3 the baseline. The description adds only the assignment use of userid and the fuzzy phrase 'search by name', which is slightly less precise than the schema's 'Match against username'.

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

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

States a specific verb and resource ('List technicians') plus the underlying table (fp_users) and the return fields, so the agent knows exactly what it gets back. It does not, however, differentiate itself from close siblings like nearest_technicians or technician_locations, so an agent must still infer which technician-listing tool to pick.

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 clause 'Optionally filter to active only or search by name' gives implied usage for the two filter parameters, but there is no explicit when-to-use-this-vs-alternatives guidance despite several sibling technician tools (nearest_technicians, tech_workload, technician_jobs) that could be confused with 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false, openWorldHint=true), the description discloses a genuinely important behavioral trait: the generated link is public and anyone with it can open the file, so sharing must be deliberate. That is real value added that structured fields do not capture, though it says nothing about persistence or idempotency.

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, verb and resource front-loaded, with the sharing caveat placed at the end where it belongs as a warning. Nothing is redundant.

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

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

With no output schema, the description usefully discloses the return value (a PDF link) and the key safety nuance. Gaps remain around the undocumented filename parameter and any need to enumerate templates first, but for a 3-param tool this is close to 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 only 33%, so the description must compensate; it clarifies the two most important parameters (template by name or id, and the arguments object via the {job_id: 42} example). The filename parameter is left undocumented in both schema and description, so compensation is incomplete.

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 (fill) and resource (workspace document template) plus the output (PDF link), with a concrete example argument. An agent can distinguish this from siblings like list_document_templates, preview_proposal, or generate_estimate without opening any schema.

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

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

Implies usage by explaining that the template can be passed by name or id and that a record is supplied via arguments, which hints at the list_document_templates -> generate flow. However, it never explicitly says when to use this tool versus alternatives such as preview_proposal, nor states any 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=false, and the description reinforces this by explicitly stating 'Nothing is saved, and it makes no quote document' — closing the natural worry that 'generate' produces a persisted quote. It stops short of disclosing error behavior or product-list availability assumptions, so not a 5.

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

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

Three dense sentences with no filler, and the core operation leads. The measurement example and discovery instruction are packed into one clause each, which is efficient though the sentence carries two distinct ideas that could be split for scanability.

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

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

No output schema exists, so the description carries the return contract by naming the line-item fields and the template-derived origin of pricing. Combined with the provenance and no-persistence caveats, an agent has everything needed to invoke this correctly.

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

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

Schema coverage is 67% and template_id is undocumented there; the description compensates by requiring it come from list_estimate_templates. It also enriches the vague schema description 'field → number' with a concrete example map ({roof_area_m2: 120, pitch_deg: 30}) and explains the discovery mode ('call without measurements'), which the schema cannot express.

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 ('Price a job with a published estimate template') and names the exact artifact it consumes (a template from list_estimate_templates) plus the return shape (product, quantity, unit price). An agent can distinguish this from list_estimate_templates, generate_document, and find_quotes without opening any schema.

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

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

Gives explicit preconditions and alternatives: 'Only works with a template from list_estimate_templates' routes the agent to the enumeration tool first, and 'Call without measurements to see which fields the template uses' tells the agent how to discover required inputs. Both when-to-use and when-not-to-use terrain are covered.

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

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

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) by disclosing that the link is public, that the document is not attached to any record, that complete HTML is used as-is with no letterhead, and that <script> is disallowed. It also prescribes an inspect-the-preview step before telling the user it's ready.

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?

Front-loaded with the core action, mentions the sibling, then details modes and caveats in a logical order. Dense but every sentence carries operational content; the parenthetical examples are slightly loose but not wasteful.

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

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

Covers inputs, the public-link caveat, the absence of record attachment, and even the return shape (link, summary, page-1 image) despite no output schema. Nothing essential for correct invocation is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: the two-mode contract of `html` (body gets branded letterhead vs. complete document used as-is) and how evidence of rendering is returned. It doesn't expand on brand/filename 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?

States a specific verb+resource ('Turn a report or document you write as HTML into a PDF and get a link') and explicitly resolves identity ambiguity against the copilot's own generate_pdf. An agent can tell this apart from generate_document/generate_estimate siblings via the HTML-to-PDF framing.

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

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

Gives clear triggering context ('when the workspace's instructions or an action's answer say to call generate_pdf, this is it') and routes attachment to the workspace's own action or propose_write. It does not explicitly contrast with generate_document, so it stops short of a full when/when-not.

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

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

Annotations already cover the read-only/open-world/safe profile, so the bar is lower. The description adds real behavioral context beyond them: results may come from cache or a fresh lookup, include a confidence value, and failures are reported as not-found rather than a guessed coordinate.

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 batch limit and return shape are front-loaded, and the not-found guarantee closes 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?

With no output schema, the description usefully sketches the return shape (lat, lng, confidence, cache vs fresh, explicit not-found). For a single-parameter tool this is nearly complete, only lacking format/precision or input-normalization specifics.

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

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

Schema coverage is 100% and the only parameter is documented there as '1–10 addresses', so the schema does the heavy lifting. The description's 'up to 10 addresses' is consistent but adds no syntax or format detail 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 states a specific transformation: addresses in, coordinates (lat/lng) out, with a 10-address batch cap. It's clearly a forward geocoder, implicitly distinguishing it from the reverse_geocode sibling, but it never names that sibling explicitly.

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

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

There is no when-to-use or when-not-to-use guidance, and no mention of alternatives such as reverse_geocode. The 10-address cap implies a batching use case but the agent gets no routing help for choosing among the many location-related siblings.

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

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

Annotations already declare it is a read-only, non-destructive, closed-world operation, so safety is covered. The description adds the bucketing behavior, which is useful. However, it does not state whether the result is as-of-now or how it handles multiple currencies, nor any auth scope. With annotations carrying the safety profile, a 3 is appropriate.

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

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

One tight sentence for the definition, one for usage. Front-loaded with the core concept and zero waste.

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?

Complete enough for a zero-parameter read-only summary. The description tells the agent what the output means (aging buckets) and when to use it. It lacks edge-case notes (e.g., currency, as-of date), but no output schema exists, so the description carries the return-value burden and does so adequately.

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 zero parameters, so there is nothing to document. The description correctly adds meaning by defining the bucket boundaries, which would otherwise be unknown. Baseline 4 for zero params.

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 the specific resource (accounts-receivable aging) and the exact output structure (buckets: current, 1-30, 31-60, 61-90, 90+). Distinguishes itself from sibling ar_aging and from related tools like overdue_tasks and find_invoices by defining the specific aggregation.

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 clear usage example ('how much are we owed by buckets') that indicates when to invoke. Does not explicitly name alternatives or exclusions, but the example is enough for an agent to select it over find_invoices or overdue_tasks.

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

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

Annotations already establish the safe read-only, non-open-world profile, and the description adds genuinely useful behavioral context beyond them: it discloses that 'steps' and 'recipes' are large and require a two-step retrieval pattern to avoid oversized responses. It doesn't discuss truncation or formatting of returned content, which would earn a 5.

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

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

Three sentences, front-loaded with the purpose, then the topic enumeration, then the operational caveat about large topics. No filler and every clause carries information.

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

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

With no output schema, the description usefully explains what comes back (a section list vs. a section's content) and how to navigate the large topics. It is nearly complete for a docs-retrieval tool; only the fallback behavior for an unknown section key is unspecified.

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

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

Schema coverage is only 50%, and the enum values for `topic` carry no schema descriptions; the description compensates by defining all four topic values. It also clarifies the intended interaction pattern for `section` (omit to list sections, supply a key to fetch one) beyond the schema's example.

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 ('Read Fieldproxy's automation reference') and enumerates exactly what each topic contains, so an agent knows precisely what knowledge it retrieves. It is clearly distinguishable from sibling doc tools like get_widget_docs and describe_schema.

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

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

Gives explicit procedural guidance: for the large 'steps' and 'recipes' topics, call without `section` to get the section list and then request one section. It does not, however, say when to prefer this tool over sibling documentation tools, so it stops short of full when/when-not coverage.

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, openWorldHint=false, destructiveHint=false, so the safety profile is covered. The description adds the detail that the call_id parameter resolves to a full call record with five named sub-fields, which is useful context beyond annotations. But it says nothing about what happens when call_id is invalid, whether the transcript is paginated, or the data's freshness.

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, front-loaded with the core purpose. The parenthetical 'who said what' is a helpful gloss on 'transcript'. No wasted words.

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

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

For a 1-param read tool with no output schema, the description should specify the call_id's origin and format, and ideally reference list_calls as the source of valid IDs. The enumerated return fields partially compensate for the missing output schema, but the input side remains under-documented.

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

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

Schema coverage is 0% and the single parameter call_id has no description in the schema, so the description carries the burden. It doesn't state that call_id is the identifier used to select the record, nor its format (UUID vs numeric). Baseline for a 1-param tool with a high-coverage schema would be ~4, but here the schema is empty and the description does little to compensate.

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 ('One call in full') and enumerates what is returned (transcript, outcome, summary, objective, tool use). This clearly distinguishes it from the sibling list_calls (which would return many). However, it doesn't name list_calls as the alternative or explicitly frame itself as the single-record counterpart.

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

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

No explicit when-to-use guidance. The phrase 'One call in full' implies it's for drilling into a single record, but the description never states when to use this versus list_calls or other search tools. The agent must infer the retrieval pattern from the name alone.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuine context by describing the return contents (summary, ranked items, per-item evidence), which is real value beyond the annotations, but omits freshness/pagination or whether it errors when no result exists.

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

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

A single tight sentence with no filler, front-loaded with the resource and payload shape. It is a noun fragment rather than a full statement of action, which slightly weakens it, but nothing is wasted.

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

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

With no output schema, the description does cover the return shape, which is the main thing an agent needs. However, for a getter tied into a run_insight/list_insights workflow, it lacks the id semantics and any error/empty-state behavior, so it is only adequate.

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

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

Schema description coverage is 0% and the single required 'id' parameter is never mentioned in the description. The agent gets no hint whether 'id' refers to the insight id from list_insights, a run id, or accepts both integer and string forms as the schema allows. With 1 parameter and zero coverage, this gap matters.

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

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

The description names a specific resource ('the latest result of an insight') and the shape of the payload (summary, ranked items, evidence). It distinguishes itself implicitly from list_insights and run_insight, but the verb is only implied and no sibling is named 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?

No when-to-use guidance, no prerequisites, and no alternatives named. With siblings run_insight and list_insights present, the agent must infer that this is the retrieval step following generation. Nothing tells it when this tool is or isn't appropriate.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered by structured data. The description adds that metrics are scoped to a date range with defaults implied, but says nothing about aggregation granularity, whether missing techs appear, or result shape. It adds modest value over the annotations.

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

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

Two short sentences, front-loaded with the resource and its metrics, then the single optional scoping dimension. No filler.

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

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

For a zero-required-parameter read-only reporting tool with a fully documented schema and no output schema, the description covers what is computed and over what range. It is close to complete; only the shape/granularity of the returned metrics is left implicit, which is a minor gap.

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

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

Schema description coverage is 100%, so all three parameters (from_date, to_date, technician_id) are already documented with formats and defaults. The description only restates the optional technician filter, adding no syntax or semantics 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?

States a specific verb+resource ('per-technician performance') and enumerates the exact metrics returned (jobs scheduled, completed, completion rate), which distinguishes it from nearby siblings like tech_workload and technician_jobs. It does not explicitly name an alternative, so it stops short of a 5.

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

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

'Optionally restrict to one technician' describes a parameter behavior, not when to use this tool versus alternatives such as tech_workload or technician_jobs. There is no when/when-not guidance or named 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 readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds useful behavioral context beyond annotations: web and mobile have different references, platform='mobile' changes behavior, and widget-type topics return full syntax. It does not cover auth, rate limits, or pagination.

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 lists topic semantics and platform behavior. Every sentence adds actionable information, and the structure makes it easy for an agent to decide what topic to request.

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 documentation-retrieval tool with no output schema, the description is complete enough to invoke correctly. It explains topic values, platform behavior, and when to use the reference, leaving no critical gap for an agent preparing to write app or screen JSON.

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?

Although schema coverage is 100%, the description substantially enriches parameter meaning. It explains that topic='index' lists guides and widgets, enumerates guide categories, clarifies that any widget type name returns syntax, and explains the platform parameter's mobile/web distinction beyond the enum labels.

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: 'Read Fieldproxy's app-building reference.' It clearly distinguishes what the tool does from sibling tools by focusing on app-building guides and widget syntax, and it explains the main lookup modes (index, guides, widget types).

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 when-to-use guidance: read the relevant doc before writing any app or screen JSON, and it notes that docs are more reliable than memory. It also explains platform selection for mobile vs web. However, it does not explicitly state when not to use the tool or name alternative documentation 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=true and destructiveHint=false, so the safety profile is covered. The description adds useful context about what the content is and the ordering rule (read before changing data), but it does not disclose auth requirements, return format, or any behavioral edge cases. Adequate but modest beyond the annotations.

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

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

Two tight sentences, front-loaded with the core action and its scope. The 'read them before changing data' rule follows immediately. No filler, though it could be marginally tighter.

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

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

For a single-parameter, read-only tool with no output schema, the description conveys purpose, content, when to read, and the parameter's condition. It does not describe the shape of the returned instructions/playbooks, but the content is adequately characterized for an agent to invoke it correctly.

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

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

Schema coverage is 100%, so the `copilot` parameter is fully documented in the schema. The description adds meaning beyond the schema by clarifying the condition under which `copilot` applies ('where the workspace has more than one in-app copilot') and that it selects another copilot's instructions, which the schema states more tersely ('Default: this connection's.').

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 (Read) plus the exact resource (the workspace's AI-assistant instructions and playbooks) and even enumerates the content categories (house rules, action routing, confidentiality rules). An agent knows precisely what data it retrieves. It does not explicitly name a sibling to distinguish from (e.g., get_automation_docs, list_ai_memory), so it falls just short of 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?

Gives clear when-to-use guidance: 'Read them before changing data,' which tells the agent to consult this prior to mutations. It also explains the conditional use of the `copilot` parameter for multi-copilot workspaces. No exclusions or named alternatives are provided, so 4 rather than 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=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds value beyond that by disclosing the returned fields and concrete status values (active, error, expired), which matters because no output schema exists.

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

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

A single terse fragment with no wasted words, and the key resource and payload are front-loaded. It reads as an incomplete sentence rather than a polished definition, which costs a 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?

For a parameterless read-only tool with annotations covering the safety profile, the description supplies the essential remaining information: what the response contains and what status values mean. Only minor gaps (freshness, auth context) remain.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4; there is nothing for the description to disambiguate.

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

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

The description names the resource precisely (the workspace's accounting/business integrations) and enumerates what it reports: status, connected account, last error. It lacks an explicit verb, but no sibling tool covers integrations, so an agent can identify it unambiguously.

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 call this versus alternatives, no prerequisites, and no mention of related tools such as list_ai_connections. The agent must infer the use case purely from the noun phrase.

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, destructiveHint=false and closed-world, so the safety profile is covered. The description adds the notable behavioral fact 'rendered directly', telling the agent this returns a rendered chart rather than queryable records — valuable since there is no output schema. It does not cover chart size, format details, or empty-result 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 tight sentences with zero filler. The chart type and scope lead, followed by the parameter contract and usage hint in order of importance.

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

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

For a one-parameter, read-only chart tool with annotations covering safety, the description supplies the parameter contract and output nature, which is what an agent needs to invoke it. Minor gaps remain around chart format/dimensions and behavior when there are no open jobs.

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

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

Schema description coverage is 0% and the schema declares no enum, so the description does the real work: it enumerates the four accepted `by` values and states the default ('status'). That fully compensates for the schema gap for a single optional parameter.

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

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

States a specific verb ('Bar chart of') plus resource ('OPEN jobs') and the dimension being varied, so an agent can distinguish it from data-returning siblings like technician_jobs or revenue_by_month. The scope qualifier 'OPEN' is a meaningful constraint stated up front.

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 quick visual breakdowns' implies a context but names no alternative and gives no when-not guidance, even though several siblings (activity_summary, ops_report) could plausibly serve similar reporting needs. Usage is implied rather than routed.

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, openWorldHint=false, and destructiveHint=false, so the safety profile is clear. The description adds that each rule includes firing frequency, a useful behavioral detail about the result shape. It does not contradict annotations, but it provides little beyond that single data-point; no mention of pagination, ordering, or workspace 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?

Very short and largely front-loaded, but the trailing '— administrators.' reads as an afterthought and is syntactically unclear. Its ambiguity reduces the value of the brevity.

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

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

For a zero-parameter list tool with a solid annotation profile and no output schema, the description is minimally adequate. However, the ambiguous 'administrators' fragment leaves the audience/permission model unresolved, and there is no differentiation from closely named siblings, so agents must infer too much.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. The description adds no parameter information, but none is needed since there are no inputs to document.

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

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

The description names the resource ('activity alert rules') and adds a distinctive scope detail ('how often each has fired'), which helps distinguish it from a plain rule list. However, the verb is implicit — no explicit 'list' or 'retrieve' — and the trailing '— administrators.' is ambiguous, not clearly stating whether it restricts results or notes required permissions. Sibling tools like 'list_activity_alerts' exist, and the description does not differentiate between rules and alerts.

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 'list_activity_alerts' or 'workspace_activity'. The only usage hint is the fragment '— administrators.', which is too vague to tell an agent whether this tool is admin-restricted, admin-oriented, or simply returns admin-related data.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds ordering ('newest first') and scopes the alert types, which is useful, but omits return shape, pagination behavior, and any note on what 'unacknowledged' filtering implies.

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

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

A single tight sentence with the resource stated first, examples parenthetically embedded, and the ordering/audience appended. No wasted words and well 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?

There is no output schema, so the description carries more burden, yet it gives no return structure beyond ordering and leaves the unacknowledged_only parameter unexplained. Adequate for a read-only list tool but with clear gaps.

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

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

Schema coverage is only 50%: limit is documented ('Max 100, default 25') but unacknowledged_only has no description anywhere. The prose mentions alert categories but never explains either parameter, 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?

Clear verb+resource: it lists alerts raised by the workspace's activity alert rules, with concrete examples (bulk deletes, off-hours activity, sensitive field changes) and the ordering ('newest first'). It does not explicitly name or differentiate itself from close siblings like list_activity_alert_rules or list_alerts, so it falls short of a 5.

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

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

The trailing '— administrators' hints at the audience but gives no when-to-use guidance, no conditions for selecting this over list_alerts or list_activity_alert_rules, and no exclusions. The agent must infer usage entirely.

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

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

Annotations already declare read-only, non-destructive, non-open-world behavior. The description adds rich return context beyond annotations: key ownership/issuer, scopes, limits, last-used time, claim/active/expired/revoked statuses, and OAuth apps. It omits pagination and rate-limit 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 a single front-loaded sentence that packs many relevant returned attributes without filler. The heavy use of dashes makes it slightly dense to scan, but every clause contributes useful information.

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

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

With no output schema, the description carries the return-value burden and does a good job enumerating fields and statuses. It is complete enough for a read-only admin listing, though it could mention defaults, sorting, or pagination.

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

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

Schema description coverage is 100%, and both parameters (user_id and include_inactive) are already documented in the schema. The description adds no further parameter semantics, so the baseline of 3 applies.

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

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

Describes a specific resource—AI connections to the workspace—and enumerates what is returned, including MCP keys and OAuth connected apps. It does not name or differentiate itself from sibling tools like ai_activity_log or list_ai_memory, so it falls short of a 5.

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

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

No explicit when-to-use or when-not-to-use guidance is provided. The parenthetical 'administrators' hints at an admin audience, but there is no direction on when this tool should be chosen over 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 annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful scope information ('yours, and the workspace-wide ones every user's assistant follows'), but it does not disclose return format, pagination, or any other behavioral detail beyond what the 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?

It is a single sentence with no obvious repetition, so it is concise. However, the structure is cryptic and does not front-load a clear action, making it less effective than a straightforward lead sentence would be.

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

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

For a zero-parameter, read-only tool, the description gives enough context to understand that it returns personal and workspace-wide standing instructions. But it lacks any explicit statement of the operation or return shape, and there is no output schema to fill that gap.

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

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

The tool takes zero parameters, so there is no parameter semantics for the description to clarify. Schema coverage is effectively complete, and the baseline for a zero-parameter tool is a 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 names the resource (Command Center standing instructions) and distinguishes personal from workspace-wide memory, but it never states a verb such as 'list' or 'retrieve'. An agent can infer the tool's purpose, yet the phrasing is vague and does not differentiate it from sibling list/read 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 is provided on when to use this tool versus alternatives. The description only describes the content of the memory, not the situations that should trigger a call or the sibling tools that might be better choices.

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, destructiveHint=false and openWorldHint=false, so safety is covered structurally. The description adds useful domain context (alerts are re-evaluated every few minutes and notify on a condition), but says nothing about pagination, sorting, or result size.

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

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

A single, front-loaded sentence with zero filler, though the parenthetical definition of an alert could be trimmed since it is background rather than action-guiding information.

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

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

With no parameters, no output schema, and annotations carrying the safety profile, the description is nearly sufficient. The field list effectively substitutes for an output schema, though the lack of differentiation from the near-identical alert-listing siblings leaves a real routing gap.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline here is 4. The description correctly implies a full unfiltered listing by enumerating the returned 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?

Names a clear verb+resource (list alerts) and enumerates the fields it reports (id, name, active/paused, frequency, last check), so the agent knows exactly what comes back. However, it does not differentiate itself from the very similar siblings list_activity_alerts and list_activity_alert_rules, which an agent could easily confuse with this tool.

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

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

The description gives no when-to-use guidance, no prerequisites, and no mention of the closely related sibling tools. The parenthetical explains what an alert is but not when this listing should be chosen over the 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds useful behavioral context by specifying sort order ('newest first') and the fields returned, though it omits pagination limits, default behavior, and filtering semantics.

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

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

The description is very short and avoids repetition, but it is a sentence fragment that front-loads a resource phrase rather than an action. It is appropriately sized for a list tool but under-specified in 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?

With no output schema, the description does list returned fields, which is helpful. However, it is incomplete for a 5-parameter tool with 40% schema coverage and no required parameters: it omits input parameter explanations, usage context, and any limitations such as default/max limits.

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 40%, so the description must compensate for undocumented parameters like agent_id, direction, and follow_up_only. Instead, the description lists output fields (agent, direction, numbers, when, etc.) and never explains what any input parameter does or how filtering works.

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

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

The description names the resource ('Voice-agent calls') and lists returned fields, so an agent can infer this is a list operation. However, it uses a noun phrase rather than a verb and does not differentiate from the sibling get_call, leaving the action ambiguous.

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

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

The description provides no when-to-use guidance, no alternatives, and no exclusions. It only states ordering ('newest first') and output fields, so an agent must guess when this tool is preferred over get_call or other call-related siblings.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The phrase 'you can see' adds a useful permission-scoping hint, and the field list describes output shape, but pagination, ordering, and result limits are unstated.

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

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

A single front-loaded sentence with zero filler; the most useful information (what the rows contain) comes first.

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 parameters, no output schema, and annotations covering read-only safety, the description is nearly sufficient — the enumerated return fields stand in for a missing output schema. Only ordering/pagination behavior is left unaddressed.

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

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

The tool takes zero parameters, so the baseline of 4 applies. The description correctly implies no filtering input is available, keeping expectations aligned with the empty schema.

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

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

The description names the resource (Command Center dashboards) and enumerates the returned fields (name, slug, published, tile count), so an agent knows exactly what this tool yields. It does not, however, differentiate itself from the sibling view_dashboard, which is the main gap.

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

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

There is no statement of when to call this versus alternatives such as view_dashboard or list_saved_views. The agent must infer from the name alone that this is the enumeration entry point before drilling into a single dashboard.

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, destructiveHint=false, openWorldHint=false, so the safety profile is covered and the description adds real context beyond it: the admin-only restriction, the implicit retention window ('can still be restored'), and the shape of the returned row preview. It does not mention pagination limits beyond the schema, which keeps it short of a 5.

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

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

A single dense sentence that front-loads the resource, the recovery constraint, and the access level, then lists return fields. No wasted words 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 no output schema, the description usefully enumerates the return fields (table, id, when/by whom, preview), and the admin note covers the main authorization concern for a 2-param read-only list. The one gap is that the optional 'table' filter parameter is never explained, leaving the agent unsure whether it can scope the listing.

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

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

Schema coverage is 50%: 'limit' is fully documented in the schema (max 100, default 25), but the 'table' parameter has no description anywhere. The description only mentions 'table' as a returned field, not as a filter, so it does not compensate for the documented gap in parameter semantics.

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

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

Names a specific resource (recently deleted, still-restorable records) and enumerates the fields returned (table, id, timestamp, actor, row preview), so the agent knows exactly what this lists. It does not need sibling differentiation since no other tool in the sibling list covers deleted-record recovery, but it also doesn't explicitly name a neighboring alternative.

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

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

The phrase 'that can still be restored' implies the use case (recovery of soft-deleted rows) and '(admins)' signals a permission gate, which is useful implied guidance. However, there is no explicit when-to-use/when-not, no statement of what to do for already-purged records, and no named alternative (e.g. restore vs. record_history).

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, destructiveHint=false and closed-world scope, so safety is covered. The description adds behavior the annotations do not: results are ranked most-common-first and each value carries a row count, which tells the agent how to interpret and rely on ordering.

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

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

Two sentences, zero padding: the first states the operation and its discovery use case, the second states the return shape. Both are front-loaded with the essential noun (distinct values in a column) before the supporting detail.

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

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

For a read-only, three-parameter tool with full schema coverage and no output schema, the description supplies the missing return-shape context (values plus counts, sorted). Only minor gaps remain, such as how truncation from limit behaves, but nothing critical for correct invocation 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 description coverage is 100%, including the limit default of 50 and the table/column meanings, so the schema carries the parameter burden and a 3 is the baseline. The description adds only the 'most common first' ordering nuance and no per-parameter detail 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 states a specific verb and resource ('List the distinct values in a column') and adds the purpose ('for enum/value discovery — e.g. what statuses or service types exist'), which implicitly separates it from describe_schema and run_sql. It never names a sibling tool explicitly, so an agent must infer the boundary rather than being routed to it.

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 a clear when-to-use context: discovering enums or value sets such as statuses or service types, including what the output looks like for that purpose. There are no explicit exclusions or named alternatives, so the agent is not told when to prefer run_sql or describe_schema 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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds one useful nugget — that each template carries its argument specification — which hints at the shape of the payload, but says nothing about pagination, filtering or volume.

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

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

A single compact sentence with no filler that front-loads the resource ('the workspace's PDF / Word document templates'). It could lead with a verb for faster scanning, but nothing is wasted.

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

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

For a parameterless, read-only enumeration with no output schema, the description conveys both what is listed and that each entry includes its argument spec. The main omission is any routing hint toward generate_document, which would have closed the loop on why an agent would fetch templates.

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

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

The tool takes zero parameters, so the schema baseline of 4 applies. The description's mention that the listing exposes 'the arguments each takes' gives a slight hint about the returned data structure, which is a small bonus beyond the empty 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 phrase names a specific resource — the workspace's PDF/Word document templates, exemplified as quotes, job reports and invoices — which separates it from list_estimate_templates, list_proposal_templates and list_email_templates. It lacks an explicit verb ('lists'), so the agent must infer the action, but the resource and scope are unambiguous.

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

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

No guidance on when to call this versus the many sibling template/listing tools, and no mention that the results presumably feed generate_document. The agent is left to infer usage entirely from the noun phrase.

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, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context — result ordering (soonest first) and what the filter flag returns — but says nothing about result size, pagination, or what happens with no pending reminders.

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

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

One sentence, front-loaded with the resource and scope, with the parameter explanation folded into a parenthetical. Nothing is wasted or repeated from structured fields.

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

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

For a simple read-only list tool with annotations and no output schema, the description covers what the list is, its ordering, and its one optional filter. Only result volume/pagination is unaddressed, which is a minor gap.

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

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

Schema description coverage is 0%, so the description carries the burden for the single parameter. 'due_only for the ones that have come round' conveys the filter intent, but 'come round' is colloquial and leaves it ambiguous whether it means due date passed, due today, or overdue only.

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 resource (pending follow-up reminders on email threads) with an ordering guarantee (soonest first), which clearly separates it from siblings like quotes_to_follow_up or read_email_thread. It does not explicitly name an alternative, but the resource is concrete enough to be unambiguous.

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

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

There is no when-to-use or when-not-to-use guidance, and no alternative tool is named. An agent must infer from the resource noun alone whether this or quotes_to_follow_up / search_inbox is the right call.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds the useful detail that it returns both personal and shared templates with placeholder names, but says nothing about pagination, ownership filtering, or how search behaves.

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

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

One compact sentence front-loading the resource and scope, followed by a short chaining hint. No filler, though the field enumeration is slightly dense.

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

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

No output schema exists, and the description compensates by naming the returned fields and the placeholder concept. For a simple read-only list tool, this is nearly complete, with the only gap being the undocumented search parameter.

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?

Only 1 parameter with 0% schema description coverage; the description never mentions the search parameter or its semantics. It does compensate somewhat by explaining the returned fields (id, name, subject, placeholders), but the input side is undocumented.

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

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

States a clear verb+resource: lists saved and shared email templates, and enumerates the returned fields. This distinguishes it from sibling list_* tools by scoping it to email templates, though it doesn't explicitly name a sibling it differs from.

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 names the downstream tool (draft_email) and the inputs it consumes (template + template_vars), which is exactly the when-to-use guidance an agent needs to chain these 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?

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds workspace scoping and the returned field set, but says nothing about volume, pagination, or whether archived/unpublished templates appear.

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

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

A single front-loaded sentence with no filler; the list of returned fields is compact and earns its 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 no output schema, the description compensates by naming the fields returned and the workspace scope, which is enough for a parameterless list tool. Minor gap: no mention of ordering, pagination, or whether only published versions are returned.

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

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

Zero parameters, so per the baseline the schema carries no semantics to clarify. The description still usefully frames the output fields (id, name, trade, published version), going slightly beyond the no-param baseline.

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

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

States a specific resource (workspace estimate templates) and enumerates the returned fields, which distinguishes it from the many sibling list_*_templates tools. It does not name those siblings explicitly, but the resource noun is unambiguous.

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

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

The parenthetical hint that published templates 'can price a job from measurements' faintly implies a downstream use, but there is no explicit when-to-use, prerequisite, or routing to alternatives such as list_document_templates or list_proposal_templates.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful context by disclosing the shape of what is returned (name, kind, schedule, last run), but says nothing about pagination, ordering, or whether insights are scoped to the workspace only.

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

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

A single front-loaded sentence with a colon-delimited field list – every element earns its place and there is no filler. It is a fragment rather than a complete sentence, but that is idiomatic for a schema description and costs little.

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

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

With no output schema, the description compensates by listing the fields each insight carries, and with zero parameters and read-only annotations there is little else an agent needs. The main remaining gap is how this list relates to the run/get execution tools of the same family.

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

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

The tool takes zero parameters, which is the baseline-4 case per the rubric; there is no parameter semantics to clarify or omit, and the description sensibly spends its space on return content instead.

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

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

The description names the resource (the workspace's AI insights) and enumerates the payload fields (name, kind, schedule, last run), with concrete examples ('at-risk jobs, next actions') that tell an agent what content to expect. It is a noun phrase rather than an explicit verb, and it never names the closely-related siblings run_insight or get_insight_result, so sibling differentiation is left 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?

There is no statement of when to call this versus run_insight (which likely executes an insight) or get_insight_result (which likely fetches a single result). An agent must infer usage purely from the name and the word 'list'.

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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the scoping trait that only proposals already sent to customers are returned and enumerates the possible status values, which is useful context beyond the annotations, but says nothing about pagination or result ordering.

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

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

A single dense sentence with the scope filter ('already sent to customers') front-loaded ahead of the field list. No filler, though the fragment style reads more like a schema excerpt than a description.

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

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

For a simple read-only list tool with three optional parameters and no output schema, this is minimally adequate. It omits return-format/pagination details and any indication of how the customer and limit filters behave, which the low schema coverage does not fill in.

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

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

Schema description coverage is only 33%, so the description must compensate and does partially: the status enumeration (sent/viewed/accepted/declined/expired/superseded) clarifies the values the status filter accepts. The limit and customer parameters, including the max-50 constraint, are not addressed 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 names the resource (proposals already sent to customers) and enumerates the fields returned, so an agent knows roughly what comes back. However, it never states an explicit verb and only weakly scopes the tool, leaving it hard to distinguish from siblings like list_proposal_templates, preview_proposal, or find_quotes.

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

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

There is no guidance on when to use this tool versus alternatives, despite several closely-related siblings (list_proposal_templates, preview_proposal, find_quotes). The 'already sent' phrasing implies a filter, but no explicit when-to-use or when-not-to-use condition is given.

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, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds the useful detail that each template exposes its arguments and option tiers (implying a nested return shape), but does not describe scope (workspace-wide), pagination, ordering, or whether inactive templates are included.

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

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

A single compact sentence that front-loads the resource and then enumerates the salient fields. Nothing is wasted, though it reads as a noun phrase rather than an imperative and lacks a terminating verb describing the action.

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

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

For a zero-parameter read-only list tool with full annotation coverage, the description is close to sufficient but omits ordering and scope (whether the list spans the whole workspace or a default subset). It also fails to help disambiguate from template-list siblings, which an agent choosing among many list_* tools 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?

The tool takes zero parameters, so per the rubric the baseline is 4. The schema is empty (100% coverage trivially), and the description correctly adds no parameter detail because there are none 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?

States a clear verb implicit (list/retrieve) and resource (the workspace's proposal templates), and enumerates the fields returned (id, title, description, arguments with defaults, option tiers). It is distinguishable from siblings like list_proposals or list_document_templates by naming 'proposal templates' specifically, though the sibling list has several near-neighbors (list_estimate_templates, list_document_templates) that it does not explicitly differentiate from.

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

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

No when-to-use guidance, no mention of alternatives, no prerequisites or exclusions. The description only names what is returned, leaving the agent to infer that this is the tool for discovering proposal templates without any routing cues relative to list_document_templates or list_estimate_templates.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered structurally. The description adds genuinely useful behavioral context beyond that: what the returned entries contain (URL, column, kind) and that the listing is scoped to a single record. It does not mention pagination or limits, which would have pushed this higher.

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, zero filler. The purpose and the example land first, and the routing hints to view_images/read_file follow, so the most important information is front-loaded.

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

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

With no output schema, the description correctly takes on the burden of describing the return fields (URL, column, kind) and the downstream handoff tools. The remaining gap is parameter-level detail for table and record_id, which is thin across both schema and description.

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

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

Schema description coverage is only 33% — only id_column carries a description (a terse 'Default id'), and table/record_id have none. The description says files are 'stored on one record', which loosely implies record_id, but it never explains the table/id_column pairing or the accepted id types, 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?

States a specific verb and resource ('List the files ... stored on one record') and immediately scopes it with examples (before/after photos, PDFs, signatures). It also enumerates the return shape (URL, column, kind), so an agent can distinguish it from siblings like read_file and view_images without reading any schema.

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

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

Clear context for when to reach for this tool and explicit routing to the downstream alternatives: photos go to view_images, documents go to read_file. It does not state a when-not condition (e.g. what to do for records with no files, or how it differs from open_record's file listing), so it stops short of full alternative coverage.

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 it as a safe read (readOnlyHint=true, destructiveHint=false), so the bar is lower; the description adds genuine value by disclosing the shape of the returned data — filter parameters as URL-form strings and AI filter boxes' saved prompts and results — which is otherwise undocumented since no output schema exists.

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

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

Two compact sentences, front-loaded with the resource and its ordering rule. The second sentence is dense and uses field names (params, ai_filters) that could be mistaken for inputs, but nothing is wasted.

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

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

With no output schema the description does well to sketch the return structure, and annotations cover the safety profile. However, it never explains what app_id/view_id values are acceptable, nor mentions pagination or volume, leaving meaningful gaps for a lookup tool with 0% parameter documentation.

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

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

Schema description coverage is 0%: neither app_id nor view_id is documented anywhere. The description alludes to 'one app view' and mentions 'params'/'ai_filters', but those terms refer to returned fields, not the two required inputs, so an agent still has no guidance on what identifiers to supply.

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

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

The description names a specific resource — saved filter presets attached to a single app view — and clarifies the ordering (own presets first, then shared ones). It is clear enough for an agent, though the verb (list/retrieve) is only implied rather than stated, and it makes no attempt to differentiate itself from the many other list_* 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?

There is no statement of when to use this tool versus the numerous other listing tools, no prerequisites (e.g. needing a valid app/view), and no exclusions. The only guidance is the implicit ordering of results, which is descriptive rather than actionable.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds a genuine behavioral nuance by noting cadence is expressed in local time, but says nothing about ordering, volume, or pagination of the returned list.

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

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

A single non-wasteful sentence that front-loads the resource and then the payload. It reads slightly like a fragment rather than a sentence, but nothing extraneous is present.

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 parameters and no output schema, the description is the only place the return shape is documented, and it does list the returned fields. It stops short of describing ordering or result limits, which keeps it from a 5.

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

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

The tool takes no parameters, so the baseline is 4. The description's field enumeration is effectively its substitute for parameter documentation and adds real value since no output schema exists.

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 the resource clearly (scheduled reports) and enumerates what each entry contains (id, name, status, cadence, next/last run, last error), which lets an agent distinguish it from neighbours like list_email_followups or list_insights. The verb is only implied via the tool name, but the content is specific enough to identify the 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?

There is no guidance on when to call this versus related listing tools, and no mention of prerequisites or typical context of use. The zero-argument nature makes it low-risk, but the definition gives the agent nothing to route on.

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, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: it discloses the exact shape of the payload and that geometry is simplified to ~10 m and 5 decimal places, which tells the agent the outlines are lossy and unsuitable for precision work.

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

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

Two tight sentences, with the resource and return fields front-loaded and the optional flag behavior second. Every clause carries information; nothing is padding.

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

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

With no output schema, the description usefully enumerates the returned columns and the geometry flag's effect, so an agent can plan around the result. Minor gaps remain: no default value for include_geometry and no pagination/volume expectations for workspaces with many zones.

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

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

Schema coverage is only 50% — zone_id is documented as 'Only this zone' but include_geometry has no schema description. The description compensates by explaining what include_geometry actually does (adds each zone's outline as GeoJSON, simplified). Both parameters now have meaning, though no default behavior for include_geometry is stated.

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 (list) and resource (the workspace's service zones) and enumerates the returned fields, so an agent knows exactly what it gets back. It implicitly distinguishes itself from the location-scoped sibling zones_for_location by calling out the workspace-wide scope, but never names that sibling explicitly.

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

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

Usage is implied rather than stated: the include_geometry sentence tells you when to set that flag, but there is no guidance on when to prefer this tool over zones_for_location or other zone-related siblings, and no exclusions. Adequate but leaves routing to inference.

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

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

Annotations already declare readOnlyHint/openWorldHint=false/destructiveHint=false, but the description resolves the one real ambiguity for a save-style call by stating 'It changes no workspace data,' and it discloses automatic capture of tools called since the previous turn plus truncation behavior. It does not cover failure modes or auth, but the annotation bar is met.

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?

Front-loaded with the purpose in the first clause, then usage, parameter guidance, and a closing safety note. Every sentence carries information, though the character limits restate what the schema already documents.

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 append-only logging side effect with no output schema, the description covers what to pass, when to call it, and what it does not affect. Only return/error behavior on a failed save is left unstated, which is minor here.

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, and the description adds meaning beyond it: user_message should be what the user 'said, as they wrote it' and reply_summary is 'one to three sentences on what you answered or did'. It also notes that tool calls are captured automatically, which is not a parameter at all.

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: saving this conversation turn to the user's Command Center history in Fieldproxy, so it can be found in the app later. This is clearly separable from siblings like record_history or ai_activity_log, which concern record changes and AI usage rather than conversation turns.

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

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

Gives explicit timing and frequency guidance: 'Call it ONCE per turn, after answering.' That is strong context for when to invoke, though it names no exclusions or alternatives (none of the siblings are close substitutes).

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

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

The annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only the matchable fields; it does not disclose matching behavior (exact vs partial), result limits, or pagination, which are the traits an agent would still need.

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

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

Two short sentences, zero waste, with the primary purpose front-loaded and the routing hint following. Every clause earns its place.

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

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

For a 1-parameter, read-only lookup with annotations covering the safety profile and no output schema to explain, the description is nearly sufficient. The only meaningful gap is the lack of guidance on result volume or behavior versus the find_customers sibling.

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

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

Schema description coverage is 0% for the single 'search' parameter, so the description carries the burden. It does add real meaning by telling the agent the query matches name, company, or email, which is more than the bare schema provides, but it omits match semantics (substring, fuzzy, case sensitivity).

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 (Search) and resource (customers) and names the fields it matches on (name, company, email), so the agent knows exactly what it does. It does not distinguish itself from the very similar sibling find_customers, so it falls short of full sibling 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?

"Use this instead of raw SQL for customer lookups" gives one explicit alternative and a reason to prefer this tool, which is useful routing guidance. However, it says nothing about when to choose this over the near-identical find_customers or segment_customers siblings, leaving the most important disambiguation to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that results include status, blocking item, latest update, proposed next move, and next check time, plus an implicit scoping to 'the user's' tasks, but says nothing about default ownership, filtering behavior, or ordering/limits.

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

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

A single front-loaded sentence with no wasted framing. The trailing five-item enumeration of returned fields is somewhat list-heavy but each item is informative, so it stays reasonably tight.

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

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

With no output schema, the description usefully enumerates the returned fields, which is the right move. However, for a two-parameter tool it leaves both parameters unexplained and provides no differentiation from closely named siblings, so it is only minimally sufficient.

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

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

Schema description coverage is 0% for both parameters, so the description carries the full burden of explaining them. It never mentions owner_userid or include_closed (whose number type is non-obvious for what reads like a boolean toggle), only loosely implying owner scoping via 'the user's'.

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

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

The description names the resource ('the user's personal-agent tasks') and enumerates the fields it exposes, so the domain is clear, but it never states an action verb (list vs. detail) and does nothing to distinguish itself from siblings like agent_task_detail or agent_updates. An agent can guess it is a summarizing list, but must infer that from context rather than from the text.

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 when-to-use guidance, no condition that selects this tool over agent_task_detail, agent_updates, or overdue_tasks, and no prerequisites mentioned. The description is purely descriptive of content, leaving routing entirely to the agent.

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