Get US rental market data from FRED BLS CPI series. Returns national rent index, YoY change, and monthly history.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of historical data points (default 12) | |
| metro | No | Metro area (optional; national data returned regardless) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It mentions the data source and return values, which is helpful, but does not disclose potential side effects, rate limits, or the fact that metro is ignored (national data always returned). It does not contradict anything, but there is room for more transparency about limitations.
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 the key verb and resource, and every phrase earns its place. It is concise and easy to parse, with no redundancy or 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?
With no output schema and only a simple input schema, the description needs to convey what the tool returns. It lists the key outputs, but it does not describe the output structure or explicitly note that metro is disregarded. Given the lack of annotations and output schema, the description is not fully complete for an agent to anticipate all behaviors.
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 100% of parameter descriptions, including 'limit' and 'metro' with their defaults and a hint that metro is optional. The tool description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 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 clearly states the action ('Get'), the resource ('US rental market data'), the source ('FRED BLS CPI series'), and the expected outputs ('national rent index, YoY change, and monthly history'). This differentiates it from sibling tools like get_home_prices and get_market_indicators by focusing specifically on rental data.
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 for when to use the tool (when US rental market data from FRED BLS CPI series is needed). However, it does not explicitly mention alternatives or exclusions, such as directing users to get_home_prices for home prices, nor does it note that metro parameters are ignored. It's useful but lacks explicit guidance beyond the core use case.
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.