USDV Capital — Your Real Estate CFO

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

Description adds context beyond annotations: states it schedules a free, no-obligation call where the advisor reviews details. Annotations already indicate a non-read-only, non-destructive mutation, but description clarifies the process and lack of credit check.

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?

Three concise sentences with front-loaded purpose. No wasted words; all information is relevant.

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?

Description covers the general process but does not explain return values (no output schema) or how the tool fits among many siblings. Missing details on what happens after scheduling (e.g., confirmation, calendar event).

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 detailed descriptions (e.g., email validation warnings, phone requirement). Description adds no further parameter context beyond the schema, so 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 tool schedules a consultation with a specific advisor, including duration, method, and conditions. It differentiates from siblings like action-prequalify by focusing on scheduling rather than financial qualification.

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 on when to use this tool versus alternatives like action-prequalify or deal-analyze. No mention of prerequisites, exclusions, or when not to use.

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

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

Annotations indicate readOnlyHint=false and destructiveHint=false. The description adds that there is no credit score impact, a dedicated advisor follows up within 24 hours, and a guarantee of response within 1 business day. This provides useful behavioral context beyond annotations.

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 concise with three sentences, front-loading the core action. It efficiently conveys purpose, process, and benefits without redundancy.

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?

Given the complexity (12 parameters, 8 required, no output schema), the description explains the outcome (advisor follow-up, no credit impact) and response time. It lacks details on prerequisites or post-submission steps, but is largely complete for a submission 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?

Schema description coverage is 100%, and the schema includes detailed descriptions for parameters like email, phone, and name. The main description does not add additional parameter semantics beyond the schema, so a score of 3 is appropriate.

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 verb 'Submit' and resource 'pre-qualification request' to USDV Capital for a capital strategy assessment. It differentiates from siblings like action-consultation and action-send_report by focusing on pre-qualification.

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 mentions no credit score impact and a guaranteed response time, which implies when to use (for capital assessment without credit impact), but does not explicitly contrast with alternatives or provide when-not-to-use guidance.

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

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

Annotations already indicate non-readOnly and non-destructive. Description adds only 'Free, no obligation,' which is marketing rather than behavioral context. No details on delivery confirmation, error handling, or authentication needs.

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?

Three concise sentences with the main action upfront. No waste or redundancy.

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?

Description covers purpose, when to use, and format. Missing potential info on delivery confirmation, but for a simple send action with complete schema and annotations, it is reasonably complete.

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 description coverage is 100%, so the description does not need to add parameter meaning. It ties calculationData to calculator output implicitly, but adds no new semantics beyond what the schema already provides.

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?

Clearly states it sends a PDF Capital Advisory Report to an investor's email. Distinguishes from sibling calculator tools by specifying 'Use after running any calculator tool.' Purpose is specific and unambiguous.

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?

Explicitly states 'Use after running any calculator tool,' providing clear context for when to use. No explicit when-not or alternatives, but the sibling set (all calculators) makes the distinction clear.

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

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

Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds context about capital cycle assessment but does not disclose any additional behavioral traits beyond the annotations. No contradictions.

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 core purpose. No wasted words, and the branding is integrated without redundancy.

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?

Given 13 parameters (4 required) and no output schema, the description provides a useful overview but does not detail the output format or how results are presented. It is adequate but not exhaustive.

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 description coverage is 100%, so all parameters already have descriptions. The tool description does not add extra meaning beyond the schema; it only gives a high-level overview of the strategy.

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 it analyzes a BRRRR strategy with complete capital cycle assessment, modeling all 5 phases. It specifies cash invested, cash recovered, and infinite return, distinguishing it from sibling tools like calc-flip_roi or calc-rental_cashflow.

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 BRRRR analysis but does not provide explicit when-to-use or when-not-to-use guidance, nor does it reference alternative tools. The context of sibling tools suggests differentiation, but no exclusions are stated.

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

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

Annotations already indicate read-only and idempotent behavior. The description adds valuable context about output specifics (itemized cost, timeline, contingency), which is beyond the annotations.

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 first two sentences are concise and informative. The third sentence is a promotional tagline about the company's financing services, which is not relevant to tool functionality and adds noise.

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 calculator tool with many siblings and no output schema, the description covers the tool's purpose and what it returns. It could mention return format, but the listed outputs (breakdown, timeline, contingency) are sufficient.

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 clear descriptions for all 7 parameters. The description mentions location, scope, and property type but does not add new meaning beyond the 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 it estimates construction and renovation costs by location, scope, and property type, and lists specific outputs (cost breakdown, timeline, contingency). This distinguishes it from sibling calc tools focused on other real estate metrics.

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 use for construction/renovation cost estimation, which is distinct from sibling tools. However, it does not explicitly contrast with alternatives or provide when-not guidance.

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

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

Annotations already indicate readOnlyHint true, destructiveHint false, idempotentHint true. The description adds no behavioral traits beyond the calculation itself; it mentions 'full CFO-level assessment' but doesn't clarify output format or side effects like sending reports (despite the sendReportTo parameter). No contradiction with annotations.

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 four sentences; the first three are informative, but the last sentence is promotional ('USDV Capital — Your Real Estate CFO...') and not useful for agent invocation. This reduces conciseness and includes irrelevant marketing content.

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?

Given 11 parameters and no output schema, the description provides some context (purpose, DSCR definition, parameter hints) but lacks details on calculation methodology, output structure, or prerequisites. The promotional content detracts from completeness.

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 description coverage is 100%. The description adds value by explaining that 'state' enables automatic tax/insurance estimation, and provides extensive guidance on 'sendReportTo' (do not guess email). This goes beyond schema descriptions, though other parameters are not elaborated.

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 that the tool calculates DSCR for rental properties and Airbnb, with specific verb 'Calculate' and resource 'Debt Service Coverage Ratio'. It distinguishes itself from sibling tools by focusing on DSCR as the primary qualification metric for cash-flow-based rental loans.

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 context on when to use: for rental properties that qualify on cash flow, not personal income, and lists applicable scenarios (long-term, Airbnb, BRRRR). However, it does not explicitly state when not to use or compare with sibling tools like calc-rental_cashflow.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds valuable behavioral context about what the tool calculates (specific financial metrics and deadlines) and mentions USDV Capital's financing services, which provides commercial context beyond the annotations' technical hints.

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 appropriately sized with two sentences: the first clearly states the tool's purpose and calculations, the second provides commercial context. While the promotional text could be considered extraneous, the core information is front-loaded and efficient.

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 calculation tool with good annotations (read-only, idempotent) and 100% schema coverage, the description provides sufficient context about what the analysis involves. The lack of output schema means return values aren't documented, but the description lists the calculated metrics, which helps understand expected outputs.

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 description coverage is 100%, so all parameters are documented in the schema. The description doesn't add specific parameter details beyond what's in the schema, but it provides overall context about what the calculation involves (1031 exchange analysis). Baseline 3 is appropriate when schema does the heavy lifting.

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 specific purpose: 'Analyze a 1031 exchange scenario for tax deferral' and lists exactly what it calculates (capital gains, depreciation recapture, estimated taxes deferred, key deadlines). It distinguishes from siblings by focusing on 1031 exchange analysis rather than other real estate calculations like BRRRR, DSCR, or rental cashflow.

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 context through 'Analyze a 1031 exchange scenario' and mentions deadlines, but doesn't explicitly state when to use this tool versus alternatives like 'deal-analyze' or other calculation tools. The promotional text about USDV Capital provides commercial context but not functional guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds context about the output (cost breakdown, profit analysis) but does not introduce additional behavioral traits beyond what annotations provide. No contradiction.

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 first two sentences are efficient and front-loaded. However, the third sentence is a promotional pitch for USDV Capital that is irrelevant to tool behavior, adding noise. Every sentence should earn its place; this one does not.

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?

Given 10 parameters with full schema coverage and no output schema, the description adequately explains what the tool calculates (ROI, profit analysis, costs). It provides enough context for an agent to understand the return value shape, though specific output fields (e.g., net profit, ROI percentage) are not enumerated.

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%, so baseline is 3. The description lists cost categories but does not add meaning beyond the schema descriptions (each parameter has its own description). It provides no additional parameter-level guidance.

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 calculates projected ROI for fix-and-flip projects, explicitly listing included costs (purchase, rehab, holding, selling, profit). It distinguishes from sibling tools like calc-brrrr by noting utility for BRRRR acquisition phase, making the purpose specific and well-differentiated.

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?

Usage context is implied by describing the tool's scope (flip projects, BRRRR acquisition), but it does not explicitly state when to use this tool versus alternatives (e.g., 'Use calc-brrrr for full BRRRR analysis'). No exclusions or when-not-to-use guidance is provided.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's job is reduced. The description adds value by detailing what the tool produces (NOI, cap rate, etc.) and the scope (CFO-level assessment), which helps set expectations. No contradictions with annotations.

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 concise at three sentences, with the purpose front-loaded. The final sentence ('USDV Capital — Your Real Estate CFO.') is a tagline that adds minimal value but does not detract significantly. Could be slightly tighter without the tagline.

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?

Given the tool's complexity (13 parameters, no output schema), the description usefully lists key output metrics (NOI, cap rate, cash-on-cash return, DSCR, expense breakdown). It does not explain return format or how outputs are presented, but the listed metrics provide sufficient context for an AI agent to understand the tool's value.

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 description coverage is 100%, so baseline is 3. The description does not add information about individual parameters; it only lists outputs. Parameter descriptions in the schema are already clear (e.g., 'Monthly HOA', 'Vacancy rate % (default 5)'), so description adds no extra meaning.

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 analyzes monthly and annual cash flow for rental properties, specifying outputs like NOI, cap rate, cash-on-cash return, DSCR, and expense breakdown. It mentions property types (long-term, Airbnb, buy-and-hold) but does not explicitly distinguish from sibling tools like calc-flip_roi or calc-brrrr, leaving some ambiguity.

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 by listing applicable property types ('long-term rentals, Airbnb, and buy-and-hold analysis') but provides no explicit guidance on when not to use it or alternatives among sibling tools. No exclusions or comparative context is given.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds context about outputs (occupancy projections, ADR, etc.) and the purpose of financing through DSCR loans. No contradictions.

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?

Description is two sentences: first sentence states purpose and outputs, second is marketing. Concise but includes unnecessary promotional language, slightly reducing efficiency.

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?

Given 7 parameters, no output schema, and 100% schema coverage, the description explains outputs well. It could mention return format but lists specific output types, making it mostly complete.

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 description coverage is 100%, so the schema already documents all parameters. The description does not add new semantic detail beyond what is in the 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?

Description clearly states the tool estimates short-term rental revenue potential based on location, bedrooms, and property type. It lists specific outputs (occupancy projections, ADR estimates, seasonal breakdown, comparison to long-term rental income), distinguishing it from siblings like calc-rental_cashflow.

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?

Description implies usage for STR revenue estimation but does not explicitly state when to use vs alternatives or when not to use. No mention of sibling tools or conditions.

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

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

Annotations already indicate readOnlyHint (true) and destructiveHint (false), so the agent knows it is safe. The description adds value by detailing what the analysis includes (market intelligence, financial projections, risk assessment, etc.) and that it produces a deal score (1-100), which goes beyond the annotations.

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 paragraph of about 4 sentences, front-loaded with the main purpose. It is efficient, though the inclusion of marketing language ('Your Real Estate CFO') is slightly superfluous but not harmful. Overall well-structured and concise.

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 covers the purpose and high-level components but does not explain the output format (the PDF report) or process. Despite having 14 parameters and no output schema, the description leaves some context gaps about what the agent or user receives.

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?

With schema_description_coverage at 100%, the parameter descriptions are already present. The tool description does not add additional meaning to the parameters beyond listing investment strategies, which mirrors the schema enums. Thus, no extra semantic value is provided.

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 performs a comprehensive deal analysis (the 'signature assessment') combining multiple evaluations into a single CFO-level report with a deal score. It distinguishes itself from sibling tools like specific calculators by indicating it is a holistic assessment.

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 is for any investment strategy when a comprehensive evaluation is needed, but it does not explicitly state when to use this tool over alternatives like the specific calculators (e.g., calc-flip_roi). No exclusions or when-not guidance is provided.

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

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

The description adds valuable behavioral context beyond annotations: it specifies the return format ('matching capital solutions with estimated terms'), mentions the financing range ('$150K to $10M'), and identifies the service provider ('USDV Capital'). While annotations cover read-only, non-destructive, and idempotent characteristics, the description provides practical implementation details that help the agent understand what to expect.

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 appropriately sized and front-loaded with the core purpose in the first sentence. The second sentence adds useful context about returns and service scope. While slightly promotional in tone ('Your Real Estate CFO'), every sentence contributes meaningful information without redundancy.

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?

Given the tool's moderate complexity, comprehensive annotations, and complete schema coverage, the description provides adequate context. It explains what the tool does, what it returns, and the service scope. The main gap is the absence of an output schema, but the description partially compensates by mentioning the return format ('matching capital solutions with estimated terms').

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?

With 100% schema description coverage, the input schema already documents all parameters thoroughly. The description doesn't add specific parameter semantics beyond what's in the schema, though it implicitly references some parameter concepts (like investment scenarios that map to loanPurpose). This meets the baseline expectation when schema coverage is complete.

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's purpose: checking financing eligibility for specific real estate investment scenarios through USDV Capital's network. It specifies the verb ('Check'), resource ('financing'), and scope (multiple investment types and geographic coverage), distinguishing it from sibling tools like 'eligibility-products' or calculation tools.

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 this tool: for checking financing eligibility across various real estate investment scenarios in all US states plus DC and Puerto Rico. However, it doesn't explicitly mention when NOT to use it or name specific alternatives among the sibling tools, though the context suggests it's for eligibility checking rather than calculations or market analysis.

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

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

Annotations already indicate this is a read-only, non-destructive, idempotent, and closed-world tool. The description adds context by specifying the source of capital (USDV Capital, institutional partners) and the goal (finding optimal structures), which helps the agent understand the business context. However, it doesn't disclose additional behavioral traits like rate limits, authentication needs, or response format details. No contradiction with annotations exists.

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 moderately concise but includes marketing language ('USDV Capital — Your Real Estate CFO') that doesn't directly aid tool selection. The first sentence effectively states the purpose, but subsequent details about use cases and sourcing could be more streamlined. It's front-loaded with key information but includes extraneous content that reduces efficiency.

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?

Given the tool's low complexity (1 parameter, no output schema) and rich annotations (read-only, idempotent, etc.), the description is somewhat complete. It covers what the tool does and the context but lacks details on output format or error handling. Without an output schema, the description doesn't explain return values, leaving a gap in completeness for agent invocation.

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 input schema has 100% description coverage for its single parameter 'product_type', with a clear enum-like list in the schema description. The tool description doesn't add any parameter-specific information beyond what's in the schema, such as default behavior or examples. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

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's purpose: to get detailed information about specific capital solutions (Fix & Flip loans, DSCR rental loans, bridge loans, ground-up construction financing). It lists the product types and use cases (house flipping, Airbnb, BRRRR strategy, etc.), making the verb+resource explicit. However, it doesn't distinguish this tool from sibling tools like 'eligibility-check' or 'action-consultation', which might overlap in providing capital-related information.

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 no guidance on when to use this tool versus alternatives. It mentions the types of loans and use cases but doesn't specify scenarios where this tool is preferred over siblings like 'eligibility-check' (which might verify eligibility) or 'action-consultation' (which could offer personalized advice). There's no explicit when/when-not or alternative tool references.

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

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

Annotations indicate read-only, non-destructive, and idempotent behavior, which the description does not contradict. The description adds value by specifying the analysis as 'CFO-level' and the target audience ('investors'), providing context beyond annotations. However, it does not detail rate limits, authentication needs, or specific output format, leaving some behavioral aspects uncovered.

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 concise and front-loaded, with the core purpose in the first sentence and usage context in the second. The third sentence ('USDV Capital — Your Real Estate CFO.') is promotional and adds no functional value, slightly reducing efficiency. Overall, it is well-structured but includes minor waste.

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?

Given the tool's complexity (comparative analysis across markets) and lack of output schema, the description provides good context on purpose and usage. Annotations cover safety and idempotency, but the description could better explain output expectations or limitations. It is mostly complete but has room for improvement in detailing behavioral aspects.

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 description coverage is 100%, with the 'locations' parameter documented as 'Array of locations to compare'. The description adds no additional parameter semantics beyond this, such as format examples or constraints. Given high schema coverage, the baseline score of 3 is appropriate, as the description does not compensate but also does not detract.

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's purpose: 'Compare real estate investment metrics across 2-5 US markets side-by-side with CFO-level analysis.' It specifies the verb ('compare'), resource ('real estate investment metrics'), scope ('2-5 US markets'), and analytical depth ('CFO-level analysis'), distinguishing it from sibling tools like 'markets-stats' or 'markets-screener'.

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 usage: 'Ideal for investors deciding where to deploy capital.' It implies when to use the tool but does not explicitly state when not to use it or name alternatives among siblings like 'markets-nearby' or 'markets-search'. This gives good guidance but lacks explicit exclusions.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds valuable behavioral context by specifying the sorting behavior ('sorted by distance'), the underlying technology ('PostGIS proximity search'), and the type of results ('investment metrics'), which goes beyond what annotations provide.

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 appropriately sized with two sentences: the first explains the tool's function and method, the second provides branding. The first sentence is front-loaded with essential information, though the branding sentence adds minimal functional value.

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?

Given the tool's moderate complexity (5 parameters, 100% schema coverage, annotations covering safety aspects), the description provides good context about what the tool does and how it works. The main gap is the lack of output schema, so the description doesn't detail the structure of returned 'investment metrics,' but this is partially compensated by the behavioral transparency.

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 description coverage is 100%, so all parameters are documented in the schema. The description doesn't add any parameter-specific information beyond what's in the schema, but it does imply the purpose of latitude/longitude parameters ('within a radius'). This meets the baseline of 3 when schema coverage is complete.

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 specific action ('Find nearby real estate markets'), the method ('using PostGIS proximity search'), and the output ('Returns markets sorted by distance with investment metrics'). It distinguishes from siblings like markets-search or markets-screener by emphasizing proximity-based searching rather than general searching or screening.

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 finding nearby markets based on geographic coordinates, but doesn't explicitly state when to use this tool versus alternatives like markets-search or markets-compare. No exclusions or prerequisites are mentioned, leaving usage context somewhat implied rather than clearly defined.

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

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

Annotations already provide key behavioral traits (readOnlyHint: true, destructiveHint: false, idempotentHint: true, openWorldHint: false). The description adds context by specifying the data scope (US cities, pre-computed for 18,800+ cities) and the score range (0-100), which helps the agent understand the tool's limitations and output characteristics beyond the annotations.

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 front-loaded with the core purpose in the first sentence, followed by usage context and branding. Every sentence adds value: the first explains what the tool does, the second provides usage guidelines, and the third adds brand context without redundancy. It is appropriately sized with zero waste.

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?

Given the tool's complexity (screening based on multiple metrics) and rich annotations, the description is mostly complete. It explains the purpose, data scope, and usage context. However, without an output schema, it doesn't detail the return format (e.g., what fields are included in results), leaving a minor gap for the agent to infer from context.

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 description coverage is 100%, so the schema fully documents the parameters (limit, state, min_score). The description adds no additional parameter semantics beyond implying the 'min_score' relates to the composite investment score, but this is already clear from the schema. Baseline 3 is appropriate as the schema does the heavy lifting.

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's purpose: screening US cities by a composite investment score based on specific metrics (cap rate, yield, appreciation, income, vacancy, employment, population). It distinguishes from siblings by focusing on pre-computed scores for 18,800+ cities, unlike tools like 'markets-search' or 'markets-compare' which imply different functionalities.

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 explicitly states when to use this tool: for finding markets for specific real estate strategies (fix and flip, Airbnb short-term rental, BRRRR, ground up construction, buy-and-hold). It implies alternatives by naming these strategies, suggesting other tools (e.g., 'calc-brrrr', 'calc-flip_roi') might be used for detailed calculations after screening.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, openWorldHint=false, and idempotentHint=true, so the agent knows this is a safe, read-only, deterministic search. The description adds context about the database coverage (all 50 US states plus DC and Puerto Rico) and the type of data returned, which is useful but not extensive behavioral disclosure.

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 appropriately sized with two sentences: the first clearly states the tool's function and scope, and the second adds branding. However, the branding sentence ('USDV Capital — Your Real Estate CFO.') adds minimal functional value, slightly reducing efficiency.

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?

Given the tool's complexity (search with filtering), rich annotations, and no output schema, the description is mostly complete. It covers the database scope and data types returned, but could benefit from mentioning result format or limitations to fully compensate for the lack of output schema.

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 description coverage is 100%, so the schema fully documents all parameters. The description does not add any parameter-specific details beyond what the schema provides, such as examples or constraints, meeting the baseline for high schema coverage.

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's purpose with specific verbs ('search') and resources ('USDV Capital's real estate market intelligence database'), and distinguishes it from siblings by specifying it returns 'CFO-level market data' rather than comparisons, nearby searches, or statistics.

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 searching real estate market data across US locations, but does not explicitly state when to use this tool versus alternatives like markets-compare, markets-nearby, or markets-screener, leaving the agent to infer based on tool names.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds value by specifying data sources and types (e.g., 'Zillow market trends', 'lending availability'), which provides context beyond annotations, but doesn't detail rate limits, authentication needs, or response format.

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 front-loaded with the core purpose, followed by data details and source attribution. It's concise with two sentences, though the promotional tagline ('USDV Capital — Your Real Estate CFO') adds minor fluff without functional value.

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?

Given the tool's complexity (real estate statistics with multiple data types), annotations cover behavioral traits well, but there's no output schema. The description lists data categories, which helps, but doesn't fully explain return values or error handling, leaving gaps in completeness for an agent.

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 description coverage is 100%, with clear parameter descriptions in the schema. The description doesn't add any parameter-specific information beyond implying 'location' and 'state' are used to fetch statistics, so it meets the baseline of 3 without compensating for gaps.

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's purpose: 'Get detailed real estate market statistics for a specific location' with specific data types listed (demographics, housing data, Zillow trends, investment metrics, lending availability). It distinguishes from siblings like 'markets-compare' or 'markets-screener' by focusing on comprehensive statistics for a single location, though it doesn't explicitly name alternatives.

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 no guidance on when to use this tool versus alternatives like 'markets-compare' or 'markets-screener'. It mentions data sources (Census ACS 2023, Zillow Feb 2026) which implies currency, but offers no explicit context, prerequisites, or exclusions for usage.

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

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

Annotations indicate read-only, non-destructive, and idempotent behavior, which the description doesn't contradict. The description adds context by specifying the domain (real estate investments) and topics covered (e.g., asset protection, financing implications), which goes beyond annotations to clarify the tool's scope and output nature, though it doesn't detail rate limits or auth needs.

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 but includes promotional content ('USDV Capital — Your Real Estate CFO') that doesn't aid tool selection or invocation. This wastes space and reduces clarity, making it less front-loaded and efficient than it could be.

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?

Given the annotations cover safety (read-only, non-destructive) and the schema fully describes parameters, the description provides basic domain context. However, with no output schema and a tool that likely returns complex guidance, the description could better outline expected outputs or result types to compensate for the lack of structured output information.

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 description coverage is 100%, so parameters like 'state' and 'annualRevenue' are well-documented in the schema. The description doesn't add any specific meaning or usage details for these parameters beyond what's in the schema, meeting the baseline for high coverage without extra value.

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 mentions 'entity structuring for real estate investments' and lists topics like LLC formation and financing implications, which gives a general purpose. However, it lacks a specific action verb (e.g., 'get guidance' or 'analyze') and doesn't clearly differentiate from siblings like 'util-insurance' or 'util-property_tax', making it somewhat vague rather than precise.

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 explicit guidance is provided on when to use this tool versus alternatives. The description mentions 'USDV Capital' as a service provider, but this doesn't help an AI agent decide between this tool and siblings like 'action-consultation' or 'eligibility-check'. There's no indication of prerequisites, exclusions, or comparative context.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds that it 'includes flood zone assessment,' which is useful behavioral context beyond annotations. However, it doesn't disclose rate limits, authentication needs, or detailed output behavior (e.g., cost breakdowns).

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: the first is functional and concise, but the second is promotional ('USDV Capital — Your Real Estate CFO...') and adds no operational value. This reduces efficiency, as the second sentence doesn't help the agent use the tool effectively.

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?

Given annotations cover safety and idempotency, and schema has 100% description coverage, the description is moderately complete. However, with no output schema, it doesn't explain return values (e.g., cost estimates, flood risk details). The promotional text detracts from completeness, leaving gaps in practical usage context.

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 description coverage is 100%, so parameters are documented in the schema. The description doesn't add any parameter-specific details beyond implying 'flood zone assessment' might relate to 'state' or other inputs. With high schema coverage, the baseline is 3, and the description doesn't significantly enhance parameter understanding.

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's purpose: 'Estimate property insurance costs including flood zone assessment.' It specifies the verb ('estimate'), resource ('property insurance costs'), and includes a key feature ('flood zone assessment'). However, it doesn't explicitly differentiate from sibling tools like 'util-property_tax' or 'util-rent_estimate' beyond the insurance focus.

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 no guidance on when to use this tool versus alternatives. It mentions that 'USDV Capital — Your Real Estate CFO — includes insurance estimates in all capital advisory assessments,' but this is promotional rather than practical usage advice. There's no indication of prerequisites, when to choose this over other tools, or contextual constraints.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds context about the analysis scope (demographics, income, employment, etc.) and mentions 'investment grade (A/B/C/D)' which provides useful behavioral context beyond annotations. However, it doesn't disclose potential rate limits, authentication needs, or data freshness.

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 appropriately sized with two sentences: one describing the analysis purpose and components, and one providing branding. The first sentence is front-loaded with key information. The branding sentence adds minimal value but doesn't significantly detract from conciseness.

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?

Given the tool's complexity (investment analysis with multiple components), lack of output schema, and rich annotations, the description provides adequate purpose context but lacks details about return format, data sources, or analysis methodology. The annotations cover safety aspects, but for a data analysis tool, more behavioral context would be helpful for an agent to understand what to expect.

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 description coverage is 100% with both parameters clearly documented in the schema. The description doesn't add any parameter-specific semantics beyond what's in the schema (state and location parameters). With complete schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate for any gaps.

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 performs 'Detailed neighborhood or city analysis for investment due diligence' and lists specific analysis components (demographics, income, etc.), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this analysis tool from sibling tools like 'markets-stats' or 'markets-search' that might provide related market 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 mentions 'investment due diligence' as a use case but provides no guidance on when to use this tool versus alternatives like 'markets-screener' or 'markets-stats'. There's no explicit when/when-not guidance or named alternatives, leaving the agent to infer usage context from the description alone.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds minimal behavioral context beyond this, mentioning it's for 'USDV Capital' branding but not detailing rate limits, authentication needs, or specific data sources. No contradiction with annotations exists.

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 appropriately sized and front-loaded: the first sentence states the core functionality, the second provides usage context, and the third is branding. While the branding sentence adds minimal functional value, the overall structure is efficient with zero wasted words on repeating schema details.

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?

Given the tool's moderate complexity (3 parameters, no output schema), annotations cover safety aspects, and schema has full description coverage. The description adds purpose and usage context but lacks details on return values (e.g., tax rate format, estimated tax calculation method) or error handling. It's adequate but has clear gaps for a tool without an output schema.

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 description coverage is 100%, so parameters are well-documented in the schema. The description mentions 'county or city' and 'property value for tax estimate,' which aligns with but doesn't add significant meaning beyond the schema. With high schema coverage, the baseline score of 3 is appropriate as the description provides no extra parameter insights.

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's purpose: 'Look up property tax rates and estimated annual taxes for any county or city.' It specifies the verb ('look up'), resource ('property tax rates and estimated annual taxes'), and scope ('any county or city'). However, it doesn't explicitly differentiate from sibling tools like 'util-insurance' or 'util-rent_estimate' beyond the domain context.

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 implied usage context: 'Essential for calculating holding costs in rental and flip analysis.' This suggests when to use it (real estate financial analysis) but doesn't explicitly state when not to use it or name alternatives among sibling tools. The context is clear but lacks explicit guidance on tool selection.

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

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

Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds valuable context about data sources (Zillow, Census, STR comparison, vacancy rates) and the provider (USDV Capital), which helps understand the tool's behavior and reliability. No contradiction with annotations.

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 appropriately concise with two sentences: one stating the tool's purpose and data sources, and another providing branding. It's front-loaded with key information, though the branding sentence adds minimal functional value.

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?

Given the tool's moderate complexity (3 required parameters, no output schema), annotations cover safety aspects well. The description adds data source context but lacks details on output format, accuracy, or limitations. It's adequate but has clear gaps in completeness for a tool that estimates financial values.

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 description coverage is 100%, with clear parameter descriptions in the schema. The description mentions 'location and bedroom count' which aligns with parameters but doesn't add meaningful semantics beyond what's in the schema. Baseline 3 is appropriate given high schema coverage.

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's purpose: 'Estimate fair market rent by location and bedroom count.' It specifies the verb (estimate) and resource (fair market rent) with key parameters. However, it doesn't explicitly differentiate from sibling tools like 'calc-rental_cashflow' or 'calc-str_revenue' which might also involve rent calculations, missing full sibling differentiation.

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 no guidance on when to use this tool versus alternatives. It mentions data sources (Zillow, Census, STR comparison) but doesn't specify scenarios, prerequisites, or exclusions. With many sibling tools in real estate analysis, this lack of contextual guidance is a significant gap.

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