compare_loan_offersRank competing loan offers by true cost of capital, not headline rate. Accounts for origination, exit and other fees over the actual term, and returns an effective rate, total cost and fee burden in basis points for each — so a 'cheaper' rate with heavy fees sorts correctly.
| Name | Required | Description | Default |
|---|---|---|---|
| offers | Yes |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint true and destructiveHint false, covering safety. The description adds valuable context about the calculation methodology (accounting for origination, exit, and other fees, correcting misordering) and the output (effective rate, total cost, fee burden). This goes beyond annotations and gives insight into the tool's behavior.
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?
Two sentences, no redundancy. The core purpose is front-loaded, followed by a brief explanation of the calculation logic. Every sentence earns its place, making it appropriately sized and well-structured.
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?
The description specifies the output (effective rate, total cost, fee burden) which is essential given no output schema. It also explains the rationale, making the tool's behavior clear. It does not mention the minimum of 2 offers (which is in the schema) or edge cases, but for a comparison tool with moderate complexity, this is adequate. A 4 reflects the slight gap in explicit prerequisites.
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 includes descriptions for term and interestRate, but the overall schema description coverage is reported as 0%. The description mentions fee types (origination, exit, other fees) but does not explain individual parameters like loanAmount or the structure of the offers array. It provides some meaning about the overall logic but not enough to fully compensate for the low coverage. A 3 reflects the partial compensation.
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?
Description explicitly states the tool's function: ranking loan offers by true cost of capital, not headline rate. It specifies the resource (loan offers) and the action (compare/rank), and differentiates from siblings by focusing on true cost with fee adjustments. This is a specific verb+resource that distinguishes it clearly.
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 when you have competing loan offers and need to compare their true costs. It does not explicitly mention alternatives or when not to use it, but the purpose is clear enough that an agent would know to use it for comparison scenarios. Lacks explicit exclusions, so a 4 is appropriate.
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.