SatelliteQuotes

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

Annotations only declare it is a non-read-only, non-idempotent, open-world write; the description goes further and discloses the whole behavioral arc: no password/card required, an emailed set-password link, widget activation gated on sign-in (email confirmation), and leads retained until a card is added. That is exactly the context annotations cannot carry.

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

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

Front-loaded with the action and the return values, then the free/trial economics, then the eligibility constraint. It is dense but every clause carries a distinct fact; the pricing parenthetical is slightly incidental but not wasteful.

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

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

With no output schema, the description still names what is returned, covers the multi-step onboarding that follows the call, and states the eligibility gate before an agent commits to an irreversible, non-idempotent write. Nothing needed to call it correctly is missing.

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

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

Schema description coverage is 100%, so the schema already documents all six parameters and their optionality. The description adds only the accepted-email constraint tied to owner_email and the real-business-email requirement; it does not explain the trade taxonomy or service_area format, so the baseline 3 is appropriate.

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

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

States a specific verb+resource ('Creates a contractor account') and immediately names the artifacts returned (widget token and embed tag), routing the agent to the sibling get_install_snippet. It is clearly distinguishable from estimate_cost, get_pricing, or list_trades.

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?

Explicit when-to-use and when-not: only when the person owns the business or asked for the setup, with their real business email, and it refuses test/disposable/placeholder addresses. That is a concrete selection condition and a hard exclusion, not implied 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, the description carries the behavioral transparency burden. It does this well by disclosing the tool's output components (range, per-unit rates, price drivers, estimate limits) and the automatic roof surface multiplier behavior. It does not mention data sources or exact calculation assumptions, but for a read-only estimation tool this is reasonably transparent.

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 sentences with no filler: it front-loads the core purpose, then adds the critical roof-trade special case, then summarizes return value. Every sentence contributes.

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 appropriately summarizes the return content. It covers the main input behavior, the roof-specific nuance, and what the caller gets back. It does not explain how to choose between this and get_pricing, but for invoking this tool correctly with the provided schema, the description 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 description coverage is 100%, so the baseline is 3. The description adds meaningful semantic value beyond the schema by clarifying that for roof trades, measurement is the building footprint and that pitch feeds into an automatically applied surface multiplier. This elevates the parameter understanding beyond raw field definitions.

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 operation: turns a measurement into a national cost range for a trade, with a clear roof-trade special case. It is clear and actionable, but it does not explicitly distinguish itself from the sibling get_pricing, so it falls just 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 clear context for when to use the tool (estimating cost from a measurement) and provides concrete usage guidance for roof trades, explaining how to pass footprint and pitch. It does not explicitly name alternative tools or state when not to use it, so it lacks exclusions but still offers solid contextual 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, the description carries the full burden, and it does disclose real behavior: without a token the snippet is returned with a placeholder plus instructions for finding the real one. That fallback behavior is not derivable from the schema. It still omits explicit read-only/side-effect framing and any note that omitted platform yields a generic snippet.

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 what comes back, then the one conditional that matters for invocation. No filler and nothing buried.

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

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

No output schema and no annotations, so the description must explain the return, and it does (script tag plus ordered steps) along with token fallback behavior. The remaining gap is minor: it doesn't state that omitting platform yields the generic snippet, and it says nothing about permission or read-only characteristics.

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

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

Schema coverage is 100% and each parameter has a substantive description, so the baseline is 3. The description reinforces the token fallback semantics ('placeholder and instructions') and ties platform to the returned steps, but adds little beyond the schema's own wording.

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 specifically what is returned: the exact script tag plus ordered steps for a given platform. Makes the resource (install snippet) and the two outputs (tag and steps) unambiguous. It does not name or contrast with siblings such as list_platforms or verify_installation, so it stops short of a 5.

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

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

The description gives conditional guidance only for the token input ('pass the contractor's own token if you have it; otherwise...'), which is really parameter handling rather than when-to-use. There is no explicit statement of when to call this versus list_platforms or verify_installation, so usage is implied rather than directed.

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. It discloses the tool's informational nature and that prices are 'live', implying a non-cached read. However, it doesn't state the return format, whether any side effects occur, or that it's read-only. For a zero-parameter lookup tool, this is adequate but not exhaustive.

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

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

Two sentences with no filler. The key content (prices, trial length, card handling, cancellation) is front-loaded, and the usage hint adds value without redundancy. It is efficiently structured and easy to scan.

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

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

For a parameterless tool with no output schema or annotations, the description covers the essential information an agent needs: what data is available and the caveat to use live data. It doesn't specify return type or structure, but for a simple lookup this is not a significant gap. The description is sufficient for correct invocation.

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

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

The tool has zero parameters, so the baseline is 4. There is nothing to explain about parameters, and the description correctly focuses on the content rather than any input semantics. No additional parameter detail is needed.

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

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

The description clearly states the tool retrieves live plan prices, trial length, card handling during trial, and cancellation terms. It specifies the resource (pricing) and the exact content, and the closing phrase 'Read this rather than quoting a price from memory' gives a concrete use case that distinguishes it from estimate-oriented tools like estimate_cost.

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 when to use it: whenever current pricing or trial details are needed, explicitly cautioning against relying on memory. It doesn't name alternatives or exclusions, but the context makes the appropriate use clear, especially given the sibling list includes estimate_cost for estimates.

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 of explaining what the tool returns. It reveals that the playbook contains steps with underlying numbers, which is useful, but it never explicitly states that this is a read-only retrieval or what the response format looks like. For a content-retrieval tool this is acceptable, but not richly transparent.

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, tightly scoped sentence with no filler. It front-loads the value proposition and enumerates the trades efficiently, though it is a noun phrase rather than a full imperative sentence. Every word contributes to conveying scope and 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?

For a single-parameter, no-output-schema tool, the description conveys the essential context: the problem it addresses, the trades it covers, and the nature of the deliverable. The schema handles the allowed values and default. It would be marginally stronger if it mentioned the 'general' fallback trade or response format, but nothing critical blocks correct invocation.

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

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

The schema already documents the single trade parameter at 100% coverage, including allowed values and the default behavior. The description repeats some trade names but adds little beyond contextual framing around contracting trades. Since schema coverage is high, 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 title states the action and resource clearly: 'Get a lead-generation playbook for a trade.' The description adds specific scope — inbound lead generation for contracting trades such as roofing, paving, and solar — and distinguishes this from pricing, estimation, and installation tools among the siblings. It lacks an explicit verb in the description itself, but the intent is unambiguous.

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

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

The description implies when to use the tool: when the agent needs a lead-generation playbook for a specific contracting trade, with quantified steps. However, it does not explicitly discuss when not to use it or compare it to alternatives like list_trades or get_pricing. The use case is clear enough, but there is no explicit routing 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes the returned content (list of platforms and time estimates) but does not explicitly state that this is a read-only operation or describe any limitations, pagination, or data source behavior. For a simple list tool this is adequate but not rich.

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 compact sentence that front-loads the tool's purpose. The grammar is slightly awkward ('The website builders and CMSs there are...'), but it conveys all key information without unnecessary 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?

With zero parameters and no output schema, the description covers the key facts: what is listed (platforms with install instructions), the time information, and when to invoke it. It could be more explicit about the return format, but it is sufficient for an agent to call it appropriately.

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 baseline is 4. The description need not discuss parameter details, and it doesn't.

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 lists website builders and CMSs that have step-by-step install instructions, along with install duration. The scope is specific and easily distinguished from siblings like get_install_snippet, get_pricing, and verify_installation.

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 explicit guidance: 'Call this first when you do not know what the contractor's site is built with.' This gives a clear trigger and ordering but does not explicitly name alternatives or when-not-to-use scenarios, so it falls slightly short of a perfect 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?

No annotations are provided, so the description must carry the burden of behavioral disclosure. It explains what the tool lists (trades) and the type of information included (measurement basis and cost ranges), but it does not disclose potential side effects (likely none, read-only), performance, or any error conditions. For a read-only listing tool, this is adequate but not rich.

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 sentences: the first states the tool's output and content, the second gives a clear use case. Every word earns its place, no fluff, and the key information (what it lists and how to use it) is front-loaded.

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

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

For a simple listing tool with one optional parameter and no output schema, the description is complete enough to guide an agent. It explains what is returned (trades, measurement basis, cost ranges) and the use case. It might lack detail on the exact structure of output, but for a list tool that is acceptable. The sibling tools are distinct, so the context is well-covered.

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

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

The schema documentation already covers the parameter 'search' (optional trade name or synonym) with examples. The description does not add much beyond what the schema says, but it implies the search is for filtering trade names. Given 100% schema coverage, the description's marginal addition (that the list can be filtered to answer specific queries) still adds value by setting expectation that search is optional and for lookup.

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 purpose: it lists trades that can be quoted from satellite imagery, along with what each is measured from and cost ranges. It distinguishes itself from siblings by focusing on the list of priceable trades rather than cost estimation or other functions.

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 guides when to use the tool: to answer whether a given business can be quoted this way. It does not name specific alternative tools, but the phrase 'Use this to answer whether a given business can be quoted this way' implies it should be used before estimating costs or getting pricing, providing clear context without exclusions.

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

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

With no annotations, the description carries the full burden. It discloses the operational behavior: fetching a public page, checking several conditions, and providing what to fix. It implies a read-only network operation and does not mention side effects, authentication, or rate limits, but for a verification tool these are reasonably implied. The description adds value beyond a mere 'checks installation' by enumerating the checks.

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 sentences: one states the purpose and the checks, the second gives usage guidance. It is front-loaded with the action and outcome, with zero filler. Every word 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 no output schema, the description provides a useful preview of the result by listing what it reports (embed tag presence, token validity, serving status, and fixes). It doesn't specify error handling or edge cases (e.g., invalid URL, network failure), but for a single-parameter read-only tool this is adequate. Slightly more detail on output format would push it to 5.

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

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

The schema covers the only parameter (url) with a clear description ('The public page URL to check.'), and coverage is 100%. The description does not add extra details like URL format requirements or validation rules, so it stays at the baseline of 3 – the schema already does the heavy lifting.

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

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

The description uses a specific verb ('fetches' and 'reports') and names the resource (public page) plus the exact checks performed (embed tag presence, token validity, widget serving, and remediation steps). It clearly distinguishes from siblings like get_install_snippet (which returns the snippet, not verification) and estimate_cost/list_trades (unrelated). The purpose is unambiguous.

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

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

The description gives an explicit trigger: 'Use this after the contractor says they have pasted the tag.' This tells the agent when to invoke it. It does not explicitly name alternatives or state when not to use it, but the sibling set makes the context obvious (get_install_snippet is for obtaining the tag, not verifying it). The use case is clear enough for a 4.

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