Get key US housing market indicators from FRED: housing starts, building permits, median home price, 30-year mortgage rate, and Case-Shiller index.
| Name | Required | Description | Default |
|---|---|---|---|
| series | No | Comma-separated FRED series IDs to filter (e.g. "HOUST,MORTGAGE30US"). Valid: HOUST, PERMIT, MSPUS, MORTGAGE30US, CSUSHPINSA. Default: all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. The verb 'Get' suggests a read-only operation, and the description lists the data source (FRED) and indicators, but it does not disclose return format, historical depth, or behavior for invalid series. Basic but adequate for a simple read 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 a single, front-loaded sentence that efficiently communicates the tool's purpose and data source. No wasted words, directly actionable.
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 could explain what the response contains (e.g., time series, latest values). It lists the indicators but omits response structure. For a simple one-param tool, it is adequate but leaves room for ambiguity.
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 a well-described 'series' parameter listing valid FRED IDs. The description adds human-readable names (housing starts, building permits, etc.) that map to these IDs, providing meaning beyond the raw 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 retrieves key US housing market indicators from FRED, listing specific indicators. This distinguishes it from siblings like get_home_prices and get_rental_data by covering a broader set of market indicators.
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 fetching housing market indicators but does not explicitly compare with sibling tools or state when to choose this over get_home_prices or get_rental_data. No exclusions or alternative guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct data category (prices, broader indicators, rentals), but get_home_prices and get_market_indicators overlap on median price and Case-Shiller, which could cause confusion. The descriptions provide enough clarity to distinguish them.
All three tools follow a consistent 'get_' + descriptive noun pattern (get_home_prices, get_market_indicators, get_rental_data). No mixing of conventions or vague verbs.
With only 3 tools, the set is on the thin side for a real estate intelligence domain that could cover many more data points (e.g., home sales, inventory, affordability). It is not unreasonably sparse, but it feels minimal.
Covers home prices, market indicators, and rent, but lacks common housing metrics like sales volume, inventory, or property-level data. This is a notable gap for a housing intelligence server, though the existing tools cover core macro data.