GroundQuote

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

No annotations are present, so the description carries the full behavioral burden. 'Shows'/'check' implies a non-mutating read, and it usefully discloses what fields come back (setup_link_pending, pricing, branding, install details), but says nothing about what setup_claim represents, authorization requirements, or error behavior when the claim is invalid.

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 purpose and then the prerequisite. No filler, though the parenthetical field name placement is slightly awkward.

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 partially offsets that by naming the returned sections. However, with no annotations and 0% parameter coverage, an agent still cannot determine what to pass for setup_claim or how failures are surfaced.

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

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

Schema description coverage is 0% for both parameters, so the description must compensate and it does not. It restates that org_id and setup_claim are required (already in the schema's required list) but never explains what setup_claim is — a token, an ID, a signed claim string — which is the key ambiguity for correct invocation.

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 ('Shows') and enumerates the concrete resources returned: password-setup state (setup_link_pending), pricing summary, branding, and install details. It implicitly differentiates from narrower siblings like get_pricing_terms and get_install_instructions by bundling them, though it never names those siblings explicitly.

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

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

The only guidance is 'Requires org_id and setup_claim', which is a prerequisite, not a when-to-use rule. Nothing says when to call this versus get_pricing_terms, get_install_instructions, or resend_setup_email, even though the password-pending signal is clearly the precursor to a resend decision.

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 and does so: it discloses the outbound email, that the pricing terms are embedded in it, that nothing is charged and no card is required, the returned fields, and that setup_claim must be retained for later calls. Those are non-obvious side effects and state-handoff requirements that no structured field conveys.

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 side effect, then cost reassurance, then return values and the setup_claim handoff, then preconditions. Four dense sentences with no filler or repetition.

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

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

With 8 parameters, no annotations and no output schema, the description compensates by enumerating return values and the retention requirement for setup_claim. An agent has everything needed to call it correctly and to chain follow-up 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 coverage is 88%, so the schema already documents nearly every parameter including owner_email and the terms_relayed const. The description adds little parameter-level detail beyond restating the owner_email rule and reinforcing that terms_relayed requires confirmation, so the baseline 3 applies.

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

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

States a specific verb and resource ('Creates a GroundQuote account for a fence contractor') plus the immediate side effect (emails a set-password link containing pricing terms). It also names the exact downstream tools that consume setup_claim, so an agent can distinguish it from the read/set siblings without opening any schema.

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

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

Explicit preconditions are given: confirm the contractor has heard the pricing terms before calling, and use the contractor's own email as owner_email. It also documents the post-call sequence by naming set_fence_pricing, set_branding, set_hosted_page, get_embed_code, check_account_status and resend_setup_email as consumers of setup_claim, which is exactly the when/how guidance an agent needs.

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 disclosure burden. It does communicate the return payload ('full text'), which implies a read-only retrieval, but says nothing about error behavior for invalid ids, permissions, rate limits, or the size/format of the returned text. Adequate but with clear gaps for a tool with zero annotation coverage.

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

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

A single sentence, front-loaded with the verb and return value, with zero filler. Nothing could be removed without losing meaning.

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, non-nested tool with no output schema, the description covers purpose, input provenance, and what comes back. The remaining gap is failure handling for bad ids and any note on the returned text's scope, which keeps it from being fully complete in the absence of 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 0%, so the schema only says 'id' is a string. The description compensates on the most important point: the id originates from a prior 'search' call, which is exactly the semantic an agent needs. It still gives no format, example, or validity constraints for the id, so compensation is partial.

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

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

States a specific verb ('Returns') and resource ('full text of a documentation entry'), with the key distinguishing detail that the entry is addressed by an id obtained from search. That separates it from the sibling 'search' tool, which locates entries rather than returning them. It falls short of 5 only because the name 'fetch' alone is generic and the differentiation is implied rather than stated.

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

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

The phrase 'id from search' implies the intended two-step workflow (search first, then fetch), which is useful guidance. However, it never explicitly says when to use this instead of 'search', nor what to do if the id is unknown or the entry is missing. Usage is inferable but not spelled out.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the return content (iframe HTML and hosted-page URL) and implies a read-only retrieval operation, but it omits explicit behavioral details such as permission requirements, error conditions, or idempotency. This is minimally 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 short sentences and front-loads the return value. The second sentence is somewhat redundant with the schema's required fields, but overall it is efficient 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 tool with no annotations, no output schema, and 0% parameter description coverage, the description is incomplete. It covers the return value briefly but leaves the meaning of both required parameters and any relevant behavioral context unexplained.

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

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

Schema description coverage is 0% and the description only says 'Requires org_id and setup_claim.' It adds no meaning about what either parameter represents, expected format, or how setup_claim is obtained. The schema itself only provides type/format, so the description fails to compensate.

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

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

The description uses a specific verb and resource: it 'Returns the iframe HTML' and 'hosted-page URL.' An agent can clearly tell this tool produces embed code. It does not explicitly distinguish itself from siblings like get_install_instructions or set_hosted_page, which keeps it from 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 only usage information is 'Requires org_id and setup_claim,' which restates required schema fields. There is no guidance on when to call this tool versus alternatives such as get_install_instructions or set_hosted_page, and no conditions or exclusions are provided.

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 exist, so the description carries the full burden. "Explains" signals a read-only informational tool and the topic list implies the content returned, but there is no statement about permissions, account scoping, or whether the answer varies by account state — relevant given siblings like check_account_status and create_contractor_account.

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, no filler. The content scope comes first so the agent knows what it will learn, and the usage trigger follows. Every clause earns its place.

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

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

With no output schema, the description must convey the shape of the answer, and it does so by listing the three topics covered. What is missing is any note on account-conditional behavior — an agent cannot tell whether the answer differs by contractor or plan tier.

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

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

The tool takes zero parameters, so there is nothing to disambiguate. Baseline 4 applies; the description correctly spends no space on argument syntax.

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

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

The description names a specific resource — install instructions — and enumerates the exact topics covered: the two install paths (iframe embed vs. GroundQuote-hosted page), AI site-builder compatibility, and account ownership. That is concrete and distinguishable from implementation siblings like get_embed_code and set_hosted_page, though it never names those siblings to sharpen the boundary.

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

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

"Use before you promise the contractor anything about the install" gives a clear triggering condition and an implicit caution against answering install questions from memory. It stops short of naming alternatives (e.g., use get_embed_code once a path is chosen), so the routing is implied rather than explicit.

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

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

With no annotations, the description carries the full burden and does well: it discloses the return content, the billing behavior ('nothing charged until the contractor unlocks a lead'), and that the call takes no inputs, implying a safe read. It stops short of stating auth requirements or explicitly declaring the call is side-effect free, which keeps it from a 5.

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

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

The imperative 'Read this first' is front-loaded before any detail, and every clause — pricing breakdown, guarantee mention, no-input note — adds usable information. 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?

With no output schema, the description usefully summarizes the returned disclosure and guarantees, which is enough to call it correctly. Minor gaps remain around the response format and auth requirements for a public-facing pricing read.

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

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

Zero parameters, so the baseline is 4; the description's 'No inputs' is consistent with the empty schema. Nothing further 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?

States a specific verb and resource ('Returns the plain-language pricing disclosure') and enumerates the exact content ($5 browsing lead, $15 high-intent lead, optional $150/month unlimited) plus the guarantees. This is clearly distinguishable from siblings like set_fence_pricing, which configures pricing rather than reading the disclosure.

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

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

Gives an explicit sequencing rule: 'Read this first and relay it to the contractor before creating an account,' which pins it to the create_contractor_account step. The condition that selects this tool is stated outright with no inference required.

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 add one genuinely useful behavior: a rate cap of 3 per day per account. However, it omits what happens at the cap (error vs. silent no-op), whether previously issued links are invalidated, and any auth/permission requirements for the caller.

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

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

A single front-loaded sentence with the rate limit parenthetically placed; nothing is buried. The trailing 'Requires org_id and setup_claim' clause is redundant with the schema's required list and slightly dilutes the otherwise tight 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 no-annotation, no-output-schema mutation tool with 0% parameter documentation, the description should explain the setup_claim source, error behavior at the rate limit, and side effects on prior emails. It supplies only the rate cap, leaving an agent unable to invoke this correctly on the first try without guessing.

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 and it largely doesn't: 'Requires org_id and setup_claim' only restates the required array. The critical opaque parameter 'setup_claim' — presumably the claim/token from account creation — is never explained, nor is its format or where an agent obtains it.

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

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

Specific verb+resource: 'Re-sends the contractor's set-password email', which is clearly distinct from siblings like create_contractor_account or check_account_status. It doesn't explicitly name the sibling it relates to (the account-creation flow), but the action itself 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?

Usage is implied by context (a contractor who hasn't completed setup), but the description never states when to prefer this over checking account status first or re-inviting via create_contractor_account. No exclusions or preconditions beyond org_id/setup_claim are given.

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

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

With no annotations at all, the description carries the full burden, and it does disclose the return contract shape (ids for `fetch`), which is the most important behavioral fact here. It says nothing about whether results are ranked, how many come back, whether matching is keyword or semantic, or what happens when nothing matches.

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

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

One tightly packed sentence plus one sentence on the return contract; nothing is wasted and the core purpose plus coverage list is front-loaded. The parenthetical topic list earns its space by telling the agent what the corpus contains.

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 no annotations, so the description is the only source of truth, and it covers the essentials (purpose, corpus scope, id-based return). It falls short on result cardinality, ranking/matching behavior, and empty-result handling — details an agent would want before relying on it in a loop.

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

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

The single `query` parameter has 0% schema description coverage, so the description must compensate. It partially does by listing the documentation topics the query can target, which tells the agent a natural-language query is acceptable, but it gives no format, phrasing, or scope guidance (e.g., one topic per call vs. compound queries).

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

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

The description names a specific verb and resource (searches GroundQuote's documentation) and enumerates covered topics — what it is, pricing, install, ownership, pricing format, rules for assistants — so the generic tool name 'search' is disambiguated. It also distinguishes itself from the sibling `fetch` by stating it returns ids to pass along.

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 workflow handoff ('Returns ids to pass to fetch') implies the intended two-step pattern, which is genuinely useful guidance. However, it never says when to prefer this over topical siblings like `get_pricing_terms` or `get_install_instructions`, which overlap heavily with the listed coverage areas — that ambiguity is left entirely to the agent.

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

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

With no annotations at all, the description carries the full burden. It usefully discloses the precedence rule (explicit fields win over fetched values) and that org_id plus setup_claim are mandatory, but says nothing about permissions/authorization semantics, whether re-applying overwrites existing branding, or whether setup_claim is a one-time token.

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

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

Two tight sentences, front-loaded with the effect, then the conditional fetch behavior, then required inputs. No filler and nothing repeated from the schema.

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

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

For a 9-parameter mutation tool with no annotations, no output schema, and zero schema descriptions, the description is helpful but only partially sufficient — an agent would still be guessing about several color/URL parameters and about auth semantics for setup_claim.

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% across 9 parameters, so the description must compensate. It explains the least intuitive parameter (auto_fetch_from_url) and its interaction with explicit values, plus flags the two required fields, but leaves website_url, accent_color, secondary_color, and the meaning/source of setup_claim undocumented.

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

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

States a specific verb (sets) and resource scope (logo, colors, font on the quote widget), so the effect is unambiguous and clearly distinct from siblings like set_hosted_page and set_fence_pricing. It doesn't explicitly name a sibling, but the resource is narrow enough that the boundary is obvious.

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

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

Gives one conditional usage path — pass auto_fetch_from_url to derive branding from an existing site — which is genuinely useful routing. However, it states no exclusions, no prerequisites beyond naming the required fields, and no advice on when to prefer explicit values versus fetching.

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 burden and does so well: it discloses that each call replaces the entire fence catalog (a destructive full-overwrite trait the agent must know), and that credentials come from create_contractor_account. It doesn't mention validation failure behavior or whether a partial catalog is acceptable, which keeps it from a 5.

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

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

Five short sentences, front-loaded with the data-shape explanation, then the guardrail, then the overwrite warning. Almost no waste; the opening 'Loads the contractor's price list' is the only line that could be tightened or made more precise.

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 7-parameter nested write tool with no output schema, the description covers what matters most: the nesting order, gate surcharge model, full-replacement semantics, and the auth prerequisite. Gaps are secondary (error behavior, handling of omitted optional fields) but not blocking for correct invocation.

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

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

Schema coverage is 71% and the description largely restates the schema's own 'material -> style -> height -> dollars per linear foot' description. 'Gates are flat surcharges' echoes the per-field schema descriptions rather than adding format or constraint detail, and the optional removal_per_ft_usd 'omit to leave unchanged' semantics and require_phone default are never addressed.

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

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

States the resource (contractor's fence price list) and the shape of the data (rates by material/style/height, gates as flat surcharges). The verb 'Loads' understates that this is a write operation, but the later sentence 'Replaces the whole fence catalog each call' removes the ambiguity. Sibling set_* tools (set_branding, set_hosted_page) are clearly different domains, so no confusion there.

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

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

Gives a clear operating rule ('Ask the contractor for real numbers; never invent them') and states the prerequisite chain back to create_contractor_account for org_id and setup_claim. It stops short of naming when not to use it or how it relates to get_pricing_terms, so an explicit alternative path is missing.

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 behavioral disclosure. It says the tool turns on a page and requires org_id and setup_claim, but it does not explain permissions, side effects, idempotency, what happens if the page is already enabled, or whether it can also disable the page via the enabled parameter.

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 tight sentences with no filler. The purpose is front-loaded, and the prerequisite requirement follows immediately.

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 an 11-parameter mutation tool with no annotations and no output schema, the description is too sparse. It explains the high-level purpose and two required parameters, but does not provide enough detail about the remaining inputs or the tool's behavioral 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 0% and there are 11 parameters. The description mentions org_id, setup_claim, headline, services, and contact details, but leaves many parameters undocumented, including city, state, cover_url, subheading, and enabled.

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 and target: it 'turns on a branded page at groundquote.com/{slug}' for contractors without a website. That is much clearer than a generic update tool, though it does not explicitly distinguish itself from sibling tools such as set_branding or get_embed_code.

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

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

It gives clear usage context by specifying 'For contractors without a website,' which helps an agent decide when this tool is appropriate. It does not, however, name alternatives 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.