ReelQuoteAI Survey Tool

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

The description discloses meaningful behavioral detail beyond the annotations: true stamps 'nothing is missing', false clears it, and the prompts are recomputed from current inventory on each read so fixing a gap makes the prompt disappear. This aligns with readOnlyHint=false, so there is no contradiction. It could add response details, but the mutation semantics are clearly communicated.

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 compact and well-structured: purpose first, then body semantics, then the recomputation behavior, then scope. Every sentence earns its place and none of the schema's details are redundantly repeated.

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 boolean ack tool, the description covers purpose, payload semantics, dynamic prompt behavior, and required scope. There is no output schema, so the description could have described the response shape, but that is a minor omission given how much context is already provided.

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

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

The schema already documents both parameters with 100% coverage, so the baseline is 3. The description adds value by explaining the effect of acknowledged=true/false and tying job_id to the inventory.gaps field on GET /jobs/{id}. This goes beyond the schema's parameter names and types.

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

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

The description uses a specific verb ('Record') and a precise resource ('customer's answer to the capture-gap prompts'), then clarifies what that answer does with acknowledged=true/false. This clearly separates it from related inventory tools like approve_inventory or quote_inventory.

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

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

The description clearly frames when to use the tool: to record a customer's answer to gap prompts. It also provides indirect usage guidance by explaining that fixing a gap removes the prompt without needing this call, which helps avoid unnecessary invocations. It does not explicitly name alternative tools or state when not to use it.

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

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

Annotations already indicate readOnlyHint=false and destructiveHint=false, so the safety profile is known. The description adds only 'Scope: jobs:write', which is an authorization detail rather than a behavioral disclosure. It does not explain side effects such as withdrawal via approved=false, idempotency, or downstream consequences.

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

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

The description is extremely concise: one sentence plus a scope qualifier, with no filler. It is front-loaded and easy to parse. However, its brevity sacrifices useful behavioral and usage context, so it cannot earn a 5.

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 three-parameter tool with full schema coverage and basic annotations, the description is minimally adequate. It includes the auth scope and the sign-off action, but it lacks guidance on when to use it and what happens when approved=false or notes are modified. An agent could probably call it correctly, but not with full confidence about side effects.

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 job_id, notes, and approved are already fully documented in the schema. The description's 'free-text notes' and 'sign-off' add no additional meaning beyond what the property names and schema provide. A baseline score of 3 is appropriate when the schema carries the parameter semantics.

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

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

The description states a specific action ('Customer sign-off') and resource ('the inventory'), immediately clarifying the tool's core purpose. It also indicates 'free-text notes' and scope 'jobs:write'. It doesn't explicitly contrast with siblings like quote_inventory or acknowledge_gaps, but the sign-off wording is sufficiently distinct.

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 about when to use this tool versus related siblings such as quote_inventory, acknowledge_gaps, or confirm_access. The description gives no preconditions, exclusions, or alternative routing. This leaves the agent to infer usage context from the name alone.

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

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

The description goes beyond the generic annotations by revealing that the tool is free, never bookable, and limited to quote scope. This is valuable behavioral disclosure that helps the agent understand the tool will not create a booking or commit the 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?

Two short sentences, both purposeful and front-loaded. The first states the core function; the second adds scope and behavioral constraints without any 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 tool with a fully described nested schema, the description provides the essential role and constraints: estimate range, quote scope, free, and never bookable. It does not describe the exact output format, but 'estimate range' conveys the primary return concept, and the schema covers all parameter 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 100%, with detailed parameter descriptions already present in the input schema. The description's mention of 'home size + addresses' loosely maps to parameters but adds no new parameter-level meaning, so the baseline score of 3 applies.

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

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

The description clearly states the tool creates an instant estimate range from home size and addresses, with 'Scope: quote' and 'never bookable' helping separate it from booking-oriented siblings. It is specific about the resource (estimate range) and the inputs, though it does not name a sibling explicitly.

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

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

'Free; never bookable. Scope: quote' implies this tool is for the quick quote stage rather than for booking or job creation, which gives the agent useful context. However, it does not explicitly name alternatives like request_booking or quote_inventory, nor 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 indicate this is not read-only and not destructive, so the description does not need to carry that burden. It adds the jobs:write scope and the ordering requirement, which is helpful context, but does not explain error behavior, idempotency, or what happens if parts are 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?

The description is compact and front-loaded: purpose, body shape, timing, and auth scope each get only a short clause. The only structural concern is that 'then call /submit' reads awkwardly and could be misinterpreted.

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

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

For a tool with 3 required parameters and no output schema, the description is too thin on the complete invocation contract. The body snippet omits job_id while the schema requires it, and the relationship between this tool and /submit/submit_job is never clarified.

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

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

Schema description coverage is 100%, so the baseline is 3; the schema already documents job_id, upload_id, parts, part_number, and etag. The description's body example reinforces upload_id and parts but omits the required job_id, which risks confusion even though the schema is complete.

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

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

The description uses a specific verb and resource, 'Assemble a chunked upload,' and includes the request body shape to clarify what the tool does. It is distinguishable from siblings like create_upload_url and submit_job, though it does not explicitly name them.

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

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

The description gives a useful precondition: 'Only after every part has been PUT.' However, the follow-up 'then call /submit' is ambiguous about whether /submit is a separate step or part of this tool's flow, and it does not mention alternatives or when not to use the 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 indicate readOnlyHint=false and destructiveHint=false, and 'Scope: jobs:write' adds a useful permission hint. However, the description does not state whether this is a partial update or what happens to existing inferred values; the informative 'Only these fields are writable; inferred values are kept' appears in the schema, not in the tool description.

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

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

The description is two short, front-loaded sentences with no filler. It delivers the core purpose first and appends a compact scope note, making it appropriately sized and easy to parse quickly.

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 write operation with nested objects and no output schema, the description is a minimal summary: it identifies the target fields and the job context but does not explain the effect of the write or what response to expect. The schema fills in some gaps, but the tool description alone is thin.

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 job_id, origin, destination, and move_date with ranges and writability notes. The description only maps its noun phrase to 'both ends', adding little meaning beyond what the schema already provides.

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

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

The description states a specific action ('confirm') on a clear resource ('floors / elevator / stairs / carry distance for both ends'), so an agent can tell what the tool is about. It does not explicitly distinguish it from sibling tools like set_move_date or report_outcome, but the unique focus on access logistics makes it reasonably distinct.

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

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

The description provides no when-to-use or when-not-to-use guidance, and no sibling alternatives are mentioned. The only extra signal is 'Scope: jobs:write', which is a permission scope rather than a usage rule, leaving the agent to infer applicability from the name and parameters.

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 indicate this is a write, non-destructive, closed-world operation; the description adds that starting a job creates a survey container and that retries are deduplicated via Idempotency-Key. It also discloses the required scope (jobs:write), which is useful behavioral context beyond what annotations alone provide.

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

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

The description is three short sentences with the core action front-loaded, followed by exclusions and a required header. Every sentence earns its place and 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?

For a tool with six parameters, nested objects, and no output schema, the description provides essential operational context: what a job is, what not to send, idempotency behavior, and auth scope. The schema handles parameter detail well, and the description complements it, though exact response behavior is left implicit.

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

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

The input schema already documents all six parameters with detailed descriptions, enums, defaults, and formats, so the description does not need to repeat parameter semantics. It reinforces the idempotency key requirement and excludes contact parameters, but adds little beyond what the schema provides.

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

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

The description uses a concrete verb ('Start') with a clear resource ('a job') and clarifies that a job is the survey container. It is clear about the core action, though it does not explicitly name sibling tools like submit_job or set_contact to differentiate 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?

It explicitly states that contact details are not accepted here and instructs the caller to send an Idempotency-Key to prevent duplicate jobs. This gives useful when/how guidance, but it does not name a specific alternative tool for contact details or for final submission, so the exclusion is implied rather than fully 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?

Beyond the annotations, the description adds critical behavioral disclosure: the raw secret is only returned once ('in THIS response only'), and minting is constrained by the calling key's mode/scope. This materially changes how an agent should handle the response. Minor gaps remain (e.g., response shape, auth requirements), but the added context is substantial.

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

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

Three tight sentences with the core action first, then the most important response caveat, then privilege constraints. No filler or repetition of schema content.

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

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

The description is fairly complete for a mutation with no output schema: it flags the one-time secret, the allowed minting hierarchy, and the scope. It does not spell out the full response object or error conditions, but the essential usage and safety information is present.

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

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

With 75% schema coverage, most parameters already have descriptions. The description adds valuable meaning about the mode/kind relationship ('test key mints only test keys; a live secret key may mint the sandbox pair') and scope restriction ('A key can never mint one broader than itself'), helping the agent choose valid enum combinations beyond what the schema lists.

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 ('Mint') and resource ('a key') and narrows the tool's domain with 'Scope: keys.' This is clearly distinct from sibling operations like list_keys, revoke_key, and rotate_key, so an agent can select it for key creation.

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

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

The description gives clear context for when to use the tool: minting a key in the 'keys' scope. It also provides when-not conditions with 'A key can never mint one broader than itself' and 'a test key mints only test keys,' though it does not name alternative tools explicitly.

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 only minimal annotations (readOnlyHint=false, destructiveHint=false), the description carries the behavioral burden and exceeds it: it discloses the 16 MB branching behavior, the fallback when multipart creation fails, the exact response shape in each branch, the prerequisite contact-email requirement, and the post-upload ETag reporting step. Nothing contradicts 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?

The description is dense but every sentence carries distinct information: purpose, prerequisite, body shape, threshold behavior, follow-up, fallback, scope. It is front-loaded with the core purpose and remains compact given the branching complexity it must explain. A slightly more structured layout (e.g., separating thresholds from follow-up) would earn a 5.

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: it names `multipart` (with upload_id, part_size, presigned PUT per part) and `upload`, plus the fallback behavior. It covers prerequisites, scope, and follow-up. Minor gaps remain: the contents of the single `upload` response are unspecified, and the optionality of `size` in the schema vs its prominence in the description 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%, so the baseline is 3. The description adds genuine meaning above the schema by explaining that size drives the single-vs-multipart decision at the 16 MB threshold, and it restates the body shape. It does not however clarify why size is optional in the schema while the body example lists it, so it stops short of 5.

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 a specific resource and mechanism: 'Presigned upload for the walkthrough video.' This clearly states what the tool produces and for which asset, going well beyond a restatement of the name. It doesn't explicitly contrast itself with the sibling complete_upload or hand_off_video, so it stops short of full sibling differentiation.

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

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

The description gives a prerequisite ('Requires stored contact email'), an auth scope ('jobs:write'), and a clear threshold rule for when multipart vs single upload applies. It also points to the follow-up action ('Report each part's ETag to /upload-complete'). However, it never explicitly states when to use this tool versus an alternative or when not to use it; usage context is strong but exclusions/alternatives are 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=false and destructiveHint=false. The description adds meaningful behavioral context beyond that: the response carries the re-priced quote and the operation requires jobs:write scope. It does not contradict annotations.

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

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

The description is three short clauses, front-loaded with the core action, followed by response and scope. Every sentence earns its place with no filler.

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

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

Given a rich schema that documents all parameters and side effects, and no output schema, the description adequately conveys the tool's purpose and response. It leaves detailed behavioral rules to the schema, which is acceptable.

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

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

Schema description coverage is 100%, including nested oneOf structures, defaults, constraints, and side effects. The description itself adds no parameter-level detail, so the baseline score of 3 is appropriate.

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

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

The description names a specific verb ('Edit'), resource ('inventory'), and the exact operations ('quantity, exclude, add by item_key'). The added note that the response carries the re-priced quote distinguishes it from quote-only or approval siblings.

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

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

The description implies a usage context: edit inventory and receive a re-priced quote. However, it does not explicitly state when to use this tool versus alternatives like quote_inventory or approve_inventory, nor does it provide any exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral nuance: marked-off days are not hard blocks, the mover confirms and calls first, and the agent should prefer open days when possible. This goes beyond the annotations and helps the agent use the data appropriately.

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 compact and front-loaded: the first sentence states the core purpose, the second adds the critical soft-semantics behavioral guidance, and the final scope tag is minimal. Every sentence earns its place with no wasted words.

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

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

For a read-only tool with two optional parameters and a fully documented schema, the description is nearly complete. It explains the soft nature of the data and the quote scope, which is the key usage context. It does not explicitly describe the response format, but 'which days' sufficiently implies a list of dates, and no output schema exists to add further structure.

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

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

Schema description coverage is 100%, so the parameters are already documented in detail, including defaults, formats, and clamping behavior. The description does not add parameter-level detail, but it does not need to given the schema's completeness. Baseline 3 is appropriate.

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

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

The description clearly identifies the tool as returning the days the mover has marked off, and adds helpful context that this is before a job exists. It does not use an explicit verb like 'list' or 'get,' but the meaning is unambiguous. It is distinguishable from sibling tools like get_date_prices or get_job by its focus on mover unavailability.

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

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

The description provides clear guidance on how to interpret results: marked days are soft, can still be requested, and should be steered away from when the customer has a choice. It also scopes the tool to 'quote' context. It does not explicitly name alternative tools, but this is not needed given the clarity of the usage context.

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

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

Annotations already declare read-only and non-destructive behavior. The description adds meaningful context beyond that by specifying the authentication requirement ('Secret key only') and the required scope ('jobs:read'), plus the CSV/Excel output format. For a simple single-job export, this is sufficient.

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 compact and front-loaded, with no wasted words. It states the output, content categories, and access constraints in two short sentences. Every sentence earns its place.

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

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

Given the simple one-parameter input, no output schema, and read-only annotations, the description is complete: it identifies the output format, the data included, and the auth/scope requirements. Nothing essential is missing for an agent to invoke this tool correctly.

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

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

The schema already documents job_id fully with type and description, providing 100% parameter coverage. The description does not add further parameter-level detail, so the baseline score of 3 is appropriate.

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

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

The description names the exact deliverable—an itemized cube sheet as CSV—and enumerates the content fields (rooms, volumes, weights, exclusions). The title reinforces the resource and format, making it clearly distinguishable from sibling tools like get_job or list_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 intended use is implied: call it with a job_id when you need the job's cube sheet as an Excel-ready CSV. It also states access constraints ('Secret key only. Scope: jobs:read.'), but it does not explicitly contrast with alternatives or say when not to use it.

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

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

Beyond the readOnly/destructive annotations, the description adds useful behavioral context: the ~2-week window derivation, the meaning of flat=true, and the required jobs:read scope. This helps an agent understand what the result means and what permission context applies, without contradicting 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?

The description is short and mostly front-loaded, with the main purpose stated first. The flat=true clarification and scope note earn their place. The minor redundancy with the title is not a significant issue.

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

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

The tool is simple with one parameter, and the description conveys the core purpose and the flat flag's meaning. However, there is no output schema and the description does not specify the full response shape, such as how prices are keyed by date or formatted, leaving some interpretation to inference.

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

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

The schema already fully documents the only parameter, job_id, with 100% coverage. The description adds no additional parameter-level detail, but it does not need to since the schema carries the meaning. The mention of flat=true is output semantics, not parameter semantics.

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

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

The description names a specific operation: retrieving a job's quote prices across a ~2-week window based on mover's date rules. It is clear about the resource (job quote prices) and the scope (~2-week window), though it does not explicitly distinguish itself from sibling tools like get_availability or get_job.

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

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

No guidance is given about when to use this tool versus alternatives, nor are any exclusions or prerequisites mentioned beyond the scope line. The usage context is implied by the description, but there is no explicit decision guidance for an agent.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the scope string 'jobs:read' and enumerates the returned data fields, which gives some behavioral context beyond the annotations. However, it does not mention edge behavior like missing job IDs or whether the response is flat or nested.

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

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

The description is extremely concise, front-loading the main point ('Full job state') immediately followed by the specific fields returned. The trailing scope declaration is short and informative. No redundant or filler content appears.

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's field list serves as the return contract and is reasonably complete for a single-job retrieval tool. It covers the key dimensions of job state. It omits error behavior or pagination, but those are less critical given the simple one-parameter input and read-only annotations.

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 job_id described as 'The job's ULID', so the schema fully documents the parameter. The tool description adds no additional param semantics, which is acceptable given the schema coverage. 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 identifies the resource ('full job state') and enumerates its components: status, inventory, quote, access, terms, move_date. It lacks an explicit verb, but the tool name 'get_job' and the required job_id clarify that this is a retrieval operation. It does not explicitly contrast with list_jobs, though 'full job state' implies a single, comprehensive view.

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 about when to use this tool versus alternatives such as list_jobs, get_availability, or quote_inventory. The description only states scope ('jobs:read'), which is permission information, not usage context. An agent would have to infer selection criteria from the name and schema.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the tool returns mover name, branding, and config and restricts scope to quote, but it does not disclose behavior such as what happens for an invalid or missing key.

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

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

The description is very short and front-loads the core action and output fields. It contains no filler, though the 'Scope: quote' fragment is terse and could be more integrated.

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, zero-parameter tool, the description provides enough to invoke it: the purpose, output fields, and scope. It does not specify return shape or error behavior, but the low complexity and existing annotations reduce the need for more detail.

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

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

The tool has 0 parameters, so the empty schema needs no elaboration. Per the baseline for 0-parameter tools, a score of 4 is appropriate; the description's mention of 'the key' is contextual rather than a parameter definition.

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

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

The description uses a specific verb ('Resolve') and identifies the resource ('key' -> 'mover') as well as the returned fields ('name, branding, config'). The 'Scope: quote' fragment narrows applicability, though it is essentially identical to the title and does not explicitly differentiate from sibling tools by 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?

'Scope: quote' gives implied context about when this tool is relevant, but the description does not state when to prefer it over alternatives or provide any exclusions. There is no explicit guidance such as 'use X instead when...'.

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

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

The description discloses behavioral traits beyond annotations: it states the server fetches the URL itself ('We fetch it (up to 500 MB, streamed)'), the job runs exactly like an upload, requires a stored contact email and consent, and mentions rate limiting (429). Annotations only say readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the description adds meaningful context about remote fetch behavior and constraints.

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 information-dense but well-structured: a clear opening statement, followed by key details on fetch limits, equivalence to upload, requirements, replacements, error recovery, and rate limits. While somewhat long, every sentence adds useful information and the most important behavior is front-loaded. The only minor issue is the use of parentheticals ('streamed', 'error') that could be slightly clearer, but overall it's efficient.

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

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

Given the tool's complexity (remote fetch, multiple constraints, rate limits, error handling), the description covers most required context: what it does, when to use it, exclusions, prerequisites, limits, and error recovery. It doesn't explicitly describe the response shape, but there is no output schema, and the description references polling GET /jobs/{id}, which adequately informs the agent of expected flow. Slight gap: it doesn't explicitly state what happens on success besides polling, but this is acceptable.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters thoroughly. The description adds context about how the parameters are used, e.g., 'Needs the stored contact email and consent, like /upload-url' and that 'http' URLs are refused, but it doesn't add significant new semantics beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool's function: 'Server-side handoff: give us a public https URL of the walkthrough instead of uploading it from a browser.' It uses a specific verb ('give us a public https URL') and identifies the resource (walkthrough video). It also explicitly distinguishes from related tools by naming '/upload-url', '/upload-complete', and '/submit' as replaced by this endpoint, which helps an agent distinguish it from siblings.

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

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

The description explicitly states when to use this tool: when the caller 'already holds the file' and wants to skip uploading from a browser. It names alternatives it replaces and provides exclusion criteria: 'Private hosts and http are refused,' and notes that a job with a failed fetch may be handed a new URL. It also states that it 'Counts toward the mover's daily analysis cap (429),' giving clear usage boundaries.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds the domain scoping ('ballpark step', quote) but does not describe return format, ordering, pagination, or other behavioral details. No contradiction.

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

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

The description is extremely short and scannable, and the 'Scope: quote' addition is the only substantive extra over the title. There is minor duplication between title and description, but no wasted 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?

For a parameterless list tool with no output schema, the description would be stronger if it explicitly stated that the tool returns a list of home-profile labels. The examples and scope help, but the return shape is left implicit.

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

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

The input schema has zero properties and zero required parameters, so there are no parameters for the description to document. The baseline of 4 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 identifies a specific resource (home sizes) and a clear context ('ballpark step', 'Scope: quote'), with concrete examples of values. It falls short of a perfect score because it lacks an explicit verb like 'lists'—the action 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?

'For the ballpark step' and 'Scope: quote' provide clear context for when this tool is relevant. It does not name alternatives or state explicit exclusion conditions, so it does not reach the top score.

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

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

Annotations already mark this as read-only and non-destructive, and the description adds valuable behavior beyond that: secret-key-only authentication, jobs:read scope, newest-first ordering, pagination mechanics, and the 400 response for a bad cursor. This gives the agent a strong behavioral model of the call.

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

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

Two sentences, front-loaded with the core purpose, then dense with only actionable constraints. Every clause adds value: auth, scope, ordering, pagination, cursor handling, and error behavior. No filler.

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

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

For a read-only list tool with three optional parameters and no output schema, the description is complete enough to invoke correctly. It covers auth, scope, ordering, paging, cursor source, and error semantics. The absense of an output schema is mitigated by the cursor/paging details.

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

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

The abstract schema documents limit constraints and status enums in detail, while the description adds practical meaning: limit is the page size, status is optional, and cursor comes from the previous response's next_cursor. It does not restate the enum values, but the abstract schema covers those well.

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

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

The description states a specific action ('List jobs'), a clear resource (jobs for the tenant), and an ordering guarantee ('newest first'). This separates it from singular get_job and other list_* sibling tools by resource and plural scope.

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

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

The description gives clear context: secret key authentication, required scope jobs:read, and paging behavior. It does not explicitly name alternatives or state when not to use this 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 non-destructive behavior. The description adds a valuable behavioral disclosure: 'Never a raw secret,' which tells callers that sensitive values are not returned. However, the trailing fragment 'Secret key with the `keys` scope. Scope: keys.' is confusing and seems to reference authentication requirements rather than tool behavior, muddying the added value.

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

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

The first sentence is concise and impactful. The second sentence, however, is fragmented and redundant, repeating 'keys' and 'scope' without clear gain. This prevents the description from being tightly 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?

For a zero-parameter read-only list tool, the description covers the core purpose and the key safety property (no raw secret). It does not specify the exact output fields, and with no output schema that would be helpful, but the low complexity makes the definition adequate.

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

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

The tool has zero parameters, so the schema fully documents the input surface. The baseline for a zero-parameter tool is 4, and the description correctly avoids mentioning parameters that don't 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 explicitly states the verb 'List' and the resource 'API keys', and it goes further to enumerate the coverage dimensions (live/test, active/revoked). This makes the tool's purpose unambiguous and clearly distinguishes it from sibling tools like create_key, revoke_key, and rotate_key.

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

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

No explicit when-to-use or alternatives are stated. Usage is implied by the description and by the sibling tool names, but there is no direct guidance such as 'use this instead of create_key when you only need metadata.'

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 signal read-only and non-destructive behavior. The description adds meaningful behavioral detail beyond that: 30-day retention, newest-first ordering, inclusion of outcome and exact body, and the live-vs-sandbox mode scoping. This gives an agent a clear picture of what the call returns and how it behaves.

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

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

The description is short and front-loaded with the most important information: what the tool returns and the retention/ordering rules. It slightly repeats the `keys` scope by saying 'with the `keys` scope' and then 'Scope: keys,' which is minor redundancy, but overall every sentence contributes useful context.

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

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

Given there is no output schema, the description adequately explains the return content (outcome, exact body), temporal bounds (30 days), ordering, and access mode. It does not mention how pagination or filters shape results beyond what the schema already provides, but for a read-only list tool with a good schema this is 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 descriptions already cover limit/before/job_id/webhook_id at roughly 75%, so the schema carries most parameter meaning. The tool description adds no parameter-level detail and does not explain how filters relate to the log, though it is not misleading. The lack of extra param context keeps this at baseline rather than above.

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

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

The description clearly states the resource (webhook deliveries), the action (list/log), and specific characteristics (30 days, newest first, outcome, exact body sent). It is easily distinguished from the sibling replay_webhook_delivery because it describes read-only inspection of the delivery log rather than re-sending.

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

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

The description gives useful access context: a secret key with the `keys` scope, and live/test mode isolation. However, it never explicitly says when to use this tool over alternatives like replay_webhook_delivery, or when not to use it. Usage is implied by the 'delivery log' framing rather than stated as a decision 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 description adds 'Secret key only' and 'Scope: quote,' but with no output schema and weak annotations, it fails to disclose key behavioral traits like whether the quote is persisted, what the response contains, or how firm-quote pricing is computed. The description carries most of the transparency burden and does not carry it far enough.

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

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

The description is very compact and front-loads the core purpose: 'items or total_cuft in, firm quote out.' The extra fragments 'Secret key only' and 'Scope: quote' add useful constraints without padding. It is slightly telegraphic, but there is no waste.

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

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

Given 8 parameters, nested objects, no required fields, and no output schema, this description is too thin to fully orient an agent. It only names two inputs and an auth constraint, leaving out behavior when both or neither of items/total_cuft are provided, response shape, and how this relates to the rate_card_id, distance, and weight parameters. The schema helps, but the description still leaves significant gaps.

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

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

Schema description coverage is high at 88%, so the schema already documents most parameters. The description's 'items or total_cuft in' highlights the two primary input alternatives, but this is already reflected in the schema descriptions ('Either this…' / '…or this'). It adds no substantial new parameter meaning.

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

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

The description states a clear function: 'Direct pricing for agents: items or total_cuft in, firm quote out.' It specifies both the inputs and the output, and the word 'firm' distinguishes it from sibling tools like ballpark_estimate. This is specific and actionable, not a tautology.

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

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

The description implies use for firm, direct pricing quotes and mentions 'Secret key only' as an access constraint, but it does not explicitly state when to use this tool versus alternatives such as ballpark_estimate or get_date_prices. The 'firm quote' wording provides context but no explicit when-not or alternative routing.

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

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

The description goes well beyond the annotations by disclosing that the body is resent byte-for-byte, the envelope id is preserved for dedupe, a fresh signature is applied, retries happen, the return is the replay's own delivery record, and other-mode deliveries return 404. This is rich behavioral context with no contradiction to 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?

The description is front-loaded with the core action, then efficiently packs the most important behavioral caveats into two sentences. Every clause adds value, and there is no redundant 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 single-parameter tool with 100% schema coverage, the description covers the action, dedupe implications, retries, return value, a key error condition, and scope. It could be slightly more complete by describing the shape of the returned delivery record, since no output schema exists, but this is a minor gap.

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

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

Schema coverage is 100% because the only parameter, id, is described as 'A delivery id from the log.' The description reinforces that it identifies a delivery but does not provide additional parameter-level format, source, or constraints beyond what the schema already states.

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

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

The description opens with a precise verb and resource: 'Re-send one delivery to its endpoint', and explains the exact behavior: same body byte for byte, same envelope id, fresh signature, and usual retries. This clearly distinguishes it from sibling tools like list_webhook_deliveries and key-management tools.

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

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

The description gives useful context about dedupe behavior and the 404 condition for 'other mode' deliveries, but it does not explicitly state when to choose this tool over alternatives or how to obtain the delivery id (e.g., via list_webhook_deliveries). The usage context is implied rather than directly instructed.

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 indicate readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the description still carries some burden. It adds useful auth context ('Secret key only') and names the data being reported, but it does not disclose whether this creates or overwrites an outcome, whether it is idempotent, or what side effects reporting actuals may have.

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

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

The description is extremely short and front-loads the core action. Every phrase is compact, though 'Scope: outcomes' is somewhat redundant with the tool name and the description duplicates 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?

For a mutating tool with five parameters, weak annotations, and no output schema, this description is incomplete. It omits what 'reporting actuals' does to the job, whether fields can be omitted, how the secret key is supplied, and how this differs from related job/submission tools.

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

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

Schema description coverage is 60%, so the schema documents job_id, notes, and actual_total_cents but not actual_hours or actual_crew. The description labels 'hours, final cents, crew', which maps to the undocumented parameters, but adds no units, constraints, or required/optional context beyond their names.

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

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

The description clearly states the verb 'Report' and the resource 'actuals' with specific components (hours, final cents, crew), so an agent can tell what the tool captures. However, it does not explicitly differentiate this from sibling tools like submit_job or ballpark_estimate, even though 'actuals' implies a post-completion action.

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

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

No guidance is provided on when to use this tool versus alternatives such as submit_job or quote_inventory. 'Scope: outcomes' is too vague to serve as a usage condition, and there is no statement of prerequisites or 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?

The description discloses non-obvious behaviors beyond the annotations: idempotency per job, the requirement for a name-as-signature approval, and the storage of a quote snapshot. This adds real context about state and side effects that the annotations alone do not provide.

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

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

The description is compact and front-loaded with the main purpose, followed by essential behavioral constraints and scope. The parenthetical is dense but earns its place by clarifying the signature approval mechanism.

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

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

The description covers purpose, prerequisites, idempotency, and scope, which is solid for a write action. However, with no output schema, it does not indicate what a successful response looks like, and it does not clarify the distinction from closely related sibling 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?

With 67% schema coverage, the schema already documents most parameters, including approve and accept_terms semantics. The description reinforces the approve and accept_terms conditions but adds little new meaning and does not clarify the undocumented email and phone 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 clearly states that the tool requests a booking, using a specific verb and resource. It adds meaningful constraints like idempotency and approval requirements, but it does not explicitly differentiate itself from siblings such as submit_job or approve_inventory.

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 communicates when the tool is appropriate by stating prerequisites: approve must be true, and accept_terms is needed when the mover has terms. However, it does not explicitly name alternatives or describe when not to use this tool, leaving some routing decisions 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?

The description discloses the important behavioral constraint that the session_token must match the one from the original suggestion and that the operation is scoped to quote, which adds context beyond the annotations. It does not explain whether resolving a suggestion consumes it, whether repeated calls are allowed, or what the response contains, but given the annotations it is not a serious contradiction.

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

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

The description is very short and contains no filler. 'Scope: quote' adds a useful constraint, and the session_token caveat is front-loaded. The main structural weakness is that it is a fragmentary phrase rather than a clearly organized sentence, and it repeats the title almost verbatim, but it remains economical.

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 tool with no output schema and limited annotations, the description provides the core purpose, session-token constraint, and quote scope, which is enough to attempt invocation if the agent already has a place_id and session_token from a prior suggestion. It is incomplete about required parameters, return value, and error behavior, so it is adequate but not 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?

With 0% schema description coverage, the description must compensate for the bare parameter names. It partially does: 'suggestion' implies that place_id is a suggestion identifier, and 'same session_token' clarifies that session_token must match the prior suggestion session. It still does not state that both parameters are effectively required or define expected value formats, so the compensation is minimal.

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

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

The description uses a specific verb ('Resolve') and a concrete object ('a suggestion to a full address'), and it adds the key constraint 'same session_token.' In the sibling list, suggest_addresses is the natural counterpart, so the tool's role is fairly clear, though it does not explicitly name that sibling or define what a 'suggestion' refers 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 phrase 'same session_token' and 'Scope: quote' imply that this tool should be used within an active quote session after obtaining a suggestion, and with the same session token used for that suggestion. However, it does not explicitly state when not to use it or point to an alternative for other flows, so usage guidance is mostly implied rather than stated.

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

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

Annotation Contradiction: the description describes revoking a key immediately, which is a destructive, irreversible action, yet destructiveHint is false. This is a serious inconsistency. The description does add useful behavioral details (409 refusal, 403 mode_mismatch), but the contradiction with the annotation forces a score of 1.

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

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

The description is three tight sentences with no wasted words. The main action is front-loaded, and the constraints and error cases are compressed into relevant, scannable clauses.

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 tool without an output schema, the description covers the core behavior, the main edge cases, and the scope. It lacks an explicit statement of what happens on success, but the failure modes are sufficiently detailed and the tool is simple enough that this is a minor gap.

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

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

The schema has 0% description coverage and the only parameter is an undocumented `id`. The description implies that `id` identifies the key to revoke and provides context about key types, but it does not explicitly describe the `id` parameter format or confirm that it is the key identifier. Some meaning is added, but the parameter semantics remain mostly inferred.

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

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

The description clearly states the action ('Revoke a key'), the target resource, and the immediacy/scope ('immediately', 'Scope: keys'). It also differentiates from the sibling rotate_key by explicitly saying 'rotate it instead' for the sole live publishable key.

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

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

The description gives explicit when-not-to-use guidance: the only live publishable key must be rotated, not revoked, and a test key cannot revoke a live key. It names the alternative tool (rotate_key) and the error conditions that should route an agent away from 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?

Beyond the minimal annotations, the description discloses critical non-obvious behavior: the old key stays valid until replaced.expires_at, rotating twice returns 409 key_already_rotated, and during grace the old key is blocked from mint, rotate, revoke, and read deliveries. These are exactly the behavioral consequences an agent needs to anticipate.

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 information-dense and each sentence serves a purpose, but the scope requirement is stated twice ('Needs the `keys` scope even to rotate itself' and 'Scope: keys.'). This minor redundancy prevents a perfect score.

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

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

For a mutation with two optional parameters, no output schema, and no safety-oriented annotations, the description covers the tool's lifecycle, error states, scope prerequisites, and operational restrictions. An agent has everything needed to invoke it correctly without further lookup.

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

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

With 100% schema description coverage, the baseline is 3, and the description does not add new parameter-level meaning beyond the schema. It adds helpful conceptual context about the grace period, but id and grace_hours are already fully documented in the input schema.

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

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

The description opens with a specific verb and resource: 'Replace a key with its twin', and defines the exact shape of the replacement (same kind, mode, scopes, label). This clearly differentiates the tool from siblings like revoke_key (revoke vs. replace) and create_key (create vs. rotate).

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

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

It explicitly states when to use the tool (zero-gap deploy key swap), prerequisites ('Needs the `keys` scope even to rotate itself'), exclusions (only once; test key cannot rotate live key), and an alternative path ('rotate a scoped key with a full key or from the dashboard'). This gives an agent clear routing.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description only needs to add contextual behavior. It adds the 'Scope: quote' constraint and query example, but it does not describe what the search returns, whether results are limited, or any other runtime behavior.

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

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

The description is extremely compact, using two short sentences with no filler. The action, resource, query example, and scope are all front-loaded efficiently.

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

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

For a single-parameter read-only search tool, the core usage is reasonably covered by the schema and annotation. However, with no output schema, the description should at least imply return shape or result semantics; it does not, leaving a real gap.

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

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

The schema already covers q fully with 'Name, synonym or key fragment', so baseline is 3. The description's ?q=sofa only gives a concrete example; it adds minor reinforcement but no substantial new semantic meaning.

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

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

The description clearly states the verb 'Search' and the resource 'cube-sheet catalog', and adds a concrete query example. It does not explicitly contrast itself with siblings like get_cube_sheet_csv, but its search-oriented purpose is still readily identifiable.

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 scope 'quote' gives some contextual direction, and the example ?q=sofa implies usage for searching by name/synonym/key fragment. However, it does not explicitly state when to prefer search_catalog over related tools or mention any exclusions.

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

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

The description discloses a side-effecting behavior (sending email) and adds policy context ('Only on explicit request') plus a permission scope ('jobs:write'). This goes beyond the annotations, which only say readOnlyHint=false and destructiveHint=false, so the agent understands both the action and the consent requirement.

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

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

The description is three short sentences with no filler. The core action is front-loaded, the critical usage constraint follows immediately, and the permission scope is stated compactly.

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 side-effecting action with four parameters and no output schema, the description plus schema gives enough to invoke it correctly: required fields are clear, consent is constrained, and the action is described. It could be more complete by explaining the optional 'name' parameter or return behavior, but those are minor gaps.

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

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

Schema coverage is 50%, and the description partially compensates by implying the 'email' parameter is the customer's email and that 'consent' corresponds to the explicit-request requirement. However, the optional 'name' parameter remains unexplained, and the description adds no direct parameter-level detail beyond what the schema already states.

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

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

The description names a specific action ('Email'), a concrete resource ('their resume link'), and the recipient ('the customer'), so the tool's purpose is immediately clear. It is not a tautology and is distinct from the listed siblings, none of which involve sending resume links.

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 explicit constraint 'Only on explicit request' gives a clear when-not-to-use condition, which is important for an email-sending side effect. It does not name alternatives or provide richer decision criteria, but no sibling tool appears to be an alternative, so the guidance is adequate.

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

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

Annotations already indicate this is a write operation (readOnlyHint=false), so the description's main added value is the explicit 'Sends NOTHING' clarification, which prevents the agent from expecting email dispatch. It does not disclose other behaviors like whether existing contact data is overwritten or what the response contains, but this is acceptable given the simple scope.

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

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

The description is very short and front-loaded, with each sentence adding at least one piece of distinct information: what is stored, that nothing is sent, and the required prerequisite. It could be slightly more structured, but it is efficient and easy to parse.

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

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

Given the moderate parameter count and sparse annotations, the description provides important operational context ('required before upload-url') and a key side-effect clarification ('Sends NOTHING'). However, it does not clarify what happens on repeat calls, whether job_id must reference an existing job, or what the tool returns, which an agent may need to know for correct invocation.

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

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

Schema description coverage is only 60%, and the description mostly repeats parameter names from the title rather than adding semantic detail. It does not explain job_id, consent, or the interaction between move_date and the separate set_move_date sibling tool. The schema covers some fields well, but the description fails to compensate for the gaps.

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

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

The description uses the specific verb 'Store' with a clear resource: customer email, optional name, and move date. It also distinguishes itself from send-related tools by stating 'Sends NOTHING', which helps separate it from siblings like send_resume_link.

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 'required before upload-url' gives useful sequencing context, implying this tool must be called before creating an upload URL. However, it does not explicitly state alternatives or when not to use it, such as preferring set_move_date when only the move date needs updating.

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

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

The description goes well beyond the annotations by disclosing side effects ('invalidates and recomputes the quote'), a refusal condition, and the required scope ('jobs:write'). This is strong behavioral transparency for a mutation tool.

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

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

Two tight sentences deliver the core action, side effects, restriction, and scope without any filler. Every clause earns its place.

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

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

For a simple two-parameter mutating tool with no output schema, the description covers what the tool does, what side effects it triggers, when it is refused, and what permission is required. Nothing essential 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 the schema already documents job_id and date including the null-to-clear behavior. The description adds no extra parameter meaning beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description names a specific verb-resource pair ('Set or clear the move date') and states the consequence ('invalidates and recomputes the quote'). This clearly differentiates it from sibling tools like set_contact or request_booking.

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

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

The description clearly states when the tool is refused ('after a booking is requested'), which is an explicit when-not condition. However, it does not name alternative tools or give broader selection guidance among the large sibling list.

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

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

Beyond the annotations (readOnlyHint=false), the description conveys that the operation is asynchronous and that status must be checked via polling. It also exposes a required auth scope ('jobs:write'). It stops short of describing the full state transition or response shape, but adds meaningful behavioral context.

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

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

Three short sentences, each carrying distinct information: the action, the follow-up, and the required scope. The primary verb is front-loaded with no filler.

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

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

For a one-parameter tool with a clear async workflow, the description is nearly complete: it names the action, gives the polling endpoint, and states the scope. It could be more explicit about prerequisites or how the job_id is obtained, but these are inferable from the workflow and sibling 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 sole parameter job_id is fully described in the schema as a ULID, so schema coverage is 100%. The description does not add parameter-level details beyond the schema, matching the baseline for well-documented parameters.

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

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

The description opens with a specific verb and resource: 'Queue the uploaded video for analysis.' It clearly identifies the operation and distinguishes it from upload/complete actions, though it does not explicitly name a sibling or state what this tool is not.

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

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

It provides the next step ('Poll GET /jobs/{id} for status') and implies the tool is used after a video is uploaded. It doesn't explicitly list when not to use it or name alternatives like create_job, but the async workflow context is present.

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

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

The description discloses that the tool is 'proxied' and instructs sending a session_token, which adds useful context beyond the annotations about an external address service and persistent session state. However, it does not explain side effects, rate limits, or data handling details, so the disclosure is only partial.

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

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

The description is very short and contains no filler. The key constraints (proxied, session_token, quote scope) are front-loaded. However, it closely mirrors the title and lacks enough substantive content to be considered a fully crafted description.

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

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

There is no output schema and the description does not describe the return value shape or the expected suggestion list format. It also fails to mention the natural follow-up call to resolve_address or explain how to obtain the session_token. An agent would struggle to integrate this into a complete autocomplete flow.

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

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

The input schema already documents both parameters clearly: input is what the customer typed, and session_token is an opaque string kept for the session. The description only repeats the instruction to send session_token and does not add any meaningful new meaning beyond the schema.

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

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

The description clearly identifies the tool as an address autocomplete function and adds a scope restriction ('quote'), which gives an agent a basic sense of purpose. However, it does not explicitly differentiate this from the sibling resolve_address, relying on the tool name to imply the distinction.

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

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

The description provides almost no guidance on when to use this tool versus alternatives. 'Scope: quote' hints at a contextual boundary but does not explain when to prefer suggest_addresses over resolve_address or how the two interact. There are no exclusions or explicit conditions.

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