Door Effect: 38% of explainable variation in FHA denial outcomes is lender identity, not the applicant's file (859,090 decisions). Historical observation computed from the public CFPB HMDA 2025 record (actions 1,2,3; loan_type 2). Not a prediction about any individual application. Attribution: FinanceRateCalc, CC BY 4.0.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full weight. It discloses important behavioral aspects: the finding is a historical observation from a public dataset, not a prediction about individuals, and includes source attribution. This adds context beyond a simple 'returns summary.'
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 extremely concise, with every sentence providing unique context (the statistic, data source, caveat, attribution). It is front-loaded with the key finding and avoids fluff.
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 tool with no parameters and no output schema, the description fully conveys what the summary contains, its provenance, and its limitations. It is complete for an agent to select and invoke this simple read-only tool.
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 tool has zero parameters, so the baseline is 4. The description does not need to explain parameters, and the schema covers the (empty) parameter list.
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 identifies the tool as providing a summary of the 'door effect' with specific statistics, but it lacks an explicit verb like 'returns' or 'provides.' It is unambiguous about the resource but could be mistaken for the output content itself rather than a tool description.
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?
No guidance is provided on when to use this tool compared to siblings like get_lender_denial_stats or get_national_fha_stats. It does not state any exclusions or alternative tool recommendations.
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 scope: national, state, lender, metro gap, door effect, lender listing, and claim certification. The purposes are clearly separable even though several tools concern FHA denial statistics.
Tool names follow a consistent verb_noun snake_case pattern: get_* for retrievals, list_lenders for enumeration, and check_claim_contract for validation. There are no convention clashes or vague single-word names.
Seven tools is well-scoped for a focused statistics and claim-validation server. Each tool serves a distinct purpose and none feel redundant or bolted on.
The surface covers the main read-only operations: national, state, lender, metro, and door-level stats plus lender listing and claim contract verification. Minor gaps include retrieval of full contract metadata or other statistic categories, but core workflows have no dead ends.