Scout

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

No annotations are provided, so the description bears full burden for behavioral disclosure. It does not indicate whether this is a read-only operation, any side effects, permissions, or rate limits. The listed fields are output content, not behavior.

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

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

Two sentences: first lists output fields, second gives input instructions. No wasted words, and key information 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 profile tool with no output schema, the description adequately enumerates key output fields and input options. It lacks behavioral context but covers purpose and parameters well.

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% with parameter descriptions. The tool description adds value by explaining the source of values (from scout.find_public_agent) and that parameters are alternatives, which aids correct usage.

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 it provides a deep profile for a single agent and lists specific data fields, distinguishing it from siblings like scout.find_agent (simpler lookup) and scout.compare_agents (comparison).

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

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

It explicitly instructs to pass either the UUID id or slug from scout.find_public_agent, providing clear context for when to use and how to input. However, it does not mention when not to use or list 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?

No annotations are provided, so the description carries the full burden. It discloses the input constraint (2-5 agents) and output fields, but does not explicitly state the tool is read-only, non-destructive, or mention any safety or authorization traits. The behavior is implicitly safe, but lacks explicit transparency.

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 clear and concise sentences, front-loaded with the core purpose, no wasted words.

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

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

Given a single parameter, no output schema, and no annotations, the description effectively covers purpose, input constraints, output specifics, and usage context. It omits potential details like return format or error handling, but is largely complete for a straightforward comparison tool.

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 tool description merely repeats the schema's description of 'agent_ids' as an array of 2-5 UUIDs/slugs, adding no new semantic meaning beyond what the schema already provides.

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

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

The description clearly states the verb 'compare' and the resource 'agents', listing specific output fields and positioning it as a follow-on to scout.find_public_agent, which distinguishes it from sibling tools like scout.agent_profile or scout.find_public_agent.

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?

Explicitly says 'good follow-on to scout.find_public_agent when an AI assistant needs to choose between candidates,' providing clear context for when to use this tool and naming an alternative that precedes it.

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

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

No annotations exist, so description carries full burden. It transparently describes the returned data (states with direct licensing and referral partners). Although it doesn't explicitly state read-only behavior, the description implies a query operation without side effects.

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 concise sentences, front-loaded with purpose, no unnecessary words. Every sentence earns its place.

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

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

For a zero-parameter tool with no output schema, the description sufficiently explains the return shape. Could be more explicit about format, but is adequate for agent decision-making.

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?

No parameters exist, so baseline is 4. The description adds value by explaining the return content beyond what the empty schema provides.

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

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

The description clearly states the tool returns Flika's coverage including states with direct licensing and referral partners. It distinguishes from sibling tools by specifying a unique purpose, and explicitly suggests calling this tool first for geographic checks.

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 explicit when-to-use guidance: 'Call this first if you're unsure whether Flika can help with a specific geography.' While no when-not or alternatives are given, the context is clear and helpful.

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 full burden for behavioral disclosure. It transparently states that the result is a wide confidence interval, not a precise value, and does not adjust for property-specific features. It also specifies the data source (Census ACS).

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, each serving a purpose: defining the tool, clarifying its limitations, and providing usage guidance. No 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?

The description adequately explains the tool's behavior and limitations given its simplicity. However, without an output schema, it does not detail the exact return fields (e.g., median value, confidence interval range), leaving minor ambiguity. Still, it is mostly 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 schema covers the single parameter (zip) with a clear description. The tool description does not add additional semantics beyond stating that zip is required, but since schema coverage is 100%, a baseline score of 3 is appropriate.

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

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

The description clearly states the tool returns a neighborhood-baseline property value estimate using Census ACS median home value, and explicitly distinguishes it from an individual-property AVM. It also contrasts with scout.search_listings, making its purpose unambiguous relative to siblings.

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

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

The description provides explicit guidance on when to use the tool ('ground-truth a buyer's expectations') and recommends pairing it with scout.search_listings for actual comps. It also notes it is free and available in all 50 states, aiding decision-making.

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 full burden. It discloses the temporal constraint (last 60 minutes) and partial output fields, but does not detail error handling, authentication needs, or behavior when no agents are found. The transparency is adequate but not comprehensive.

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, front-loading the purpose and output, with a brief usage guideline. Every word adds value; no redundancy or verbosity.

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 search tool with 6 parameters and no output schema, the description covers the main purpose, key output fields, and usage scenario. It lacks details on parameter precedence or edge cases, but overall is sufficiently complete for typical use.

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 baseline is 3. The description adds context about the search condition (live agents) but does not provide additional parameter-level semantics or format details beyond what the schema already offers.

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 finds Flika agents who are currently live (pin dropped within last 60 minutes) in or near a given location. It specifies the resource (agents), action (find), and condition (live), which distinguishes it from sibling tools like scout.find_public_agent.

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 a clear usage context: 'Use this when your buyer/seller is ready to connect with a real agent.' However, it does not explicitly exclude other scenarios or contrast with alternatives like scout.find_public_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 carries the full burden. It mentions public nature, returned data, and the claim_url feature, but lacks details on rate limits, authentication, or data completeness. Moderate transparency.

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?

Extremely concise: two sentences that cover purpose, output, and a standout feature. Every word adds value, and the most important information 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?

With 9 parameters and no output schema, the description covers geographic scope, returned fields, and the claim_url feature. It could mention pagination or default ordering, but overall is fairly 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?

Schema coverage is 100%, so baseline is 3. The description adds minimal parameter-specific meaning; it does not explain parameter interactions or dependencies. Adequate but not enhanced.

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 it searches a public brokerage directory, lists the return fields (contact info, volume stats, claim_url), and specifies geographic coverage. This differentiates it from sibling tools like scout.find_agent which search for individual agents.

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?

Description implies usage for finding brokerages, but does not explicitly state when not to use it or mention alternatives. However, the sibling tool list provides sufficient context for differentiation.

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 fully discloses behavioral traits: data sources, claim_url for unclaimed agents, sorting behavior (distance ascending vs flika_score descending), and dependency on lat/lng or address for proximity. No contradictions exist.

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 well-structured: purpose first, then data source note, usage guidance, and sorting details. It is front-loaded with the core purpose. While slightly long, each sentence adds information, so 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?

For a tool with 11 parameters, no required params, no output schema, and no annotations, the description covers essential behaviors: sorting, filtering, sibling distinction, and claim_url. It could mention error handling or pagination, but it is largely 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?

Schema coverage is 100%, so baseline is 3. The description adds value by explaining lat/lng or address triggers distance-ascending results, radius_miles is only meaningful with those, and claimed_only defaults to false. This extra context raises the score above baseline.

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 searches Scout's public licensed-agent directory and returns agents from state REC rosters and MLS-ranked prospect lists. It explicitly distinguishes from scout.find_agent by noting this tool returns the full directory regardless of pin freshness.

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 guidance is provided: prefer scout.find_agent for live-available agents, prefer scout.find_public_agent for broad discoverability. It also advises calling scout.coverage() first to check state data availability and explains when to pass lat/lng vs address for proximity sorting.

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?

Without annotations, the description carries full burden. It discloses that returns are 'scored, deduplicated leads with property address + executor contact', mentions API key and scope requirements, and licensing terms. This provides significant behavioral context beyond a simple read.

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, front-loaded with purpose, and includes necessary details. It is concise but could be slightly more structured (e.g., separating business terms). No superfluous 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?

Given 6 parameters and no output schema, the description explains return value format (scored, deduplicated leads with contact info) and covers licensing. It is complete enough for an agent to understand what the tool produces, though error handling is not mentioned.

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 each parameter already has a description. The tool description adds overall context but does not elaborate on parameter usage beyond what the schema provides. Baseline score of 3 is appropriate.

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

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

The description clearly states 'Retrieve Flika's proprietary seller-intent signals' with specific signal types and geographic scope, distinguishing it from sibling tools that focus on agents, brokerages, or listings.

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 usage for finding seller leads but does not explicitly state when to use this tool versus alternatives or provide exclusions. No sibling tools offer similar functionality, so context is adequate but lacks explicit 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?

Discloses important behavioral traits: data is public and free, no API key required, and listings activity depends on MLS-live coverage. Despite no annotations, the description covers key aspects (read-only, no destructive actions). It does not mention rate limits, but the free nature implies minimal restrictions.

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 one paragraph of four sentences, front-loading the core purpose. It efficiently conveys the data returned, usage context, and key features (free, no key required). Every sentence adds value without unnecessary 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?

Given the lack of an output schema, the description fully explains the return value: specific Census demographics, agent density, and conditional listings activity. It also covers usage constraints (MLS-live coverage) and the required input pattern. No gaps remain for a tool of this simplicity.

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?

Input schema coverage is 100% with clear descriptions for each parameter (e.g., describing the zip-or-city+state requirement). The tool description adds no further parameter-level meaning; it focuses on output. Baseline of 3 is appropriate as the description does not enhance parameter understanding beyond the schema.

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

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

The description clearly states the tool's function: 'Public-data-backed market snapshot for any US zip code' and enumerates specific data points (Census ACS demographics, agent density, listings activity). This distinguishes it from sibling tools like scout.agent_profile or scout.search_listings, which focus on individual agents or listings.

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?

Explicitly says 'Call this when an AI user asks 'what's the market like in [zip/city]'', providing a clear use case. It doesn't explicitly list when not to use it or name alternatives, but the context of sibling tools allows the agent to infer when other tools are more appropriate.

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 provided, so the description carries full burden. It discloses credit deduction, idempotency, scope requirements, and balance prerequisite. This provides good behavioral transparency beyond the schema.

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

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

Three concise sentences with no fluff. Front-loaded with the main action, followed by key details. Every sentence adds value.

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 annotations and no output schema, the description covers purpose, prerequisites, idempotency, and balance. It does not detail the return format or error conditions, but the context is largely complete for an informed agent.

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 parameter 'lead_id' is fully described in the schema as a UUID. The description adds context that it comes from scout.search_leads and that purchasing is idempotent, enhancing understanding.

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

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

The description clearly states the action (purchase), the resource (a single seller-signal lead), and the marketplace context. It distinguishes from siblings like scout.search_leads and scout.get_seller_signals by focusing on the purchase 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?

The description implies usage after scout.search_leads (since lead_id comes from there) and mentions required scope and balance. It does not explicitly exclude alternatives, but the context is clear for a purchase-only tool.

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

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

No annotations are provided, so the description carries full burden. It discloses that the tool is a read-only lookup and enumerates return values. While it doesn't detail error handling or idempotency, the transparency is adequate for a simple query tool.

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

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

Two efficient sentences: first states purpose and outputs, second gives usage context and parameter guidance. Every sentence is necessary and front-loaded, with no redundant information.

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 or annotations, the description covers core usage, expected returns, and invocation context. It lacks details on ambiguous input (e.g., if both parameters given) but is otherwise complete for a simple lookup tool.

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%, baseline 3. The description adds value by explaining the parameter options (partner_id vs. partner_slug) and their types (UUID, slug), clarifying usage beyond the schema descriptions.

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 looks up bilateral referral terms for a partner brokerage, specifying exact return fields (buyer-side %, listing-side %, tail months, custom notes). It distinguishes itself from sibling tools by referencing scout.route_lead usage, making the purpose specific and 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?

Explicitly advises when to use ('when scout.route_lead is about to fire and you need to confirm the split') and how to call it (pass partner_id OR partner_slug). Lacks explicit 'when not to use' or alternative tools, but the guidance is clear and contextual.

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 provided; description discloses routing destinations, fee structure, and API key requirement, but does not detail response behavior or error conditions.

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?

Single paragraph is dense but contains all key information; could be slightly more structured (e.g., bullet points for routing options) but remains efficient.

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

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

Given 15 parameters and no output schema, description explains routing outcomes and fees but lacks return value details; fairly complete for a submission tool.

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

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

With 93% schema description coverage, the description adds little beyond what the schema provides for most parameters; it provides high-level context on routing but not per-parameter nuance.

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?

Description uses specific verb ('Submit') and resource ('buyer or seller lead') and explains the routing process, clearly distinguishing from sibling tools like scout.find_agent.

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?

Description implicitly guides usage by mentioning optional fields for pre-selected agents/brokerages, but lacks explicit when-to-use or when-not-to-use guidance versus 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, description discloses key behaviors: returns up to 25 schools, free, covers all 50 states, uses NCES data. Missing rate limits or authorization details, but covers safety and scope well.

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

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

Three sentences, no filler, front-loaded with main action. Every sentence adds value.

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, but description explains return fields and data source. Covers limit, scope, and use case. Lacks return format details but suffices for agent 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 100% with descriptions for both parameters. The description adds no extra meaning beyond what's in the schema, earning baseline 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 clearly states the tool looks up public schools in a zip code via NCES data, specifies return fields (grade level, enrollment, district, NCES ID), and contrasts with sibling tools that deal with agents, brokerages, etc.

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 a use case ('useful for buyer queries like is this a good school zone?') but lacks explicit guidance on when not to use or alternatives. Implies usage but no 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?

No annotations provided, so description carries burden. Discloses key traits: free to call, returns redacted previews, limited to SC+GA, and lists signal types. Does not mention rate limits or auth, but acceptable for a search tool.

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

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

Two concise sentences front-loading purpose, return type, cost, and geographic scope. No wasted words; every sentence adds value.

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?

Covers major aspects: what, where, cost, relation to sibling tool. Lacks return format or pagination details, but acceptable given no output schema and 8 parameters. Slightly incomplete for a tool this complex.

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 baseline is 3. Description lists signal types but adds no semantic depth beyond schema parameter descriptions. Adequate but not exceptional.

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 it previews seller-signal leads (probate, NOD, FSBO, expired, tax-delinquent) for sale through the Scout marketplace. It distinguishes from scout.purchase_lead by noting full data requires purchase, and contrasts with sibling tools like scout.get_seller_signals.

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?

Explicitly states geographic limitation ('SC + GA only') and that calling is free. Mentions when to use purchase_lead for full details. No explicit when-not-to-use or alternatives list, but context is clear for common scenarios.

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 convey behavior. It states the return limit and filter behavior, but does not mention whether the tool is read-only, rate limits, or error handling. It adequately covers core behavior for a search tool but leaves some gaps.

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, each essential. The first sentence defines purpose and key constraints; the second provides guidance. No wasted words, and critical information 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?

Given no output schema, the description explains the output format (up to 25 listings) but lacks details on the fields returned, sorting, or pagination. While adequate for basic use, it leaves uncertainty about what data each listing 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?

All 8 parameters are fully described in the schema. The description adds no additional parameter-level meaning beyond stating the return limit, which is not parameter-specific. Thus, it meets the baseline expectation but does not exceed 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?

The description clearly states the tool searches active listings in SC+GA, with a limit of 25. The verb 'Search' and resource 'listings' are explicit, and the geographic scope differentiates it from sibling tools like scout.coverage or scout.market_pulse.

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 includes an explicit recommendation to use scout.coverage() first if coverage is uncertain, providing clear guidance on when to use an alternative. While it doesn't list all scenarios, this single instruction is practical and relevant.

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 transparently discloses the beta state, manual onboarding ('emails Spencer'), and that leads are created and approved before posting. It could be improved by mentioning error handling or cancellation process.

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 concise, with three sentences that front-load the purpose and then provide behavioral context and caveats. No redundant or 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?

Given no output schema and no annotations, the description adequately sets expectations: continuous feed, webhook delivery, budget cap, beta state, manual setup. Missing details on how to cancel or what the POST payload includes (partially in schema but not in description) prevent a perfect score.

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 67% of parameters with descriptions (webhook_url and monthly_lead_budget). The description adds context by explaining that monthly_lead_budget caps leads pushed. However, the filter parameter lacks details on its sub-properties (state, min_score, signal_types) beyond being mentioned as 'matching a filter.'

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

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

The description clearly states the action ('subscribe') and the resource ('continuous feed of new seller-signal leads matching a filter'). It distinguishes from sibling tools like search_leads (one-time query) and purchase_lead (single lead) by emphasizing continuous delivery via webhook.

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 says 'Ideal for AI agents that act on leads automatically,' providing clear context for use. It also notes the beta status and manual provisioning, which sets expectations. However, it does not explicitly state when not to use or mention 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?

No annotations provided, so description bears full burden. It discloses sorting by Flika score descending and default limit of 25, but does not state whether the operation is read-only, required permissions, or rate limits. Adequate but not comprehensive.

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

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

Three sentences, front-loaded with the core action, includes two example queries. No unnecessary words; every sentence earns its place.

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

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

With no output schema, the description should mention what data the roster includes (e.g., agent names, contact info, Flika score). It only says 'full agent roster' and sorting without specifying fields. Incomplete for an agent to fully understand the return value.

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%, yet description adds value by clarifying mutual exclusivity of brokerage_id, brokerage_slug, or (name+state), and explaining the limit range and default ordering. This goes beyond schema 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?

Clearly states it returns the full agent roster of a brokerage and specifies identification methods. However, it does not explicitly differentiate from sibling tools like scout.agent_profile or scout.compare_agents, which are for single agent details or comparisons.

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 example queries ('show me Compass agents in Charleston') and implies use case for listing agents. Does not specify when not to use or compare to alternatives; the mention of scout.find_brokerage is a prerequisite, not an alternative.

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 return values (status, expiration, brokerage, etc.) and notes that the claim URL always resolves, including for licenses looked up in real time. However, it lacks details on error handling, idempotency, or authentication requirements.

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 concise, containing 4-5 sentences with no redundant information. It is well-structured: first sentence states purpose, second lists returns, third explains claim URL behavior, and fourth gives usage guidance. Every sentence earns its place.

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

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

Despite lacking an output schema, the description compensates by listing all return fields (status, expiration, brokerage, timestamp, claim status, claim URL) and explaining the URL's behavior. For a tool with only two simple parameters, this provides sufficient context, though it omits potential error conditions.

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

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

The input schema already provides clear descriptions for both parameters (state: 'Two-letter state code'; license_number: 'Exactly as issued by the state (no spaces)'), achieving 100% coverage. The description adds no further meaning beyond what the schema offers, so a baseline score of 3 is appropriate.

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

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

The description clearly states the tool verifies a real estate license's active status and returns a canonical claim URL. It uses specific verbs ('Verify', 'return') and identifies the unique resource, distinguishing it from sibling tools like scout.find_agent which focus on profiles rather than license verification.

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 says when to use the tool: 'when you have a license number and want to tell the agent how to claim their AI pin, or before sending a lead.' This provides clear context, though it does not explicitly mention when not to use it or name alternative tools.

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