Taco Street Locating

Request an apartment research report

request_apartment_research

Idempotent

Submit a saved shortlist and renter brief to Taco Street with consent. Staff accepts the request before paid research starts; VAs verify gaps, then Alexander adds his judgment. Returns a private continuation link. No immediate report, guaranteed completion time, or tour booking. No email is sent by this tool.

Input Schema

Name	Required	Description	Default
`city`	Yes	Supported search market for this shortlist.
`agent`	No	Self-reported referring assistant or product; not a verified partner identity.
`notes`	No	Renter requirements and questions, not assistant-generated promises.
`consent`	Yes	True only after the renter agrees to share this brief and contact for research and follow-up.
`contact`	Yes	Renter's email or phone shared with consent for research follow-up.
`move_in`	Yes	Move-in month YYYY-MM or exact date YYYY-MM-DD. Never invent a day; confirm the year.
`bedrooms`	Yes	Bedroom count, 0 for a studio, 1–4 otherwise.
`budget_max`	Yes	Monthly USD budget; specify its basis and flexibility separately.
`client_name`	Yes	Renter's name shared with consent.
`request_key`	Yes	Generate a fresh cryptographically random URL-safe key (at least 32 random bytes, 43 encoded characters). Keep it private. Reuse it only to retry this identical request and retrieve its status; a different brief needs a new key.
`budget_basis`	No	base_rent, total_monthly, or unknown when the renter has not specified.	unknown
`shortlist_token`	Yes	The s parameter from the create_shortlist URL.
`lease_term_months`	No	Requested lease length if known; omit when unknown.
`budget_flexibility`	No	Defaults to target. Use hard_max only for an explicitly strict ceiling.	target
`move_in_flexibility`	No	Whether the move-in date is fixed or flexible.	flexible

Output Schema

Name	Required	Description	Default
`report`	No
`status`	Yes
`criteria`	No
`guidance`	Yes
`duplicate`	No
`apartments`	No
`request_id`	Yes
`continuation_url`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 11, 2026
- removedInput schema / properties / city / enum
```
Removed value: -[
-  "Austin",
-  "Dallas",
-  "Houston"
-]
```
- addedInput schema / properties / city / maxLength
```
Added value: +40
```
- addedInput schema / properties / city / minLength
```
Added value: +1
```
AddedSep 15, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations only declare readOnly=false, destructive=false, idempotent=true, openWorld=false; the description adds genuinely new context: asynchronous human-in-the-loop flow (staff acceptance, VA gap verification, Alexander's judgment), no email being sent, no guaranteed completion time, and a private continuation link. It is consistent with the annotations and does not contradict them, though it does not discuss rate limits or permission/consent failure modes beyond mentioning consent.

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

Conciseness4/5

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

Four tight sentences, with the core action front-loaded and the workflow/return/exclusions following in a logical order. The trailing negative-sentence ('No immediate report, guaranteed completion time, or tour booking') is dense but earns its place; no filler.

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

Completeness4/5

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

With an output schema present and full schema description coverage, the description need not explain return payloads, and it still flags the continuation link. Combined with the annotations, an agent has enough to call this 15-parameter tool correctly, though the explicit sibling routing and retry semantics remain implicit.

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

Parameters3/5

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

Schema description coverage is 100% and 15 parameters are each documented in-schema (including the request_key idempotency rule and shortlist_token origin), so the schema carries the load. The description adds essentially no parameter-level detail beyond the 'with consent' framing, so the baseline 3 applies.

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

Purpose5/5

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

The opening sentence states a specific verb and resource — 'Submit a saved shortlist and renter brief' — so the agent knows exactly what is being created. It also differentiates from the tour sibling by declaring 'No ... tour booking', and it names the concrete outcome ('private continuation link'). This is well beyond a restatement of the name/title.

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

Usage Guidelines3/5

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

The description implies when this applies (a paid-research request that requires staff acceptance, with no immediate report) and rules out tour booking, but it never explicitly says 'use request_research_tours instead for tours' or states prerequisites like needing a prior create_shortlist. Usage is inferable but not spelled out against the sibling set.

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

All Taco Street Locating tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?