Taco Street Locating

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

With no annotations, the description carries the behavioral burden and largely succeeds: it discloses asynchronous follow-up via check_answer, expected latency in Central Time business hours, and rate limiting with a batching mitigation. Minor gaps remain around failure handling or what happens if no human can answer, but the core behavior is clear.

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 each earning their place: what to ask, latency plus return mechanism, and rate-limit guidance. The use cases are front-loaded and there is no filler.

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 five-parameter, no-annotation, no-output-schema async tool, the description is close to sufficient: it covers question scope, async polling mechanism, timing, and rate limiting. It could clarify behavior for edge cases or how optional parameters affect routing, but nothing essental for a correct call is missing.

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

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

Schema coverage is 60%, and the description adds meaning mainly to the question parameter by illustrating what counts as a human-answerable question. It does not elaborate on city or agent, but those are self-explanatory and the schema already describes contact and apartments. The description provides acceptable but not comprehensive parameter 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 names a precise verb-object pair ('Ask a question... a human locator'), scopes it to 'a question only a human can answer,' and gives concrete examples like current specials, real availability, and lease flexibility. It also differentiates itself from siblings by noting it returns a question_id to poll with check_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?

It provides a clear selection criterion ('only a human can answer') with examples that distinguish it from search_apartments, plus operational guidance about business hours and batching under rate limits. It does not explicitly name all alternatives or state when not to use the tool, but the context is strong.

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 burden of exposing behavior. The verb 'Poll' conveys a read-only, repeated check operation, which is useful behavioral information. However, it does not disclose what happens if the answer is not yet available, whether the call blocks or returns immediately, or what the return value 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?

The description is a single, front-loaded sentence with no wasted words. Every element—action, target, and parameter—is conveyed efficiently, making it easy to parse quickly.

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 does not clarify the return format or behavior when no answer exists yet, which is important for a polling tool. However, the tool is simple (one required parameter) and the core operation is stated clearly, so it is minimally viable but lacks some contextual detail.

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

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

Schema description coverage is 0%, so the description must compensate for the parameter semantics. It does identify question_id as the identifier of the ask_a_locator question, which adds some meaning beyond the raw schema. Yet it does not explain where to obtain the question_id (e.g., from the ask_a_locator response) or the expected format of the string, leaving room for ambiguity.

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 a specific verb ('Poll') and resource ('the answer to an ask_a_locator question'), and identifies the required identifier (question_id). This distinguishes it sharply from siblings like ask_a_locator, which creates the question, and search_apartments, which searches for something else.

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

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

The phrase 'ask_a_locator question' gives clear context that this tool is meant to be used after a question has been asked, implying a workflow pairing with ask_a_locator. It does not explicitly list alternatives or when-not-to-use conditions, but the usage context is clear enough for an agent to select it appropriately.

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 burden of behavioral disclosure. It explains what the tool produces, the URL pattern, that the list opens with buildings added, and that actions like compare, AI Read, and tour requests are available there. It could mention side effects or failure behavior, but the core behavior is well disclosed for a link-creation 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?

The description is two sentences with the primary behavior front-loaded. The feature list after the dash is brief and helps the agent understand the output's purpose without adding bloat. 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 low-complexity tool with three parameters and no output schema, the description is nearly sufficient: it names the output artifact, the input source, and the result behavior. It could be slightly more explicit about what the tool returns and the role of the optional city and agent parameters, but these are not critical blockers.

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 only 33%, so the description needs to compensate, and it meaningfully does for the most important parameter: apartment_names must use the EXACT names returned by search_apartments. It also implies these are finalist apartments. City and agent receive less clarification, but city is an enum and agent has a schema description.

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: it turns finalist apartments into a Taco Street link that opens the renter's saved list. This clearly distinguishes the tool from siblings like search_apartments, which finds apartments rather than creates a shareable link.

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: use this tool when finalist apartments have been identified and a shareable shortlist is needed. It also provides an explicit input rule, 'Use the EXACT names returned by search_apartments,' which helps the agent avoid common errors. It does not explicitly list when not to use alternatives, but the intended scenario is clear enough.

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 transparency burden. It discloses consent requirements, the cost model (properties pay), and the one-request-per-renter limit, which are important behavioral traits beyond a simple request action.

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 filler; each sentence adds a distinct piece of information: the locator's role, the cost/consent model, and the per-renter limit. The key 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 no annotations and no output schema, the description is not complete enough. It provides strong high-level context but lacks parameter-level guidance and clear routing criteria, so an agent cannot fully determine how to invoke 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 only 44%, so the description needs to compensate. It adds meaning for contact by explaining it must be a real phone/email shared with consent, but it does not clarify city, name, move_in, budget, or neighborhoods, leaving most parameters underspecified.

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, who confirms live pricing/availability and books tours. It names a specific resource and verb, but it does not explicitly distinguish itself from the similar sibling tool ask_a_locator.

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 constraints such as 'free to renters' and 'one request per renter,' but it does not say when to use this tool versus ask_a_locator or other siblings. No alternatives or exclusions are mentioned, so usage timing is left to inference.

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 disclosure burden. It discloses meaningful behavior: the tool returns scored matches with starting prices and a per-building 'why,' and it searches a curated (rather than raw) inventory. However, it never states the safety profile explicitly (read-only, no side effects) or any auth/rate-limit considerations; for a search tool the mutation risk is low, but the burden was the description's to carry.

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

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

Three sentences with zero wasted words: purpose+scope, return format, and usage boundary. The core verb and resource are front-loaded in the first sentence, and every subsequent sentence earns its place by adding decision-relevant 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?

For a moderately complex tool (6 parameters, no output schema, no annotations), the description covers the essentials: what is searched, where, what is returned, and when it should be used. Since there is no output schema, the description's return-format disclosure is essential and present. It does not explain how scoring works, how parameters like neighborhoods or budget_max interact, or how to craft an effective query, but none of these are required for a competent call.

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 exactly 50%: city, query, and budget_max already have descriptions, while limit, bedrooms, and neighborhoods are documented only by type/enum/default. The description adds some contextual value by revealing that results are scored, which implies the query parameter drives relevance ranking, but it does not compensate for the undocumented parameters or add meaning beyond what the schema enum/constraints already convey. A 3 baseline is appropriate given borderline coverage.

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

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

The description names a specific verb (Search), a specific resource (Taco Street's curated apartment inventory), and a precise geographic scope (Austin, Dallas, Houston). The return behavior (scored matches, starting prices, a 'why' per building) further pins down what the tool does. Its inventory-search purpose is clearly distinct from the sibling tools, which all concern locators, answers, or shortlists.

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 closing sentence 'Use for long-term rentals only' gives an explicit usage boundary, telling the agent not to apply this tool to short-term rental queries. The context for when to search is clear from 'curated apartment inventory,' but the description never names alternatives or states when to prefer ask_a_locator or request_locator_help instead, so it misses the explicitness required for a 5.

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