Orca Site Guide

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 states prices are 'public' and that checkout on orcarw.com is the source of truth before payment, which usefully limits reliance on the output for payment. However, it never confirms read-only behavior, side effects, freshness, or authentication needs.

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 content scope and then the payment caveat. The noun-phrase opening is terse but not padded, and every element is relevant. It could be marginally clearer with an explicit verb, but there is no wasted text.

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 pricing lookup with full schema coverage, the description covers scope and the main 'source of truth' caveat. However, with no annotations and no output schema, it omits usage routing and any indication of return structure. It is minimally viable but has clear gaps.

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

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

There is one optional enum parameter, and the input schema fully documents its meaning and default. The description adds no additional syntax or interpretation beyond the schema. Per the calibration rule, a 100% schema description coverage yields a baseline of 3.

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 enumerates the exact price domains (marketplace, Team OS, Training, Scout), so the resource is clear. However, it is a noun fragment without a verb and does not explicitly differentiate itself from sibling tools. The name supplies the action, but the description itself lacks a clear 'returns pricing' statement.

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

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

No when-to-use, prerequisites, or alternative tools are named. The checkout caveat tells the agent to verify payment elsewhere, but it is a caveat rather than routing guidance. There is no guidance on when this tool should be selected over siblings.

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

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

With no annotations provided, the description carries the full behavioral burden, and it does disclose the key trait: no account creation, no email, no charge, i.e. a side-effect-free read. It omits anything about auth requirements, link expiry, personalization, or what the returned URL looks like.

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, front-loaded with the core action, and the disclaimers are compact. No filler or redundancy.

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

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

For a one-parameter read tool with no output schema, the description covers purpose and side-effect profile, and 'signup or onboarding URL' roughly characterizes the return value. Minor gap: it does not explain how the audience enum affects the returned link.

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

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

Schema description coverage is 100% and the single 'audience' parameter documents its enum values and default inline, so the schema does the heavy lifting. The description adds no meaning about the audience parameter or how it changes the returned link, making the baseline 3 appropriate.

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

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

The description states a specific verb and resource: 'Return a signup or onboarding URL.' That resource is distinct from all siblings (get_pricing, list_faqs, list_services, etc.), so an agent can tell it apart without opening a schema. It stops short of explicitly naming an alternative or framing the scope, so it is clear but not maximally differentiated.

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

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

Usage is only implied: by disclaiming account creation, email, and charging, it quietly signals this is for retrieving a link rather than performing onboarding. There is no explicit 'use this when...' statement and no comparison against siblings such as recommend_path or match_intent.

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 behavioral burden. It implies a read-only public listing and discloses that results carry a source page, but says nothing about pagination, result volume, ordering, or whether a topic with no matches returns empty versus errors.

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 short sentence with no filler, front-loading the resource and its key payload attribute. It is efficient, though it is terse to the point of under-specification rather than genuinely tight.

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 no sibling differentiation, the description is too thin. It does not tell an agent when this is the right call versus match_intent or understand_site, nor what an FAQ record actually contains.

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

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

Schema description coverage is 100% and the single 'topic' parameter is a documented enum with a stated default of 'all', so the schema does the heavy lifting. The description adds nothing about how topics map to content, which is the baseline-3 case for a fully documented 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 names the resource ('Public FAQ answers') and adds a hint about payload ('with the page they come from'), so an agent knows it retrieves FAQ content. It never states a verb and does not distinguish itself from siblings like list_services or understand_site, leaving the boundary fuzzy.

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

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

There is no when-to-use guidance, no exclusions, and no named alternative among the six siblings. An agent must guess whether to call this or match_intent/understand_site for question-answering 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 burden. It does disclose a scope boundary (not live VA profiles) which is useful behavioral context. But it doesn't state whether results are paginated, how many are returned, whether it's read-only (inferred but unstated), or the shape of the output. For a description with zero annotation coverage, this is inadequate.

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

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

Two short sentences, zero waste, front-loaded with the primary action. 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?

For a tool with no annotations and no output schema, the description is too sparse. It doesn't explain return format, pagination, or what 'Orca service and region pages' actually contain. The exclusion is helpful but leaves substantial gaps for a tool whose structured fields can't compensate.

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 the 'query' parameter with an example. The description adds no information about the query parameter beyond the baseline. Per rubric, baseline 3 applies when schema 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?

States a specific verb (List) and resource (public Orca service and region pages). The second sentence distinguishes it from related content ('live VA profiles'), which helps differentiate from siblings like list_faqs. Reasonably clear what the tool returns, though 'Orca service and region pages' is somewhat domain-specific jargon.

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

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

Provides one exclusion ('Not live VA profiles') which implies when NOT to use, but gives no explicit guidance on when to use it versus alternatives or what condition triggers it. Siblings like understand_site, list_faqs, or match_intent aren't referenced. Usage context is implied but thin.

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 usefully discloses that the tool is classification-and-redirect only and touches no personal/account data, but says nothing about determinism, whether the returned URL is guaranteed, or how unmatched questions are handled.

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

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

Two tight sentences: the action and taxonomy come first, the exclusion last. No filler, no restatement of the tool name, nothing that could be cut.

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 sketch the return value, and "return the next URL" plus the enumerated classes does that adequately for a simple classifier. The precise response shape (label alongside URL, fallback behavior) remains unspecified.

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

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

Schema coverage is 100%, so both parameters are already documented in the schema, including the 500-character limit and the non-echoed pageUrl. The description adds only the classification taxonomy, which is about output labels rather than parameter meaning, so baseline 3 applies.

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

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

States a specific verb and resource ("classify a public-site question"), enumerates the intent classes, and names the output ("return the next URL"). It does not distinguish itself from near-sounding siblings like understand_site or recommend_path, so an agent must infer the boundary rather than being told it.

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

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

Scopes usage to "public-site question" traffic and adds a clear negative constraint: it does not look up any person or account, which prevents misuse for account-specific lookups. It stops short of naming alternatives (e.g., get_pricing or list_faqs) for cases that fall outside its taxonomy.

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 'canonical public URL' usefully implies a stable, read-only, deterministic lookup. It does not say what happens for an unrecognized goal, whether the URL is localized, or whether it is absolute vs relative.

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

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

A single front-loaded sentence with no waste. It is appropriately terse, though arguably under-specified rather than optimally concise for the ambiguity in its enum.

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 annotations and no output schema, so the description is the only source of behavioral detail, and it omits error behavior, URL format, and enum value meanings. For a lookup tool with 13 opaque enum values this leaves real 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 0%, and the enum includes opaque members such as 'become_va', 'team_os', and 'scout' that an agent cannot infer. The description only restates the parameter as 'goal' without mapping any value to a destination, so it fails to compensate for the coverage gap.

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

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

The description gives a specific verb (Return) and resource (canonical public URL) that clarifies the ambiguous tool name 'recommend_path'. It does not, however, distinguish this from siblings like get_pricing or get_signup_link, which also appear to return 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?

There is no statement of when to use this tool versus get_pricing, get_signup_link, or list_services, all of which overlap on routing users to URLs. The word 'known' hints at a precondition but is never defined.

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 behavioral burden, and it offers only that this is an orientation/documentation read. The zero-parameter, non-mutating nature is self-evident from the schema, but the description says nothing about response shape, size, or whether it is safe to repeat — a moderate gap for a tool with no 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?

Two compact fragments, content first and the ordering imperative last, with zero filler. Every clause carries information an agent needs.

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, no-output-schema orientation tool, the description covers what it returns and its position in the call sequence, which is sufficient to invoke it. Only the absence of any note on the returned material's shape keeps it from being fully complete.

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

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

The tool takes no parameters, so there is no argument semantics to document; the baseline for a zero-param tool applies. The description correctly implies a parameterless call with no configuration 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 names the specific content the tool returns — what Orca is, the target audience, and the public docs — which is enough to distinguish it from siblings like get_pricing, list_faqs, and list_services. It lacks an explicit verb ('retrieve', 'return'), so it reads as a content summary rather than an action, but the scope 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?

'Call this first' is an explicit, actionable ordering instruction that tells the agent when to reach for this tool relative to the other site-info siblings. It stops short of naming when-not-to-use or pointing to a specific alternative for follow-ups, so it is clear context rather than full routing logic.

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