Taco Street Locating

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

With all annotations false, the description carries the full behavioral disclosure burden. It reveals asynchronous reply timing, business-hours availability, direct delivery to the renter, the risk of polling-only answers being stranded, rate limiting, and the fact that answers are point-in-time facts. This is substantial and actionable 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?

The description is compact and front-loaded, leading with purpose, then examples, then operational guidance. Every sentence adds value: business hours, contact necessity, return channel, rate limiting, and point-in-time caveat. There is no fluff or repetition of schema mechanics.

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 is complete for an async human-question tool: it explains how answers are delivered, what the agent gets back, when responses occur, and what to do about rate limits. Since an output schema exists and the input schema is fully documented, an agent has everything needed to invoke the tool correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces the contact parameter's importance and adds 'batch related questions into one,' but it does not substantially add parameter-level meaning beyond what the schema already provides for question, city, agent, and apartments.

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

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

The description opens with a specific verb and resource: 'Ask a question only a human can answer,' backed by concrete examples like specials, availability, and lease flexibility. It clearly separates this tool from automated lookup siblings by emphasizing human-only knowledge, and references check_answer as the companion channel.

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 tells the agent when this tool is appropriate: when the question requires a human, during Central Time business hours, and with a contact included. It also advises batching related questions due to rate limits, but it does not explicitly name alternatives or state when not to use it. The 'only a human can answer' criterion is a clear contextual signal but not a full exclusion list.

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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds the meaningful behavioral nuance of 'Poll', indicating repeated non-blocking checks may be needed until the answer is available. This goes beyond the structured annotations without contradicting them.

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 carries the full purpose, method, and parameter relationship with no wasted words. The verb is front-loaded, and the description is immediately actionable without 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 low-complexity tool with a single required parameter, an output schema, and comprehensive annotations, the description is complete. It names the source tool (ask_a_locator), specifies the parameter source, and uses 'Poll' to convey the expected interaction pattern.

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%: the schema already states that question_id is 'The id returned by ask_a_locator.' The description only mentions 'by question_id' and adds no additional semantic detail beyond the schema, 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 uses a specific verb ('Poll') with a clear resource ('the answer to an ask_a_locator question') and identifies the key identifier (question_id). This clearly distinguishes it from siblings like ask_a_locator, which creates the question rather than retrieving its answer.

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 clearly implies when to use it: after calling ask_a_locator, using the returned question_id to retrieve the answer. It does not explicitly list when-not-to-use scenarios or alternatives, but the relationship to ask_a_locator is explicit enough for a single-purpose 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?

The annotations say the tool is not read-only, not idempotent, and not destructive, and the description adds the key behavioral detail: it creates a link that opens the renter's saved list with the buildings added. This adequately communicates the main side effect without contradicting the annotations.

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

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

Two sentences with no wasted words. The first sentence front-loads the action and outcome, while the second delivers a critical input constraint. The extra benefits (compare, AI Read, free tour requests) justify their place by clarifying the link's purpose.

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 100% schema coverage and the presence of an output schema, the description fully equips the agent to call the tool correctly. It explains the tool's effect, the exact-name requirement, the use case, and the downstream value, leaving no material gap for 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 description coverage is 100%, so the schema already documents city, agent, and apartment_names. The description reinforces the 'EXACT names from search_apartments' requirement, but that is already present in the schema's apartment_names description, so it adds limited new semantic value.

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 ('Turn finalist apartments into a Taco Street link'), names the output artifact, and explains what the link lets users do. It clearly distinguishes this tool from siblings like search_apartments and get_apartment_details.

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 the right moment to use the tool: when the user has finalist apartments to save and share. It also directs the agent to use exact names from search_apartments, which is a concrete integration constraint, though it does not explicitly list 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.

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

Annotations already establish readOnly, idempotent, and non-destructive behavior. The description adds valuable behavioral context by flagging specials as last-known and dated, requiring the agent to compute totals itself rather than trust an already-calculated number, and noting that a human locator can confirm live figures.

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 dense sentences deliver the tool's scope, data freshness caveat, and usage rule without wasted words. Key information is front-loaded in the opening clause, and every sentence adds operational 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?

The description fully covers what the tool returns, how to call it correctly, and important caveats about data freshness and total calculation. With a rich output schema, read-only annotations, and clear sibling context, nothing essential is missing for an agent to invoke this tool effectively.

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

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

Schema coverage is 100%, so the schema already documents name and city well, including the disambiguation purpose for city. The description reinforces using the exact name from search_apartments, which is helpful but largely redundant with the schema's parameter 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 states a specific action: retrieving a full fact sheet for one building, and lists the concrete contents (floorplan pricing, move-in costs, specials, amenities, walkability, virtual tour). This clearly distinguishes it from search_apartments and the locator sibling tools.

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

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

The description gives clear usage context: use the exact name from search_apartments, implying this tool is for follow-up detail lookup on a known building. It does not explicitly enumerate when not to use it, but it does route total confirmation to a human locator, which helps with alternative selection.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds value by stating that no draft, contact details, or internal notes are returned, and includes a security instruction about not sharing the key publicly. This goes beyond the annotations and provides useful behavioral context.

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 with no wasted words. The primary purpose is stated first, followed by exclusions and a security note. It is front-loaded and highly 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 the tool's simplicity (2 params, output schema present, annotations cover safety), the description provides all necessary context: what it does, when to use it, what it excludes, and a security warning. Nothing critical is missing for an agent to call it correctly.

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 both parameters (request_id and request_key) are fully described in the schema. The description only restates the purpose of the key ('private request key') without adding new semantic meaning. Baseline 3 is appropriate when the schema carries the parameter documentation.

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

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

The description clearly states the tool retrieves progress and, after approval, a reviewed report snapshot using a private key. It explicitly lists what is not returned, distinguishing it from other research-related tools. This is 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?

The description provides clear context: use when you have a private request key and after Alexander approves. It implies the tool is for continuing an existing research request, but it does not explicitly contrast with sibling tools like request_apartment_research. The condition 'after Alexander approves' gives a usage hint, though no exclusions are mentioned.

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 annotations declaring idempotentHint, non-destructive, and not read-only, the description adds valuable behavioral context: the request is accepted by staff before research starts, involves VA verification and Alexander's judgment, and returns only a continuation link. It also clarifies that no email is sent, which is not indicated by annotations. No contradiction with annotations.

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

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

The description is compact – two sentences that front-load the core action and then set expectations. It is informative without being verbose, though it could be slightly more structured to separate the action from the limitations.

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 tool with 15 parameters and an output schema, the description provides a clear workflow and expected behaviors. The schema fully documents parameters, and the description covers the submission lifecycle. A minor gap is not mentioning how to retrieve the eventual report (via get_research_request), but that is not required for invoking this tool correctly.

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 has 100% description coverage for all 15 parameters, including detailed semantics for request_key, consent, and shortlist_token. The description adds no parameter-level meaning, which is acceptable given that the schema already fully documents them. 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?

The description states a specific action – Submit a saved shortlist and renter brief – with a clear target (Taco Street) and outcome (private continuation link). It differentiates from siblings like create_shortlist (which creates a shortlist) and get_research_request (which retrieves status) by focusing on submission initiation.

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

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

The description gives clear context: it requires consent, refers to a saved shortlist (implying prior use of create_shortlist), and explicitly lists exclusions (no immediate report, no tours, no email). However, it does not name alternative tools for follow-up, such as get_research_request, leaving some inference 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?

The description adds meaningful behavioral detail beyond the annotations: follow-up arrives by text or email, never a cold call; the renter's contact must be shared with consent; duplicates within 24h return the existing lead. This also elaborates the idempotentHint annotation instead of merely repeating it.

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 with no redundancy: first sentence states the action and cost model, second covers communication behavior, third covers consent and deduplication. Every sentence earns its place and the main action 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 9-parameter tool with full schema coverage and an output schema, the description covers the essential workflow, consent requirement, contact method, and idempotency behavior. It doesn't describe edge cases like missing optional parameters, but the schema already documents those.

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 documents all 9 parameters with 100% coverage, so the baseline is 3. The description reinforces that the 'contact' parameter must be real and consent-based, but it doesn't add new meaning to the other parameters.

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

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

The description clearly states the action ('Hand the renter to Alexander...') and the resource (Taco Street's human locator), so an agent can tell what the tool does. It doesn't explicitly differentiate from the sibling ask_a_locator, which appears to cover a similar domain, so it misses the full 5-point bar.

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

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

The description gives useful context: it's free to renters, requires a real contact with consent, and has a 24h deduplication rule. However, it never states when to prefer this tool over ask_a_locator or other siblings, so the usage guidance 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?

Annotations declare idempotentHint=true but the description adds concrete behavioral detail: 'identical retries return the existing request, changed preferences require staff follow-up.' It also clarifies side effects with 'No appointment is booked or message sent' and notes the private key/contact usage. This goes well beyond the structured annotations.

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

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

The description is front-loaded with the purpose and precondition, then packs behavioral constraints into compact sentences. The line about preferred_times is mildly redundant with the schema, but every other sentence adds distinct value and the overall length is appropriate.

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 four required parameters, an output schema, and annotations, the description covers preconditions, idempotency, side effects, contact/key usage, and the handoff limit. Nothing an agent needs to avoid misinvocation is missing; the only omitted details are already covered by the output schema.

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. The description's 'Include preferred dates, times and timezone in preferred_times' largely echoes the schema's parameter description. No additional semantic meaning is added beyond what the schema already documents.

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

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

States a specific verb+resource: 'request human tour coordination for selected apartments.' Adds scoping conditions 'After report approval and explicit renter consent' and 'Uses the existing private research key and contact,' which clearly separates this from sibling request_apartment_research without needing the 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?

Provides clear context: 'After report approval and explicit renter consent' states when this tool is valid, and 'One handoff per research report' sets an important boundary. It does not explicitly name alternatives or exclusions, but the prerequisites are strong enough to guide selection.

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?

Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond annotations by explaining that it returns scored matches with starting prices and a per-building rationale, which is not derivable from annotations alone.

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 short sentences, each earning its place: the first defines the action and scope, the second describes the return value, and the third sets the usage boundary. No fluff or repetition of schema 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 the rich schema, presence of an output schema, and strong annotations, this description is nearly complete. It conveys the tool's purpose, output highlights, and usage boundary; the only small gap is not explicitly differentiating it from locator-style sibling 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?

The schema already describes 100% of parameters, so the baseline is 3. The description adds no parameter-specific detail beyond a high-level sense of what the search covers, but it does not need to, because the schema is complete and descriptive.

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 action ('Search'), a precise resource ('Taco Street's curated apartment inventory'), geographic scope (Austin, Dallas, Houston), and what the output contains (scored matches with prices and 'why' notes). This clearly differentiates it from detail, shortlist, and locator sibling tools.

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 clear context: it is for searching curated long-term rental inventory in specific Texas metros. The phrase 'Use for long-term rentals only' is an explicit boundary, though it does not name sibling alternatives or state when to choose, say, ask_a_locator instead.

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