site

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

No annotations are provided, so the description carries the full behavioral burden. It only describes content ('criteria and any filters') and does not disclose whether the operation is read-only, what the output format is, or any side effects. It is not misleading, but it is very thin.

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

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

The description is a single sentence with no filler, but the grammar is awkward ('of the Where nearshoring wins, and where it does not comparison') and the comparison name is not clearly delimited. It is concise in length, but the structure hurts clarity.

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

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

With no parameters and no output schema, a short description can be sufficient, and the sentence does identify the content domain. However, it does not explicitly state that the tool returns or describes the criteria, leaving basic call semantics to inference. This is nearly adequate for a zero-input info tool but not complete.

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

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

The tool has zero parameters and an empty input schema, so there is no parameter meaning for the description to clarify. The baseline of 4 for a zero-parameter tool applies.

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

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

The description identifies the tool as exposing the criteria and filters for a specific comparison ('Where nearshoring wins, and where it does not'), which is a meaningful resource and somewhat distinguishes it from compare_options and compare_table. However, it lacks an action verb and is phrased as a fragment rather than a clear operation, so an agent must infer the intended 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 given about when to use compare_criteria versus compare_options or compare_table. The description only names the content; it does not state conditions, exclusions, prerequisites, or alternatives.

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

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

With no annotations, the description must disclose behavior on its own. It states the output fields and that tag filtering is optional, which gives a basic picture of the operation. However, it does not say whether the operation is read-only, how tags are matched, or whether filterKey and filterValue must be supplied together.

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

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

The description is a single sentence with no filler, and the core resource and fields are stated up front. The phrasing is somewhat awkward ('where it does not comparison'), but it remains concise and scannable.

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

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

For a tool with no output schema, no annotations, and undocumented parameters, the description omits key call details: the meaning of filterKey, how filter values are formatted, and how this tool relates to the sibling comparison tools. The returned fields are listed, but the invocation contract is incomplete.

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

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

Schema description coverage is 0%, so the description must compensate. It explains that filtering is by tag value, which partially describes filterValue, but filterKey is never explained and no allowed values or semantics are given.

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 ('the options in the Where nearshoring wins... comparison') and the returned fields (name, best-for, tags), so an agent can tell it returns option data. However, it lacks an explicit verb like 'list' or 'get', and it does not distinguish itself from siblings such as compare_table or compare_criteria.

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

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

There is no guidance on when to use this tool instead of compare_criteria, compare_table, or the enquiry tools, and no mention of exclusions or prerequisites. The only usage hint is that filtering by tag is optional, which is not enough to route 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?

No annotations are provided, so the description must carry the behavioral burden. It clearly describes the table's content and scope, which is useful. It does not disclose output format, how the optional option parameter affects results, or whether any filtering or defaulting occurs beyond what the schema indicates.

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

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

The description is a single sentence with no filler and the core idea is front-loaded. However, the phrase 'Where nearshoring wins, and where it does not comparison' is syntactically tangled and reduces immediate readability.

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

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

For a tool with one optional parameter and no output schema, the description conveys the primary return content well. It still leaves some gaps such as what happens when option is omitted versus explicitly given, and what the table structure looks like, but the schema covers the parameter part adequately.

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

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

Schema description coverage is 100%, with the option parameter documented as 'one option's name, else all'. The description reinforces that each option has a value on every criterion but adds no new semantic detail beyond the schema.

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

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

The description states the tool's output: a full table showing each option's value on every criterion. This separates it from siblings like compare_criteria and compare_options, which likely show focused subsets. The wording is awkward and lacks an explicit verb like 'returns', but the intent is clear.

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

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

There is no explicit statement about when to use this tool versus compare_criteria or compare_options. The phrase 'full table' implies it is the exhaustive comparison view, but the agent must infer the exact routing decision from tool names and this single phrase.

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

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

With no annotations, the description carries the full burden and it does well: it states nothing is bought/ordered/paid, no quote is guaranteed, it is free, and it returns the recipients, consent wording, and confirmation method. It does not explicitly declare itself side-effect-free, but 'States plainly what submit_enquiry does' implies a descriptive read-only role.

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, front-loaded with 'Read first', and each sentence adds relevant information about scope, exclusions, or return content. It is concise, though it slightly repeats the title's 'not a purchase, not a guaranteed quote' phrasing.

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 informational tool with no output schema, the description is complete enough: it states the topic, the constraints, and the key returned details. It could be more explicit about exact return formatting, but the absence of an output schema makes the description's level 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?

The tool has zero parameters and the schema is empty (100% coverage by default), so the baseline is 4. The description adds useful context about the informational content returned, though there are no parameters to document.

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

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

The description uses a specific verb ('States plainly') and identifies the resource ('what submit_enquiry does on Nearshore Finder'), making clear this is an informational description rather than the submit action itself. It is distinguishable from siblings like submit_enquiry, but it does not explicitly differentiate from the other descriptive sibling enquiry_fields.

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?

'Read first' explicitly tells an agent to consult this before acting, and the description clarifies the scope (an enquiry, not a purchase or guaranteed quote). It does not explicitly name when to choose this over other tools, but the 'Read first' instruction provides practical usage direction.

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

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

With no annotations, the description carries the behavioral disclosure burden. It clearly states that the tool returns all field metadata and implies a read-only, non-submitting nature by instructing the caller to pass answers separately to submit_enquiry. It does not go into exhaustive detail about output format or edge cases, but for a simple metadata listing it is transparent 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?

Two tight sentences earn their place: the first delivers the full scope of the returned data, the second connects it directly to the next action (submit_enquiry). No filler, no repetition of the tool name, and the key usage hint is front-loaded enough.

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 zero-parameter tool with no output schema, the description explains what the output contains and how the output should be used. It gives an agent everything necessary to call the tool and correctly feed results into submit_enquiry. No critical context about return shape or behavior 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?

The tool has zero parameters and the schema is trivially covered at 100%. The baseline for zero parameters is 4. The description adds a valuable usage note about keying answers by field key, which helps the agent understand how the returned metadata plugs into the sibling tool, even though it does not document any parameters.

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

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

The description names a specific verb (enumerate/describe) and a concrete resource: every field of the Nearshore Finder enquiry. It goes beyond a label by spelling out exactly what is included (key, label, type, required, help text, allowed options), and it distinguishes itself from submit_enquiry by explaining how the fields are meant to be used as keys for submission.

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 contextual guidance: an agent should retrieve these field definitions before calling submit_enquiry, and answers must be keyed by field key. However, it does not explicitly mention alternatives such as enquiry_describe or state when not to use this tool, so it falls short of full when/when-not guidance.

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

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

With no annotations present, the description carries the full burden and delivers richly: it discloses that step 1 is non-committal validation, that step 2 triggers an email with a click-before-delivery gate, that providers see nothing until the link is clicked, and it quotes the exact consent language. This fully compensates for the missing 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 long but every sentence carries operational necessity: exclusions are front-loaded, steps are clearly labeled, and the verbatim consent line is essential for a compliance-sensitive tool. Slight redundancy exists in restating consent in both the consent parameter description context and the body, but overall it is dense rather than padded.

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

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

For a complex two-step mutation tool with no output schema and no annotations, the description is remarkably complete: it covers return values of step 1 in prose, the consent requirement, the post-submission email flow, and the prerequisite linkage to enquiry_fields. The only omissions, such as validation-failure behavior and token expiry, are minor and outside the core call sequence.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds genuine workflow meaning beyond the schema by explaining which parameters belong to which step, that confirmation is the token returned from step 1, and that answers are keyed by field key from enquiry_fields. This exceeds baseline but stops short of fully documenting per-parameter edge cases.

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 plus resource — 'Submits an enquiry to Nearshore Finder' — and immediately sharpens the scope with 'NOT a purchase, NOT a guaranteed quote.' This distinguishes it clearly from the sibling compare_* and enquiry_* tools, so an agent can select it confidently.

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 two-step workflow is spelled out with explicit sequencing: call once with answers and consent=true to obtain a token, show the summary, then call again only if the person agrees. It also provides a hard condition for step 2 ('only if the person agrees') and routes the agent to enquiry_fields for the answer keying, which is effective alternative guidance.

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