Fieldproxy

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds that results are aggregated over a trailing window and signals an admin audience, but does not state auth requirements, rate limits, or whether the trail depth figure is configurable.

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 substance (what is counted) before the trailing-scope qualifier. The parenthetical '(administrators)' is slightly awkwardly placed but the sentence carries 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?

With no output schema, the description must carry the return shape, and it does list the aggregates returned plus the trail-depth metric. It still leaves unclear the response format, whether counts are grouped/ranked, and the admin-permission consequence of calling it as a non-admin.

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 'days' parameter documents 'Default 30; 0 = all time'. The description only restates the window ('last N days'), adding no syntax or edge-case meaning beyond the schema, 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?

The description names the resource and the concrete outputs (busiest tables, sources, people) plus the audit-trail depth, which is more specific than a tautology. It is a noun phrase rather than a verb+resource, and it never contrasts itself with near neighbours like workspace_activity, ai_activity_log or record_history, so an agent cannot route on the description 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, no when-not-to-use, and no named alternative among the many activity/log siblings. The only usage cue is the parenthetical '(administrators)', which hints at a permission gate but is not framed as guidance.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds ordering ('newest first'), the admin restriction, and an enumeration of what each entry contains (key, owner, tool, success/failure with error, duration, argument summary). It does not discuss pagination or default time windows, which are left to 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?

A single dense sentence that front-loads the resource and scope before enumerating returned fields. Nothing is wasted, though the long middle clause listing seven fields is harder to parse than a short bulleted form 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?

There is no output schema, and the description does a good job compensating by enumerating the returned fields, so an agent knows what to expect. The gap is on the input side: with seven mostly undocumented filter parameters (tool, key_id, status, user_id, since/until), the definition leaves the agent guessing how to narrow an admin audit query.

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% and the description mentions no filter parameters at all - it never explains that tool, key_id, status, user_id, since or until narrow the log, nor what limit does. The 'tool' mention in the description refers to the returned field, not the filter, so the description does not compensate for the coverage gap.

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

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

The description states a concrete resource and scope: an audit feed of what AI connections did in this workspace, newest first, restricted to administrators. It is clearly distinct from list_ai_connections (which enumerates connections rather than their actions), though it never names a sibling to route the agent 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?

The parenthetical '(administrators)' tells the agent the audience/permission requirement, which is useful scoping context. However, it gives no when-to-use versus alternatives such as ai_usage_summary, activity_summary, or workspace_activity, which sit in the same audit/usage space.

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 openWorldHint=false, so the safety profile is covered. The description adds the administrator-only constraint and the aggregation granularity, but says nothing about result size, pagination, or whether the window is inclusive — moderate added value against a lower bar.

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 the resource and breakdown front-loaded and no filler. Slightly dense in its trailing clause list, but every clause carries information.

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

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

For a one-parameter, low-complexity tool with no output schema, the description usefully characterizes the return shape (calls and errors broken down by key, person, and tool) and the admin restriction. Only the ambiguity versus sibling AI/activity tools keeps it short of full completeness.

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

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

Schema description coverage is 100% and the single 'days' parameter documents its range (1–90) and default (7) in the schema itself. The description only restates N as a day count and adds no format or edge-case detail beyond 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 a specific resource (AI connection use), a time scope (last N days), and the exact breakdown dimensions (calls and errors per key, per person, per tool), so an agent knows precisely what it returns. It does not, however, distinguish itself from close siblings like ai_activity_log or activity_summary, leaving the agent to guess which one 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 parenthetical '(administrators)' signals an audience/permission prerequisite, which is useful routing information. But there is no explicit when-to-use guidance and no mention of alternatives such as ai_activity_log for raw events or workspace_usage for aggregate usage, so selection between the AI/usage siblings remains implied at best.

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 openWorldHint=false, so the safety profile is covered. The description adds useful content about what is aggregated (the four funnel stages) but says nothing about permissions, rate limits, or whether the numbers are scoped to the caller's workspace.

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: the metric list first, the usage trigger second, with no filler. Everything present earns its place, though the second sentence is fragmentary rather than fully structured.

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

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

No output schema exists, so the description must convey what comes back — and it does by naming the four funnel metrics returned. The absence of any note on scoping or empty-result behavior keeps it from being fully complete.

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

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

Schema description coverage is 100%, and both parameters carry their format ('YYYY-MM-DD (inclusive)') in the schema. The description only restates 'over a date range', adding no boundary, timezone, or default behavior beyond what the schema supplies. 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 a specific verb-and-resource computation ('Quote-to-close funnel over a date range') and enumerates the exact metrics computed: quotes created, sent/pending, accepted, and accepted rate. It is clearly distinct from quote-listing siblings like find_quotes or quotes_to_follow_up, though it does not name those alternatives.

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

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

It gives explicit trigger phrases in quotes — 'conversion rate' / 'pipeline funnel' — which tells the agent when this tool is the right one. It stops short of stating when not to use it or what sibling to pick for raw quote retrieval.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered by structured data. The description adds the useful semantic scope (only unpaid invoices), but says nothing about aging buckets, sorting, or result shape. Adequate but not rich given the annotations already carry the behavioral load.

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 plus one trigger-phrase clause; the core purpose is front-loaded and every word 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 parameterless tool with no output schema, the description adequately conveys what comes back (unpaid invoices and days past due). It leaves minor gaps around the aging-bucket structure and its relationship to the duplicate get_ar_aging 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?

The tool takes zero parameters, so per the baseline a 4 applies. There is no parameter surface for the description to clarify or omit.

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 (accounts-receivable aging) and the return content (unpaid invoices with days past due), so the agent knows exactly what it yields. However it never distinguishes itself from the near-identical sibling get_ar_aging, nor from find_invoices, which the description's 'overdue invoices' phrasing overlaps 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?

Provides explicit trigger phrases ('AR aging', 'overdue invoices', 'who owes us'), which gives clear context for when to reach for it. It stops short of naming alternatives or exclusions, so there is no guidance on when to prefer get_ar_aging or find_invoices 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?

With readOnlyHint already covering the safety profile, the description adds real behavioral substance: it enumerates what counts as the promise being 'fulfilled' (invoice on the job, follow-up job created, payment received, communication sent) and states it returns ONLY unfulfilled ones. It omits any note on cost/performance or how the phrase matching is scoped, but the fulfillment logic is a meaningful disclosure 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 dense but purposeful sentences, front-loaded with what the tool lists and followed by the matching logic. Nothing is padded, though the parenthetical enumeration is long enough to strain single-pass readability.

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

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

For a no-output-schema analytical tool the description explains the selection logic adequately, but it never documents the days_back parameter or the default lookback when it is omitted, which an agent needs 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 0% and the single parameter days_back is never mentioned in the description, so its meaning (lookback window? since date?) must be guessed. The description discusses time-flavored phrases like 'next week' but does not connect them to days_back, leaving the only parameter undocumented in both places.

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

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

The description states a specific verb+resource (lists tech notes containing promise phrases) and a precise filter (only never-fulfilled promises), which is far more than a restatement of the name 'broken_promises'. It conceptually separates itself from follow-up siblings like overdue_tasks and quotes_to_follow_up by describing the fulfillment cross-reference, though it never explicitly names an 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 description explains the output but gives no when-to-use guidance: no conditions, no prerequisites, and no mention of when to prefer this over quotes_to_follow_up, overdue_tasks, or list_email_followups. The agent must infer the trigger 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?

With readOnlyHint=true and openWorldHint=false already declared via annotations, the safety profile is covered and the description instead adds genuinely new behavioral detail: the tool scans four distinct sources, and the return value includes the exact flagging sentence plus surrounding context. What is still missing is how results are ordered/limited and whether keyword overrides affect the scan.

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 scan scope front-loaded and the return behavior second. No filler or restatement of the tool name. Slightly overstuffed in the middle clause but every element 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 correctly takes on the burden of explaining what comes back (flagged customer, flagging sentence, full context), which is its strongest contribution. However, both input parameters are left completely undocumented despite 0% schema coverage, leaving the agent guessing at invocation semantics.

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, so the definition must compensate here and does not. It does not say whether min_rating is a threshold that suppresses flags, how churn_keywords is formatted (comma-separated list?), whether it supplements or replaces built-in signals, or what the defaults are when both are omitted.

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

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

The description names a specific verb (scans) and enumerates the exact data sources inspected (satisfaction ratings, written feedback, job-level and customer-level notes) for a clearly stated goal: churn risk signals. That is far more specific than the bare name 'churn_risk'. It stops short of distinguishing itself from the closely related sibling customer_churn_feedback_flags, which appears to cover overlapping ground.

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. The presence of the sibling customer_churn_feedback_flags makes the omission material: an agent cannot tell whether this tool supersedes, complements, or duplicates it. Usage is only inferable from the stated purpose.

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 and openWorldHint=false, so safety is covered. The description adds a real behavioral prerequisite (history must be enabled on the table) and describes the comparison semantics (earlier time vs now, or two times). It doesn't cover what happens if history is off (error? empty result?), which would be valuable.

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 capability, the example use case, and the prerequisite front-loaded. 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?

Adequate for a 4-param read-only tool with no output schema: it covers purpose, timing semantics, and the history requirement. It leaves gaps on error behavior when history is off and on result shape (e.g., per-field diffs), which for a comparison tool an agent might want to know.

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%; 'table' and 'record_id' have no schema descriptions, but the description implies their meaning (a record in a table). 'from' and 'to' semantics — the default-now behavior for 'to' and the 'two times' mode — are clarified in the prose, which is genuine added value beyond the schema.

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

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

States a specific verb (differ/compare) and resource (a record's fields over time), plus a concrete example question ('what changed on job 42 since Monday?'). Easily distinguished from siblings like record_history (raw history) and open_record (current state).

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

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

Gives implied usage through the example question and an explicit prerequisite ('history must be switched on'). However, it doesn't name record_history as the alternative for viewing the raw change log, nor clarify when to prefer compare_record over 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 and openWorldHint=false, so the safety profile is covered. The description usefully adds the result-selection rule (exact triggering sentence, falling back to rating evidence), but says nothing about result volume, pagination, or how min_rating gates the two detection paths.

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, and the output behavior is stated up front. Slightly dense with the parenthetical, but 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 responsibly explains the return shape, and annotations cover safety. However, an agent still cannot confidently supply min_rating or know how this differs from churn_risk, leaving real gaps for a one-required-parameter detection tool.

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

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

The single parameter min_rating has 0% schema description coverage and the description never explains it: no scale or units (stars vs. percent), no direction (minimum rating to include vs. cutoff below which a flag fires), and no indication of whether it also gates the written-feedback sentence matching.

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 (finds) and resource (customers with churn-risk feedback) plus the precise return payload (triggering sentence or rating evidence). An agent can tell what it produces, but the description never distinguishes it from the sibling churn_risk tool, which sounds like overlapping territory.

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 or when-not-to-use guidance is given. With both 'churn_risk' and 'segment_customers' in the sibling list, the agent has no signal for choosing this tool over them; usage is only inferable from the name and the result description.

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=true), so the description only needs to add operational context. It does: it discloses permission scoping ("tables you may read") and the exact shape of results in both modes, which matters since there is no output schema. No auth or rate-limit caveats are mentioned.

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

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

Three front-loaded sentences that each carry unique information: purpose, default behavior, parameterized behavior, and the call-ordering rule. No filler or repetition of the title.

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

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

A single optional parameter, no output schema, and the description covers purpose, both return shapes, permissions scope, and when to invoke it. Nothing an agent needs to call this 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 100%, so baseline is 3, but the description adds real meaning beyond the schema: omitting `tables` yields a one-line summary of every readable table, while supplying it yields full column lists, types, foreign keys and notes. That mode-switching behavior is not evident from the schema alone.

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

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

States a specific verb and resource ("Describe the workspace's data tables you may read") and immediately distinguishes itself from the SQL-execution sibling via "Call this before writing SQL." The two output modes are spelled out, so an agent knows exactly what the tool yields in each case.

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

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

"Call this before writing SQL" gives a clear when-to-use condition that maps onto the run_sql/dispatch_query siblings. It stops short of naming an alternative explicitly or stating when not to call it (e.g. for non-SQL tasks), so it is strong context rather than a full routing rule.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavior beyond annotations: both modes return booked minutes and job count per technician, and availability mode returns results lightest first. It does not cover permissions, rate limits, or exact return shape, but the added mode-specific behavior is meaningful.

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 short, front-loaded, and wastes no words. It leads with the core purpose, then gives mode details, then closes with the explicit alternative, all in three sentences.

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, but the description still explains the returned metrics for each mode and the ordering behavior. For a read-only, two-mode capacity query, this is nearly complete; it could be improved by explicitly distinguishing itself from sibling tools such as tech_workload.

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 each parameter, including which date fields are required for each mode. The description reinforces the mode-to-parameter mapping, but it does not add format, validation, or semantic detail beyond what the schema already provides.

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

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

The description states a specific resource and scope ('Per-technician capacity in ONE call') and then distinguishes the two modes by name, required date inputs, and output metrics. An agent can immediately tell this is a capacity/workload reporting tool rather than a generic query 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?

It gives clear mode-selection guidance: availability uses date, workload uses from_date/to_date. It also names an alternative workflow ('instead of looping find_jobs per tech'), but it does not explicitly address when to choose this over close siblings like tech_workload or get_tech_performance.

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 and openWorldHint, so the safety profile is covered. The description adds real behavioral context beyond that: traffic is excluded (so results are static estimates), travel is one-way and not round-trip, and out-of-coverage places are refused with the region named rather than returning a fallback. That refusal behavior is decision-relevant and not derivable from 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?

Four short sentences, front-loaded with what is returned and its units before input format and caveats. No filler, padding, or redundancy; each sentence carries a distinct fact.

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 must convey return values, and it does: minutes and km, one-way. Input shape, traffic caveat, and coverage-failure behavior are all stated. A minor gap is the absence of any resolution or latency expectations for address geocoding failures, but for a simple two-parameter read 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 description coverage is 100%, with both 'from' and 'to' documented as address-or-coordinates and identical to the description's phrasing. The description adds no syntax, format, or defaulting detail beyond 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 states a specific verb+resource with units: road drive time (minutes) and distance (km), one-way, between two places. This is far more precise than a name restatement. It does not, however, name or contrast with routing siblings such as plan_day_routes, technician_route, or nearest_technicians, 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 when-to-use guidance, no prerequisites, and no alternative tools named. An agent must infer from the name alone that this is the single-pair routing primitive while plan_day_routes handles multi-stop optimization. Nothing in the text routes the agent between these options.

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=true and openWorldHint=false, so safety is covered. The description adds meaningful behavioral context beyond them by pinning the result set to already-sent messages and excluding drafts, though it says nothing about result volume, ordering, or pagination beyond the schema's limit.

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 scope qualifier (sent, not drafts) front-loaded before the filter capability. No filler or redundancy.

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

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

For a 3-parameter read tool with annotations and no output schema, the description covers purpose, scope, and filtering adequately. It could note what the returned communication records contain or how results are limited/ordered, but nothing critical to 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 description coverage is 100%, so limit, channel, and customer_id are already documented in the schema. The description only restates that filtering is possible by channel and/or customer, adding no format or syntax detail beyond the structured fields — the baseline 3 for full coverage 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 (find) and resource (sent emails/SMS in the communications log), and explicitly scopes to SENT messages versus drafts awaiting a Send click. This cleanly separates it from inquiry-oriented siblings like search_inbox or read_email_thread.

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 context: it finds sent communications and supports filtering by channel and/or customer. It distinguishes the sent/draft boundary, but does not name an alternative sibling (e.g., search_inbox or read_email_thread) or state when-not to use this tool.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the return field set, but says nothing about ordering, pagination beyond the schema's limit, or default sort behavior, so it adds only modest 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 compact sentences, front-loaded with the purpose and followed by the return shape. No filler, every clause useful.

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 returned fields (id, customer name, status, end_date). Combined with fully documented parameters and read-only annotations, an agent has nearly everything needed, though default ordering/pagination behavior remains unstated.

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

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

Schema description coverage is 100%, so all three parameters (limit, customer_id, expiring_within_days) are already documented. The description's 'optionally expiring soon' loosely echoes expiring_within_days but adds no format or semantics beyond 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?

States a specific verb (Find) and resource (service contracts) plus a scoping option (expiring soon), so an agent can distinguish it from find_invoices, find_jobs, or find_customers. It does not explicitly name which sibling it is not, keeping it just short of a 5.

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

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

There is no statement of when to use this versus alternatives (e.g. lookup_customers or find_invoices), no prerequisites, and no exclusions. Usage is only implied by the resource name.

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 openWorldHint=false, so safety is covered. The description adds value beyond that by enumerating the exact return fields (id, name, email, phone, city, lead_status), which tells the agent what shape of data to expect.

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

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

Three short sentences with the core purpose front-loaded, the return shape second, and the sibling routing last. No filler or repetition.

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

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

With no output schema, the description compensates by listing the returned columns, and the limit default/max is documented in the schema. Nothing needed to call this read-only lookup 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 description coverage is 100%, so both parameters (limit, search) are already fully documented in the schema. The description's 'by name or company' only loosely restates the search parameter and adds no format or syntax 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 (customers / leads) plus the searchable attributes, and lists the returned fields. It explicitly routes geo filtering to search_freeform, though it does not differentiate from the similarly-named 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?

Gives a clear use context (name or company matching) and an explicit exclusion with a named alternative for geo filters. It stops short of a full when/when-not mapping against the other customer-related siblings (lookup_customers, 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 establish readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral value beyond that: exact boolean logic for 'overdue' (due_date<today AND balance_due>0 AND not paid/cancelled/refunded) versus 'outstanding', plus the returned field list. It does not mention pagination behavior or row caps beyond what the schema 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?

Front-loaded with the purpose, then filter semantics, then return shape. Dense and information-bearing with no filler, though the parenthetical logic and return-field enumeration make it somewhat long for a three-parameter tool.

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

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

With no output schema and no annotations covering return data, the description usefully enumerates what is returned (id, invoice_number, totals, balance_due, due_date, status, customer name). Combined with the filter definitions, an agent has enough to call it correctly; only pagination/ordering is 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 coverage is 100%, so the baseline is 3, but the description meaningfully enriches the enum beyond the schema's terse 'Invoice state filter.' by spelling out the business logic behind overdue vs outstanding vs paid, which is not derivable from 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 ('Find invoices') and immediately characterizes scope through the filter modes, which distinguishes it from aggregation siblings like ar_aging or get_ar_aging. It does not explicitly name an alternative tool, so it stops short of a 5.

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

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

The description defines each filter value precisely, which implies how to select the right mode, but it never states when to reach for this tool over siblings such as ar_aging, quotes_to_follow_up, or unbilled_completed_jobs. Usage context is implied rather than explicit.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real value beyond that by disclosing the return payload (id, job_number, title, status, schedule, tech/customer names, coordinates) and advising that the DB pk id is for navigation. No pagination or truncation behavior is mentioned, which keeps 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?

Three short sentences, front-loaded with purpose, then return shape, then the alternative-tool routing. Every sentence earns its place and nothing is 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?

No output schema exists, but the description compensates by enumerating returned columns and flagging id as a navigation key. Combined with annotations covering safety and a fully documented schema, an agent has what it needs to call it; only pagination/ordering behavior is 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 100% with six well-documented params, so the schema does the heavy lifting. The description adds no syntax, format, or interaction detail beyond noting which filters are 'common'. Baseline 3 is appropriate.

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

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

States a specific verb+resource ('Find jobs') and scopes it with 'with common filters', then enumerates the fields returned. It also distinguishes itself from the search_freeform sibling, so an agent can route between them without opening schemas. Not a 5 only because it doesn't summarize the filter dimensions (status/date/tech) that define its domain.

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 tool and the condition for using it: 'Use search_freeform for filters this tool lacks (e.g. by city).' That is clear routing guidance. It lacks any explicit when-not or prerequisite advice (e.g. required identifiers), but the core routing decision is 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuine value by enumerating the returned fields (id, quote_number, status, total, valid_until, customer name), which compensates for the absent output schema. It does not mention pagination or the default/max limit behavior, so it is 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?

Two tight sentences with zero waste: the first front-loads the action and filters, the second declares the return shape. Nothing is padded or 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 but a full-coverage input schema and covering annotations, the description fills the main gap by listing return fields and filter intent. It could be slightly more complete by noting result-count limits or ordering, but an agent has enough 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 the schema already documents all four parameters, including the limit default/max and the expiring_within_days semantics. The description restates the filter dimensions but adds no syntax or behavioral detail beyond 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?

States a specific verb+resource ('Find quotes') and names the optional filter dimensions (status, customer, expiring soon). It does not differentiate itself from lookalike siblings such as quotes_to_follow_up or find_invoices, so it stops short of a 5.

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

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

The word 'optionally' implies the filters are all-optional, which is useful, but there is no explicit statement of when to use this tool versus siblings like quotes_to_follow_up, nor any exclusion conditions. 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 declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds useful behavioral context by listing the returned fields (userid, username, mobile) and their assignment use, which is especially valuable since no output schema exists. It does not describe pagination or sorting behavior, but the core output behavior is disclosed.

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-load the purpose and returned fields, then cover optional filters. Every phrase earns its place with no wasted wording.

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 full schema coverage and no output schema, the description is nearly complete: it states the resource, returned fields, and filters. The only notable gap is guidance on when to choose this tool over sibling technician tools, which is minor given the tool's straightforward listing purpose.

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 documented in the schema. The description restates the optional filters for active-only and name search but adds no syntax, format, or edge-case meaning beyond what the schema already provides, making the baseline 3 appropriate.

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

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

The description names a specific verb and resource ('List technicians (fp_users)') and lists returned fields. It clearly states what the tool does, but it does not differentiate itself from related siblings like nearest_technicians or technician_jobs.

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

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

The description mentions 'use for assignment' in reference to the returned userid, which implies a context, but it gives no explicit when-to-use guidance, no when-not-to-use guidance, and no alternatives for selecting a technician list versus other technician-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?

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 and openWorldHint=false, so the safety profile is covered; the description usefully reinforces this with 'Nothing is saved' and adds non-obvious behavior: the returned shape (product, quantity, unit price) and the no-args discovery mode. It stops short of noting rate limits or what happens when a measurement field is missing.

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

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

Three sentences, no filler, with the core action front-loaded and the no-save caveat and discovery trick placed after. 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?

With no output schema, the description compensates by sketching the return value (line items of product, quantity, unit price) and the read-only nature is covered by annotations. Nested-object semantics and failure modes for bad template_id or unknown measurement fields are not addressed, but nothing critical to invoking 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%, so the baseline is 3, but the description adds real value beyond the schema's terse 'field → number' by giving a concrete measurements example and explaining that omitting measurements reveals the template's field set. waste_pct is left entirely to the schema, which is acceptable since the schema documents it as an override.

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 and resource ('Price a job with a published estimate template') and states what it produces ('the line items... the template produces'). It is clearly distinct from sibling list_estimate_templates, though it never names an alternative outright, so it falls just short of the 5 bar.

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 concrete operational guideline: 'Call without measurements to see which fields the template uses,' which tells the agent how to discover required inputs. It does not, however, state when to prefer this over siblings like find_quotes or preview_proposal, so it stops at clear context without exclusions.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely useful behavior: batch cap of 10, the returned fields, the cache-vs-fresh-lookup distinction, and crucially that unfindable addresses are reported rather than guessed.

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

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

Two tight sentences with no filler, and the output shape and batch limit are front-loaded. The parenthetical 'from cache or a fresh lookup' is slightly compressed but still readable.

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 usefully compensates by naming the returned fields (lat, lng, confidence) and the failure behavior. What remains thin is routing guidance against siblings, but the core call contract is 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?

With a single parameter and 100% schema coverage, the schema already documents 'addresses' as '1–10 addresses'. The description's 'up to 10 addresses' confirms the constraint but adds no syntax or format detail beyond it, so the baseline 3 applies.

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

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

The name plus 'Coordinates for up to 10 addresses (lat, lng, ...)' makes the resource and output explicit, and the batch scope is stated. It implicitly contrasts with the reverse_geocode sibling via the name, but the description itself doesn't name or distinguish from any 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 when-to-use or when-not-to-use guidance, and the obvious sibling (reverse_geocode) is never referenced. 'from cache or a fresh lookup' hints at behavior but does not tell an agent when this tool is the right choice.

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 openWorldHint=false, so safety and scope are covered structurally. The description adds that the result is an aggregated bucket breakdown rather than row-level invoices, which is useful, but it says nothing about time period, currency, or whether the results are workspace-wide.

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

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

Two short sentences, with the resource and bucket definition front-loaded and the intended use case trailing. No filler or redundancy.

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

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

With no input parameters and no output schema, the description carries the job of describing the return shape, and it does so via the named buckets. Minor gaps remain around the reporting period and scope, but an agent has enough 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?

The tool takes zero parameters, so there is nothing for the description to document and the baseline of 4 applies. The description correctly implies no input is needed.

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

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

Names the specific resource (accounts-receivable aging) and the exact output shape (outstanding balance bucketed as current, 1-30, 31-60, 61-90, 90+). This clearly separates it from siblings like overdue_tasks or revenue_by_month without needing to open 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 an explicit trigger question ('how much are we owed by buckets'), which tells the agent when this tool is the right answer. It stops short of naming alternatives or exclusions, so it does not reach the top band.

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 openWorldHint=false, so the safety profile is covered. The description adds behavior the annotations cannot: which topics return oversized payloads and the required two-step enumeration-then-fetch pattern. It doesn't discuss failure modes for bad topic/section keys, which keeps 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?

Four compact sentences with zero filler, front-loaded with the core action before the topic list. The critical two-step retrieval caveat is placed last where it is most actionable.

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 documentation reader with no output schema, the description conveys what each topic returns and how to page through the large ones, which is the essential contextual load. A brief note on what a bare section-list response looks like would make it fully self-sufficient.

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

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

Schema coverage is 50% and the `topic` property has an enum but no schema-level description, so the description carries real weight by defining what each of the four enum values contains. It also explains that `section` takes a key or heading with examples like 'send_email' and 'dunning', reinforcing the schema text rather than merely repeating it.

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

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

States a specific verb and resource ('Read Fieldproxy's automation reference') and then enumerates the exact coverage of each topic (rule anatomy, trigger types, step library, working recipes). This is unmistakably distinct from the adjacent documentation siblings like get_widget_docs and describe_schema, so an agent can route without opening the schema.

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

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

It gives concrete operating guidance: 'steps' and 'recipes' are large, so call without `section` to get the section list, then request one section. That is a clear when/how pattern. It does not, however, say when to prefer this over the other reference tools (get_widget_docs, describe_schema), so it stops short of full alternatives guidance.

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

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

readOnlyHint already signals a safe read, but the description adds real value by enumerating what the response contains (transcript, outcome, summary, objective, tool use), which matters since there is no output schema. It omits any note on error behavior for a missing/invalid call_id.

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 front-loaded sentence that wastes no words and immediately conveys the resource and its contents. The trailing list is dense but informative rather than redundant.

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

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

For a single-parameter read tool with no output schema, the description covers the essential question of what you get back. The gaps are minor (parameter meaning, no-call behavior), which keeps it just short of fully complete.

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

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

Schema description coverage is 0% and the single required 'call_id' parameter is a bare string with no format, source, or provenance hint. The description never mentions call_id, so it does not compensate for the undocumented 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+resource ('get_call' -> one call) and enumerates the payload ('transcript, outcome, summary, objective and the agent's tool use'). The phrase 'One call in full' implicitly contrasts with the list_calls sibling, though it never names 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?

There is no explicit when-to-use guidance and no alternatives named. The singular/detail framing loosely implies 'use this after list_calls to drill into a specific call', but that routing is left 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 declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the return shape (summary, ranked items, per-item evidence), which is helpful given there is no output schema, but it says nothing about missing/expired results or id resolution 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 return content is stated immediately. It is terse to the point of omitting the verb and parameter meaning, 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 simple one-parameter read tool with annotations covering safety and no output schema, describing the returned structure is the key contribution and it is present. The undocumented id parameter and unspecified behavior when no result exists leave 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?

With one required parameter and 0% schema description coverage, the description carries the full burden of explaining what 'id' identifies. It never mentions the id at all, and doesn't clarify whether it is an insight id, an integer or string identifier, or something else.

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 (an insight's latest result) and outlines its content (summary, ranked items, evidence), so the agent knows roughly what comes back. However, no explicit verb is given and nothing distinguishes it from siblings like list_insights or run_insight, leaving the action 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 use this tool versus run_insight (which presumably generates a result) or list_insights (which enumerates insights). The word 'latest' hints at post-execution retrieval, but the condition 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=true and openWorldHint=false, so the safety profile is covered externally. The description adds useful context about the computed metrics and the date-range scoping, but says nothing about return format, aggregation granularity, or whether results are paginated.

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

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

Two sentences, front-loaded with the resource and metric set, zero filler. Every clause carries information.

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

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

With three optional params, no output schema, and annotations covering safety, the description's enumeration of returned metrics is the key missing piece and it supplies it. It is nearly complete, only lacking any note on result ordering or per-tech grouping 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 coverage is 100%, with defaults documented in the schema itself, so the baseline is 3. The description only restates the optional technician filter and 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?

States a specific verb+resource (per-technician performance) and enumerates the outputs (jobs scheduled, completed, completion rate) over a date range. This is clearly distinguishable from generic list tools, though it does not explicitly contrast with close siblings such as tech_workload or technician_jobs.

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 'Optionally restrict to one technician' gives a usable condition for the technician_id parameter, but there is no explicit when-to-use guidance relative to sibling performance/workload tools and no exclusions. Usage is implied rather than stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely non-obvious behavior: web and mobile share different reference sets and the platform parameter changes which docs are returned. It omits return format/volume details, but for a read-only lookup 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-loaded with purpose, then the topic catalog, then the critical warning about reading docs first, then the platform caveat. The guide list is long but each entry is load-bearing for topic selection; no filler sentences.

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 still characterizes returns ('index lists every guide and widget', widget type returns full syntax). Both parameters and the required one are covered, and the web/mobile distinction closes the main ambiguity for calling 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 baseline is 3, but the description adds real semantics beyond the schema: it enumerates the valid topic classes ('index', guide names such as 'app'/'view'/'actions', and widget type names) and explains the effect of platform='mobile'. That goes past the terse schema strings.

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 ('Read Fieldproxy's app-building reference') and immediately enumerates what each topic value yields, so an agent knows exactly what retrieval this performs. It is clearly distinct from sibling doc tools like get_automation_docs or 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 strong prescriptive guidance ('Read the relevant doc before writing any app or screen JSON') plus the platform-selection condition ('pass platform mobile for a mobile app'). It does not explicitly contrast itself against the sibling get_automation_docs, which is the one remaining routing gap.

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 openWorldHint=false, so the safety profile is covered. The description adds meaningful context beyond that by enumerating the returned state values (active, error, expired) and the diagnostic fields (connected account, last error), which is useful in the absence of an output schema; it does not, however, say whether all integrations or a single one are returned.

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

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

A single compact sentence with no filler, and the resource is front-loaded ahead of the enumerated fields. It is a fragment rather than a full sentence, 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 no-argument, read-only tool with no output schema, the description does the necessary work of sketching the return payload (status values, connected account, last error). The only gap is whether the result covers one integration or all of them and in what form.

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 are no parameter semantics to explain and the description correctly spends no effort on them.

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 workspace's accounting/business integrations) and enumerates what is reported: status, connected account, last error. It lacks an explicit verb (it reads as a noun phrase), but an agent can still tell what it retrieves and it is distinguishable from data-oriented siblings like list_ai_connections or activity_summary.

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

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

There is no guidance on when to call this versus alternatives, no prerequisites, and no mention of any sibling tool. The agent must infer the trigger condition (wanting to check integration health) entirely on its own.

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 and openWorldHint=false, so safety is covered structurally. The description adds one behavioral hint — that this is administrative/administrator-facing data — but says nothing about permissions required, pagination, ordering, or data freshness, so the incremental value is modest.

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

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

It is short, but it is not a well-formed sentence: the em-dash clause '— administrators' hangs without a verb or clear referent, forcing the reader to guess whether it means 'for administrators' or 'number of administrators'. Brevity here comes from omission rather than efficiency.

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

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

With no output schema and no parameters, the description must at least convey the shape of the result, and 'rules and how often each has fired' does that. Still missing: any interaction with the sibling list_activity_alerts, and clarity on the truncated administrator clause, for what is otherwise a simple read tool.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-parameter tool is 4. The description correctly implies no filtering input is needed.

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

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

The noun phrase names a specific resource (activity alert rules) and adds scope ('how often each has fired'), which helps distinguish it from the sibling list_activity_alerts. However, there is no explicit verb and the trailing '— administrators' is a dangling fragment that leaves the action implied rather than stated.

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

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

There is no when-to-use guidance, no stated prerequisites, and no mention of the sibling list_activity_alerts, which is the obvious alternative for alert data. The only contextual signal is the ambiguous tag '— administrators', which may hint at an audience but does not tell the agent when to select this tool.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safe-read nature is covered. The description adds useful behavioral context beyond the annotations: 'newest first' ordering and the administrator audience restriction. It still omits pagination behavior and what an alert record contains, which keeps it at a 3.

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 the resource and scope front-loaded and no filler. The parenthetical examples earn their place by narrowing scope, though the dash-appended 'administrators' reads slightly clipped.

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, zero-required-parameter list tool with no output schema, the description covers scope and ordering adequately. It is missing usage routing and an explanation of unacknowledged_only, so it is sufficient but not complete.

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

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

Schema coverage is 50%, so half the parameters carry no documentation. The schema itself documents 'limit' (max 100, default 25), and the description's 'newest first' implies sort semantics but never explains unacknowledged_only, leaving that parameter undocumented in both places.

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

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

States a specific verb and resource ('Alerts raised by the workspace's activity alert rules'), which is clearer than a bare 'list alerts'. The parenthetical examples (bulk deletes, off-hours activity, sensitive field changes) pin down the alert scope. It is distinguishable from the sibling list_activity_alert_rules (rules config vs raised alerts), though it does not explicitly contrast them.

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

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

No when-to-use guidance or alternatives are named. The trailing '— administrators' implies an audience/access constraint, but nothing tells the agent when to reach for this over list_alerts, list_activity_alert_rules, or activity_summary.

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 openWorldHint=false, so safety is covered. Beyond that, the description usefully discloses the substance returned — key ownership, issuing admin vs owner, scopes, limits, last-used, and the claim/active/expired/revoked lifecycle — which is real behavioral context an agent would not get from the annotations alone.

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 resource and scope before the enumeration of returned fields. It is dense and dash-heavy, but each clause adds a distinct piece of information rather than 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?

For a read-only listing tool with full schema coverage and an explicit read-only annotation, the description supplies the essential missing piece — what the returned connections consist of and their lifecycle states. With no output schema, it could say slightly more about volume/pagination, but it is otherwise complete for correct invocation.

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

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

Schema coverage is 100%, so both parameters are already documented in the schema. The description doesn't add syntax or format detail for user_id or include_inactive, though its mention of the claim/expired/revoked states loosely maps to include_inactive. Baseline 3 applies when the schema carries the 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?

The description states a specific resource ("Every AI connection to this workspace") and enumerates exactly what it returns: MCP keys with owner/issuer, scopes, limits, last-used, status, plus OAuth-signed-in apps like Claude and ChatGPT. It clearly reads as a connection-inventory tool, distinct from activity or usage tools, though it does not explicitly name a sibling it should not be confused 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?

The parenthetical "(administrators)" signals the intended audience, implying an admin-only audit/inventory use case. However, there is no explicit when-to-use versus a sibling like ai_activity_log or ai_usage_summary, nor any stated prerequisites, so the guidance 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 declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description usefully adds scope ('yours, and the workspace-wide ones'), clarifying that both personal and shared instructions are returned. It says nothing about ordering, size, or formatting 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 front-loaded sentence with no wasted words. It is written as a noun phrase rather than a full clause, which is terse but still readable.

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-argument, read-only list tool with no output schema, the description covers the essential question of what is returned and its two scopes. Only minor details (ordering, volume) are absent, which is acceptable at this complexity.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline is 4. No parameter-level gaps exist.

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 resolves the cryptic name 'list_ai_memory' into concrete content: 'standing instructions' that are both personal and workspace-wide. This is clear enough that an agent knows it returns stored AI instructions rather than log/activity data. It doesn't explicitly differentiate from nearby siblings like list_ai_connections or get_automation_docs, keeping it 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 statement of when to call this versus alternatives, and no prerequisites or trigger conditions. The description only says what the data is, not when an agent should reach for it. Usage is left 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 declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuine resource semantics — alerts are polled every few minutes and fire on a condition — which tells the agent the data is periodically refreshed rather than real-time. It says nothing about ordering, result size, or pagination, so it is useful but incomplete 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?

A single sentence with zero filler; the resource definition comes first and the returned fields are compressed into one clause. The heavy parenthetical slightly hinders 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 zero-parameter, read-only list tool with no output schema, the field enumeration usefully stands in for return-value documentation. However, with ~70 siblings and two confusable alert tools, the absence of any disambiguation leaves a meaningful gap for selection.

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

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

The tool takes no parameters, so the baseline of 4 applies. The description does not need to explain inputs, and the returned-field list is a bonus rather than a parameter explanation.

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 ('your data alerts') and defines what an alert is in this product, plus enumerates the returned fields (id, name, active/paused, frequency, last check). It never says 'list' explicitly, but the field enumeration makes the retrieval intent unmistakable. It does not differentiate itself from the sibling tools list_activity_alerts and list_activity_alert_rules, which is a real ambiguity given the crowded namespace.

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 prerequisites, and no mention of alternatives — despite two similarly named alert-listing tools in the sibling set. The definition of 'alert' implicitly signals context, but the agent gets no help deciding between this and list_activity_alerts.

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 openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior in the absence of an output schema by enumerating returned fields and stating newest-first ordering, but it omits pagination and default-limit behavior. A moderate contribution given the lower bar set by annotations.

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

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

A single front-loaded sentence that leads with the resource and ordering before the field list. It is appropriately sized with no obvious filler, though the field enumeration is long relative to the sparse purpose statement.

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 field list partially fulfills the need to describe return values, but the definition leaves filtering semantics, pagination, and the distinction from get_call unaddressed for a 5-parameter list tool. Adequate but with clear gaps.

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

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

Schema coverage is only 40%: limit and since are documented, while agent_id, direction, and follow_up_only are undocumented in both schema and description. The description names no filtering parameters and does not compensate for the coverage gap, adding nothing to what the schema already says.

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 identifies the resource clearly (voice-agent calls) and the ordering (newest first), so an agent understands it is a listing of calls. However, it uses a noun phrase with no explicit verb and primarily enumerates returned fields rather than stating the action, and it does not differentiate from the sibling get_call. Clear but imperfect.

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 mention of alternatives such as get_call for a single call, and no exclusions. The agent is left to infer that a plural 'calls' listing tool is for browsing rather than fetching one record.

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 that this is a read-only, non-open-world operation. With no output schema, the description adds real value by disclosing the shape of each returned record (name, slug, published flag, tile count). It does not mention pagination or ordering, which is a minor gap given there are no inputs.

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 resource first and the returned fields second. No filler, no repetition of the title or name.

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 listing tool with no output schema, the description covers what an agent needs: the resource scope and the returned fields. Only ordering/pagination behavior is unstated, which is a small omission rather than a blocking one.

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 to explain; per the rubric this is the baseline 4. Nothing in the description conflicts 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?

States a specific verb (list) and resource (Command Center dashboards) and enumerates the returned fields (name, slug, published, tile count), so the agent knows exactly what comes back. It does not explicitly distinguish itself from the sibling view_dashboard, which is the obvious alternative for inspecting a single dashboard.

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 view_dashboard or any other sibling, and no prerequisites or exclusions. The phrase 'dashboards you can see' hints at a visibility scope but the agent must infer that it means the listing operation.

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 and openWorldHint=false, so the safety profile is covered. The description adds two meaningful behavioral facts beyond that: access is restricted to admins, and the listed rows are only those still within a restorable window. It does not describe pagination or the effect of omitting the optional table filter.

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 packs the resource, the restore window, the permission gate, and the returned fields without filler. The enumeration of return fields ('table, id, when and by whom, and a preview') could be tightened but is 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?

With no output schema, the description usefully enumerates what each row contains and states the admin restriction and recovery window, which is enough for an agent to decide whether to call it. Only pagination behavior and the semantics of the optional table filter remain uncovered.

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 'table' has no schema description. The description mentions 'table' but in the context of returned fields rather than explaining that it filters results or that it is optional, so it only partially compensates for the gap.

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

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

The description names a specific resource with a clear qualifier: records that were recently deleted but are still restorable. That scope is distinctive and lets an agent separate it from siblings like record_history or list_record_files, even though the verb ('list') is only implied by the tool name.

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

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

Usage is only implied: '(admins)' signals the required privilege and 'can still be restored' hints at a recovery-oriented workflow, but there is no explicit statement of when to call this instead of alternatives, nor any reference to a restore/undelete counterpart.

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=true, openWorldHint=false). The description adds genuinely useful behavior beyond that: it returns each value with its row count and orders results most-common-first, so the agent knows the return shape and 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, and the ordering/return behavior is front-loaded alongside the purpose. Every clause earns its place.

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

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

For a simple 3-parameter read tool with no output schema, the description supplies purpose, use case, and return format, leaving little ambiguity. Only minor gaps like large-table cost or limit semantics remain, and the schema covers the limit default.

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 table, column, and the limit default of 50 are all documented in the schema itself. The description implies column/table are required by restating 'in a column' but adds no format or syntax detail, so baseline 3 applies.

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

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

States a specific verb+resource ('List the distinct values in a column') and clarifies the intent with a concrete use case (enum/value discovery for statuses or service types). It does not name a sibling such as describe_schema, but the operation itself is unmistakable.

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 context for when to reach for this tool ('for enum/value discovery — e.g. what statuses or service types exist'), which is exactly the decision point an agent faces. No explicit when-not guidance or named alternative is provided, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safe-read profile is covered. The description adds useful payload context ('and the arguments each takes'), but says nothing about pagination, ordering, or whether templates are workspace-wide or user-scoped.

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-loaded with the resource and followed by examples and the argument note. Nothing is wasted and nothing is 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 and no parameters, the description carries the burden of describing the return value, and it does state what comes back (templates plus their arguments). It is adequate for a zero-arg listing tool, with only minor gaps around scope and 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?

Zero parameters, so the baseline is 4. The phrase 'the arguments each takes' hints that each returned template carries its own accepted argument set, which is a small bonus over an empty schema, though no parameter-level detail is needed or possible 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?

Names the concrete resource (the workspace's PDF/Word document templates) and enumerates examples (quotes, job reports, invoices), so the agent knows exactly what is returned. It stops short of differentiating from near-identical siblings such as list_estimate_templates and list_proposal_templates, which an agent could easily confuse with this one.

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

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

The description is purely a content statement; it gives no when-to-use guidance and never mentions when to prefer this over list_estimate_templates, list_proposal_templates, or list_email_templates. The agent must infer from the sibling list alone that this tool covers PDF/Word output 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 and openWorldHint=false, so safety is covered. The description adds the sort order (soonest first) and the due-filter meaning, but says nothing about pagination, result size, or whether reminders from all threads 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?

One compact sentence with the resource and ordering front-loaded and the parameter hint folded in economically. Every clause earns its place.

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

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

For a simple read-only list with one optional boolean, one annotation pair, and no output schema, the description covers purpose, ordering, and the filter's intent. Minor gaps remain on default due_only behavior and result volume.

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

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

Schema coverage is 0% for the single due_only boolean, so the description must carry the meaning. 'due_only for the ones that have come round' conveys that true restricts to currently-due reminders, but the wording is colloquial and leaves the false/default behavior unstated.

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') and behavior ('soonest first'), which scopes it away from sibling listing tools such as overdue_tasks or quotes_to_follow_up. It stops short of naming a sibling or explicitly contrasting scope, so a 4 rather than 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 parenthetical hints at when to set due_only (when you only want items that have come round), which is implicit usage guidance. There is no explicit when-to-use-vs-alternatives statement directing the agent away from overdue_tasks or search_inbox.

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 openWorldHint=false, so the safety profile is covered by structured data. The description adds useful value by enumerating the return fields and the {{placeholders}} metadata in the absence of an output schema, but says nothing about result size, ordering, or how 'team shared' templates are distinguished.

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 with zero waste; the resource and scope are front-loaded and the actionable next step comes second. Nothing is redundant against name, schema, or annotations.

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

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

For a read-only list tool with no output schema, the description supplies the key return fields and the follow-up workflow, which is close to complete. The one material omission is any explanation of the search parameter, which an agent would otherwise have to 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?

There is one parameter, 'search', and schema description coverage is 0% - the schema offers only a bare string type with no explanation. The description never mentions the search parameter at all, so it does not compensate for the gap or clarify what search matches against (name, subject, body?).

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 the specific resource (email templates) and its scope - the caller's saved templates plus the team's shared ones - and lists the returned fields (id, name, subject, placeholders). This clearly separates it from sibling template listers such as list_document_templates and list_proposal_templates.

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 states the downstream workflow - take a template and use it with draft_email (template + template_vars) - which implies why you'd call it. However it gives no explicit when-to-use-this vs. the many other list_* siblings, and the selection guidance is only implicit through the draft_email reference.

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 openWorldHint=false, so the safety profile is covered. The description adds useful domain context (the published-version distinction and that published templates can price jobs), but says nothing about pagination, workspace scoping, or what an empty result means.

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 the resource stated first and the return fields appended. Every clause earns its place 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?

With no output schema, the description usefully lists the fields returned (id, name, trade, published version), which is the main thing an agent needs for a no-arg list tool. It is nearly complete, missing only result volume or ordering 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?

The tool takes zero parameters, so the schema imposes no burden and the baseline for a parameter-free tool applies. The description instead documents the shape of the returned records, which is a reasonable substitute for parameter guidance 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 specific verb and resource ('list_estimate_templates' → the workspace's estimate templates) and enumerates the returned fields (id, name, trade, published version). It is clearly distinguishable from sibling list_* tools by resource name, but it never names an alternative to avoid confusion with list_proposal_templates or generate_estimate.

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 that 'published ones can price a job from measurements' gestures at why the tool matters, but there is no explicit when-to-use, when-not-to-use, or routing to siblings like generate_estimate or list_proposal_templates. An agent must infer the calling context on its own.

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 openWorldHint=false, so safety and scope are covered without the description. The description adds useful context about the domain (insights represent at-risk jobs and next actions) but says nothing about ordering, pagination, or whether the list is exhaustive or per-user.

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 is named first and details follow. The trailing field enumeration is slightly packed but each item earns its place in the absence of a 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?

With no parameters and no output schema, the description correctly carries the return-value burden by naming the fields (name, kind, schedule, last ran). It stops short of describing scope (whole workspace vs. current user) or ordering, which keeps it from being fully 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?

The tool takes zero parameters, so the baseline of 4 applies; there is nothing for the description to disambiguate. The field list it provides describes output, not input, so it neither helps nor hurts this dimension.

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 ('The workspace's AI insights') and concretizes it with examples (at-risk jobs, next actions) plus the fields each insight carries. It is clear on its own, but it never contrasts itself with the closely-named siblings run_insight and get_insight_result, so an agent must infer which one lists vs. executes.

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 or when-not-to-use guidance. Given siblings like run_insight and get_insight_result, the description should say this returns the catalog of insights rather than generating one, but that routing information is absent.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds one useful behavioral fact: only already-sent proposals are returned, implying drafts are excluded. It says nothing about ordering, pagination, or what 'superseded' means operationally.

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 the noun and scope front-loaded and zero filler. It is terse to the point of being fragmentary, 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 correctly enumerates the returned fields, which is the right thing to include. It still leaves gaps for a filterable list tool: default sort order, behavior when status/customer are omitted, and what happens past the limit of 50.

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% (just limit), so the description must compensate, and it partially does by enumerating the valid status values (sent/viewed/accepted/declined/expired/superseded), which the schema omits. However, the customer parameter's matching semantics (exact name vs partial) and the interaction of limit with pagination 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 verb (list) and resource (proposals), and scopes it with 'already sent to customers', which separates it from the sibling list_proposal_templates. It also enumerates the returned fields, so the agent knows exactly what it gets. No explicit sibling routing, hence not a 5.

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

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

There is no when-to-use guidance, no mention of the alternative tools (list_proposal_templates, preview_proposal), and no stated prerequisites or exclusions. The field list hints that results can be narrowed by customer or status, but the description never says to do so.

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 openWorldHint=false, so the safety profile is covered. The description adds that templates carry arguments with defaults and option tiers, which is useful context, but it says nothing about workspace scoping, pagination, or filtering behaviour.

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, and the resource is front-loaded before the field list. It is efficient, though being a fragment it lacks the crisp verb-first framing that would make it self-contained.

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 list tool with no output schema, the field enumeration (id, title, description, arguments with defaults, option tiers) largely substitutes for the missing return schema. The remaining gap is the absence of any routing guidance relative to sibling list tools.

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

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

The tool takes no parameters, so the baseline is 4. There is nothing for the description to clarify beyond the empty schema, and it correctly does not invent parameters.

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

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

The description names the resource ('the workspace's proposal templates') and enumerates the fields it exposes, so the agent knows what it returns. However, it is a bare noun phrase with no verb, relying on the 'list_' prefix in the name, and it does nothing to distinguish itself from close siblings like list_proposals, list_estimate_templates or list_document_templates.

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 prerequisite, and no mention of alternatives. An agent cannot tell from the text when to call this rather than list_proposals or list_estimate_templates, so it must infer usage purely from the name.

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 openWorldHint=false, so the safety profile is covered. The description adds useful return-shape context ('each file's URL, column and kind') but says nothing about permissions, pagination, or limits on the number of files returned, which would be valuable for a listing tool with no output schema.

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

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

Two tight sentences with the core purpose front-loaded, followed by the return shape and the routing hints. No filler or redundancy.

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

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

For a read-only list tool with no output schema, the description does cover the return fields and the follow-up tools, which is the main complexity. However, the parameter semantics gap (table vs. record_id vs. id_column) and the absence of any pagination/limit context leave it only minimally complete.

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

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

Schema description coverage is only 33% and the description never explains the three parameters. 'stored on one record' loosely implies record_id, but 'table' and 'id_column' (which has only a terse 'Default id' schema note) are left undocumented in both places, so the description does not compensate for the coverage gap.

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

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

States a specific verb ('List') and resource ('files... stored on one record') with concrete examples (photos, PDFs, documents, signatures) and a domain illustration (a job's before/after photos). It is clearly distinguishable from siblings like read_file and view_images, which it explicitly routes to.

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

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

The description tells the agent both when to use this tool (to enumerate files on a record) and which alternatives to use for follow-up actions: view_images for viewing photos, read_file for reading document text. This is explicit routing with named alternatives, not implied usage.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds the ordering behavior of the result set, which is genuine extra context, but nothing about pagination, result size, or cases where no saved views exist.

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 with no filler; the ordering detail is front-loaded and the return-shape note follows. Effective use of limited 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?

For a read-only two-parameter tool with no output schema, the description usefully sketches what comes back (params, ai_filters), but it leaves the required inputs entirely undocumented and gives no sense of scale or failure modes.

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 neither app_id nor view_id is explained anywhere. The mention of 'params' and 'ai_filters' describes return fields, not the two required input parameters, so the description does not compensate for the schema gap.

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

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

The description names the resource precisely (saved filter presets on one app view) and even describes the ordering of the returned items ('your own, then the ones shared with everyone'). It is a noun phrase rather than a verb, but combined with the name the action is unambiguous. No obvious sibling overlaps it, so sibling differentiation is less critical here.

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 alternatives, no prerequisites, and no mention of what context (which app/view) an agent should already have. The description only characterizes the payload, leaving usage 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 declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context: cadence is reported 'in local time' and that a 'last error' field is included, going slightly beyond the annotations. It does not address ordering 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?

A single front-loaded sentence with zero filler; every listed field earns its place by describing the output.

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 (id, name, status, cadence, runs, last error), compensating well for the missing schema. Minor gaps like ordering or whether inactive reports are included 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 no parameters, so the baseline is 4. The description appropriately focuses on return fields rather than parameters, adding nothing misleading about inputs.

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

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

States a specific verb+resource ('your scheduled reports') and enumerates the returned fields, so an agent immediately knows what it retrieves. It does not differentiate from any sibling, but there is no competing sibling for scheduled-report listing, so the omission is harmless.

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 prerequisites, and no named alternatives. The tool is self-evident as a read, but the description offers nothing about context of use.

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 and openWorldHint=false, so safety is covered. The description goes beyond that by disclosing the exact returned fields and the geometry simplification behavior (~10 m, 5 decimals) — concrete behavioral detail an agent can use to decide whether to request geometry.

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

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

Two tight sentences with no filler. The field enumeration is front-loaded, though the sentence opens as a fragment ('The workspace's service zones...') rather than with an explicit verb.

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

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

With no output schema, the description substitutes by enumerating return fields in detail. The main gap is the absence of routing guidance relative to zones_for_location, but for a zero-required-parameter read tool it is otherwise complete enough to invoke 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 only 50% and include_geometry has no schema description, but the description compensates by explaining what include_geometry adds and how the GeoJSON is simplified. zone_id is left to the schema's 'Only this zone', which is adequate but thin.

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

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

Specific resource and field list: service zones with id, name, colour, active, area, vertex count and record counts. It clearly describes what the tool returns, but does not differentiate from the related sibling zones_for_location or the many other list_* tools.

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

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

No when-to-use, when-not, or alternative guidance. The presence of a sibling zones_for_location raises an obvious route-selection question that the description never addresses.

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 openWorldHint=false, covering the safety profile for this read operation. The description adds no behavioral context beyond that - nothing about match semantics (exact vs fuzzy), result limits, pagination, or what is returned - so it contributes little on this dimension.

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

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

Two short sentences, zero filler, with the core capability stated first and the alternative second. 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?

There is no output schema, so the description should be self-sufficient for a simple one-parameter lookup; it states purpose, matched fields, and the SQL alternative. The remaining gap is only secondary detail (match type, result caps), which is minor 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 description coverage is 0%, so the description carries the burden, and it does explain the single 'search' parameter's semantics: the query matches on name, company, or email. That is meaningful value the schema does not provide, though it omits matching behavior (partial vs exact).

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

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

The description gives a specific verb and resource (search customers) plus the fields matched (name, company, email), so the purpose is unambiguous. It does not, however, distinguish itself from the very similar sibling 'find_customers' or 'segment_customers', leaving a sibling-selection ambiguity.

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

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

'Use this instead of raw SQL for customer lookups' names one alternative and the condition for preferring it, which is real guidance. But it offers no exclusions and gives no clue about when to use it versus the near-identical 'find_customers' sibling, so the routing guidance is only partial.

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 and openWorldHint, and the description adds real value on top: the 'up to 5' ceiling, the freshness caveat that a position is merely where the phone last reported, and the permission scoping. It does not discuss rate limits or failure modes, which keeps it at 4 rather than 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 tight sentences, front-loaded with what is returned (drive minutes, km, position age) before the caveats. No filler, though the scheduling advice could be folded more economically.

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 (drive minutes, km, position age) and the access scope. It is complete enough to call the tool correctly, with only output ordering/pagination undescribed.

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 place, limit, user_ids, and within_hours. The description only echoes the limit cap of 5 and the freshness concept already implied by within_hours, so the baseline 3 is correct.

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 operation: the technicians nearest a place measured by road distance, derived from each person's latest reported position. This clearly separates it from raw-position siblings like technician_locations and lookup-style siblings like find_technicians, though 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?

Gives a concrete usage frame ('check their schedule before assigning work') and states an access precondition (only people your location access covers; admins see everyone). It does not name when to prefer a sibling tool, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context the annotations don't: the tool returns a link rather than opening anything, and the agent cannot drive the user's browser.

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 and constrained to two sentences with no filler. The parenthetical record-type examples and the browser caveat both earn their 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 explains the return value (a link) and the interaction model. It stops short of edge cases such as missing records or link expiry, but is otherwise sufficient for a simple read tool.

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

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

Schema coverage is only 33% (only id_column is documented), so the description must compensate. It maps the inputs well ('Give the table and the record's id (or another unique column in id_column)'), but adds no detail on accepted table names or id formats, leaving the compensation partial.

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

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

The description states a specific verb and resource ('Get a link that opens one record') and clarifies the record types (customer, job, invoice). It conveys a distinct value proposition versus data-returning siblings, though it never names an alternative to contrast against.

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

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

Usage is implied by 'for the user to click — you can't open their browser yourself', which signals this is for handing a viewable link to a human. There is no explicit when-to-use/when-not or named alternative sibling (e.g. record_history or find_* lookups).

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

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the meaningful scope constraint that results are a filtered subset (past due, incomplete), but says nothing about ordering, volume, or return shape. Some added context, but modest.

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

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

Two short sentences, zero waste, with the definition front-loaded before the usage hint. Nothing could be removed without losing signal.

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, parameterless read tool with no output schema, the description covers what an agent needs to select it: what it returns (a filtered task set) and when to reach for it. It does not describe the fields returned per task, which is the only remaining gap.

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

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

This tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-parameter tool is 4. Nothing in the description suggests configuration that isn't there.

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 (tasks) with two precise filters: past due date and not completed. That is enough for an agent to distinguish it from a generic task list, though it never names a sibling such as todays_schedule or broken_promises to anchor the 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?

It offers trigger phrases ('overdue tasks', 'what's slipping'), which is real usage guidance. However, it gives no when-not guidance or alternatives, and the first phrase is essentially a restatement of the tool name, so the routing value 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 declare readOnlyHint=true and openWorldHint=false, and the description reinforces this with 'Only READS' plus the downstream 'apply the result with apply_schedule'. It also discloses graceful-degradation behavior (missing coordinates cause a refusal message). It does not cover result size, performance, or whether the plan is deterministic.

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 action and scope, then immediately covers prerequisites, fallback, and safety in three dense clauses. Every sentence carries information an agent needs to select and call the tool; there is 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?

With no output schema, the description compensates by summarizing the return payload (assignment/order, suggested start times, km and drive minutes). Combined with the coordinate prerequisite, the fallback tool, and the read-only/apply split, an agent has everything needed to invoke and act on 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?

Schema description coverage is 100%: date format (YYYY-MM-DD), the technician filter with its default, and service_minutes with its default are all documented in the schema. The description adds only loose context (road routing, per-visit start times) and no parameter-specific syntax beyond what the schema provides, so the baseline 3 applies.

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

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

Names a specific verb (plan) and resource (one day's routes) and enumerates concretely what is produced: assignment of technician to job, visit order, suggested start times, and per-tech km/drive minutes. It is clearly distinguishable from siblings like plan_job_distribution and 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?

Explicitly states the precondition (job coordinates required), what happens when it can't be met ('if none have them it says so'), and names the fallback sibling plan_job_distribution. It also closes the loop with the follow-up action apply_schedule, so the agent knows this tool is read-only planning.

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

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

Annotations only declare readOnlyHint=true and openWorldHint=false; the description adds the important behavioral fact that it returns a proposal (per-job assignments plus what couldn't be placed) and does not persist anything on its own. This 'plan vs. commit' disclosure is genuinely useful beyond the annotation, though it omits details like pagination or 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 with zero filler: purpose first, then read-only disclosure, then the forward action. The scoping constraint and the commit step are each front-loaded where they matter.

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 describing what is returned (a proposed assignment per job and unplaceable jobs) and the call to apply_schedule to persist. Combined with 100% schema coverage it is nearly self-sufficient, missing only its relationship to the route-planning 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 100%, so all four parameters (date range, default_minutes, cap_minutes_per_day) are already fully documented with ranges and defaults. The description alludes to the daily cap and booked minutes but adds no syntax or format meaning beyond the schema, so baseline 3 applies.

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

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

States a specific verb (plan/assign) with exact scope: 'which open, unassigned job over a date range' and the balancing objective (booked minutes under a daily cap). An agent can tell exactly what the tool produces (a proposed assignment per job) without opening the schema.

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

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

Explicitly routes the agent to the follow-up tool: 'To make it real, pass the assignments to apply_schedule,' making the read/commit split clear. It does not, however, distinguish itself from the similar sibling plan_day_routes or state when not to use it, so it falls short of full when/when-not guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the dry-run framing ('without creating it') and lists the fields the preview returns, which is meaningful since no output schema exists, but it discloses nothing about auth, limits, or error behavior.

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

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

A single sentence, front-loaded with the verb and resource, with no wasted words. The dash-separated enumeration is compact and skimmable.

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?

Because there is no output schema, enumerating the returned content (title, customer, price, pricing lines, tiers) compensates well. The one gap is not clarifying how 'arguments' plain values map into the preview, but the schema covers that case.

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

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

Schema description coverage is 100%, so template, tiers, and arguments are all documented in the schema itself. The description adds no parameter meaning beyond what the schema already provides; 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 (show/preview) and resource (proposal), and enumerates the content it previews (title, customer, price, pricing lines, tiers). The phrase 'without creating it' clearly separates it from a create/generate operation, though it never names an actual sibling 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 'without creating it' phrasing implies this is a dry-run/preview step to use before creating a proposal, which is useful context. However, it gives no explicit when-to-use guidance relative to neighbors like list_proposals, list_proposal_templates, or generate_document, so the agent must infer.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description usefully adds what counts as a flag (urgency mismatch, vague/empty description) and the shape of the result. However it says nothing about the scope of requests scanned, whether any limit/cap applies, or whether the check is deterministic versus model-based — notable gaps for a zero-parameter audit tool.

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

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

Three sentences, front-loaded with the core behavior, and the return value is stated last. Efficient, though the second clause ('also flags requests whose description is too vague or empty') slightly repeats the flagging frame and could be tightened.

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

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

With no input schema, no output schema, and annotations covering safety, the description carries the burden well by explaining both trigger conditions and the result shape. The one missing piece is scope — which requests are evaluated and over what period — which an agent cannot infer from any structured field.

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. There is nothing for the description to disambiguate, and it does not introduce unnamed inputs.

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

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

States a specific action (analyzes service request descriptions against assigned priority) plus the two flagging conditions, and describes the return payload. No sibling tool performs a priority-vs-text audit, so it is clearly distinguishable from the surrounding analytics and listing tools.

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

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

The scenario where this tool pays off is implied by the description (auditing priority consistency), but there is no explicit when-to-use statement, no mention of prerequisites, and no routing away from alternatives such as overdue_tasks, rework_check, or the various list_* tools. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. Beyond that, the description usefully discloses the actual filtering predicate (past next_follow_up_date or sent >5 days ago), which is behavioral detail the annotations do not carry.

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

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

Two tight sentences with zero filler. The scoping criteria come first and the usage trigger second, so the most decision-relevant 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?

For a zero-parameter, read-only list tool with no output schema, the definition supplies enough to select and call it correctly. It could add return-field or ordering expectations, but those are minor omissions.

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 there is nothing for the description to clarify beyond the schema; the baseline for a zero-argument tool 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 resource (quotes) and a precise inclusion rule: sent/viewed/pending quotes past next_follow_up_date or sent more than 5 days ago. It is clearly distinct from a generic find_quotes, though it never names that sibling explicitly to reinforce the 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?

Gives concrete user-phrase triggers ('quotes to chase', 'open quotes') that map natural-language intents to this tool. However, it does not state when NOT to use it or name find_quotes as the alternative for broader quote queries.

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 openWorldHint=false, so safety is covered, but the description adds meaningful fidelity context: messages come back condensed with quotes trimmed, so an agent should not expect raw full bodies. That is a real behavioral trait beyond the structured fields. It does not mention truncation limits or auth requirements.

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

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

A single tightly written sentence that front-loads the action and enumerates the payload. Every clause carries information and 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 enumerates the returned fields and the condensed-message behavior, which is the key completeness burden here. The remaining gap is the undocumented parameters, but for a simple two-param read tool the description is largely 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?

With only 50% schema description coverage, the description should compensate, but it adds nothing about thread_id's accepted type/format or about max_messages controlling message count. The phrase 'newest messages' vaguely gestures at ordering/quantity but does not explain the 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 (read) and resource (one email thread) and enumerates what is returned: subject, participants, linked contact, newest messages. It distinguishes itself from listing/searching siblings like search_inbox and list_email_followups by emphasizing a single thread, though it never names an alternative explicitly.

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

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

There is no guidance on when to use this tool versus search_inbox, find_communications, or list_email_followups. The only implied usage is that the caller already knows a thread_id, but no precondition or exclusion is 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 openWorldHint=false, so the safety profile is covered; the description adds real behavioral context beyond that — images return as the picture itself rather than text, and video/audio are unsupported. It omits any truncation behavior tied to max_chars, but the added format-handling detail is meaningful.

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 dense sentence, front-loaded with the core action, then the accepted inputs, then the format support and the image/video exclusions. Every clause carries information; nothing is 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 two-parameter read tool with no output schema, the description covers the source of url, supported formats, image return behavior, and unsupported media. What's missing is minor — nothing about what happens to very large files or error behavior when a URL is invalid — but an agent has enough 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 only 50%: max_chars is documented ('Default 20000, max 100000') but url has no schema description. The description compensates by explaining what url should contain (a URL from list_record_files, a record, or an email attachment), which is the key semantic an agent needs. It adds little on max_chars since the schema already covers it.

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

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

States a specific verb (read) and resource (file text in this workspace), enumerates the accepted source forms (URL from list_record_files, a record, or an email attachment) and the supported formats, and explicitly carves out video/audio. An agent can distinguish it from siblings like view_images or read_email_thread immediately.

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

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

Names the alternative for bulk images ('view_images does up to 10 at once') and states the exclusions (video and audio aren't read), which routes the agent correctly for image-heavy cases. It does not cover other potential alternatives (e.g. read_email_thread for threads, list_record_files for discovery), so it stops short of full when/when-not guidance.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral detail about the result shape (newest first, actor attribution, before → after values), but says nothing about the limit cap or pagination behavior that a caller would care about.

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; every clause (ordering, actor types, before → after) carries information. The trailing ellipsis after 'AI…' is slightly loose but harmless.

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 returned fields, which is a real contribution. However, it leaves the two required parameters (table, record_id) unexplained and omits limit/default behavior, so an agent still lacks enough to invoke it confidently.

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%: table and record_id have no descriptions at all, and the description does not compensate by explaining what 'table' identifies or what form record_id takes (integer or string). Only the limit parameter is documented, and even that 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 names the specific resource (a record's change history) and its ordering (newest first), giving an agent a clear picture of what it retrieves. It does not name or differentiate itself from sibling tools like compare_record or open_record, which also operate on records, 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?

There is no guidance on when to use this tool versus alternatives such as compare_record, open_record, or workspace_activity, nor any stated prerequisites. The agent must infer usage entirely from the purpose statement.

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