Japan Real Estate Intel

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

Annotations already provide readOnlyHint=true and destructiveHint=false, so the description does not need to repeat safety traits. The description adds context about calculating various costs and yields and including future plan upside, but does not disclose further behavioral details like data sources, update frequency, or precision of estimates.

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 two sentences, one in English and one in Japanese. It front-loads the main purpose and key outputs. No redundant information.

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 has 6 parameters, no output schema, and moderate complexity, the description provides a high-level overview but lacks details on return structure, data sources, or how future plan upside is computed. While annotations cover safety, the description could be more complete for a data-driven analysis 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%, so the schema already documents all parameters well. The description does not add additional parameter-level meaning beyond mentioning the calculation outputs. Baseline 3 is appropriate as the schema carries the load.

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 acquisition cost, renovation cost, expected rent, and gross/net yield for Nagoya neighborhoods. It uses specific verbs and resources. However, it does not explicitly differentiate from sibling tools like 'recommend_renovation_targets' or 'composite_value_score', which are similar in domain.

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 the tool is for renovation yield analysis but offers no explicit guidance on when to use it versus alternatives. It does not mention prerequisites or cases when it should not be used. The usage context is assumed from the task name.

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. The description adds that the tool returns a risk score and deal-breakers, which is behavioral context beyond annotations. However, it does not detail the output structure or any side effects.

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 in English and two in Japanese, conveying the core purpose and output succinctly. While bilingual duplication is present, each part is functional. It could be slightly more concise by removing the Japanese, but is acceptable.

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 a nested object parameter and no output schema, the description is incomplete. It does not specify the output format (e.g., numeric score, list of strings) or clarify the geographic context (Nagoya wards implied by 'ward' parameter). This leaves the agent uncertain about expected return structure and scope.

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 with clear definitions for each parameter. The tool description adds value by listing example clause types (financing contingency, inspection, future value terms) that go beyond the schema's generic 'JSON format' description for proposedTerms, helping the agent understand expected content.

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 ('assess') and resource ('contract risk'), and specifies the action (analyze proposed clauses, return risk score with deal-breakers). It distinguishes from siblings like 'assess_property_risk' by focusing on contract clauses, but does not explicitly differentiate from other risk 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?

No guidance is provided on when to use this tool versus alternatives like 'assess_property_risk' or 'generate_contract_support_package'. There are no exclusions or prerequisites mentioned, leaving the agent without context for appropriate invocation.

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. The description adds context about the three assessment axes (education, safety, healthcare) and scope (10 prefectures), which is useful but does not detail data sources or scoring methods. With annotations covering safety, this is adequate but not rich.

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 (two sentences: one English, one Japanese). The English sentence is front-loaded with key information. The Japanese repetition adds redundancy but supports bilingual users. Overall, every part serves a purpose with minimal 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 (6 parameters, nested objects, no output schema), the description covers only purpose and axes. It lacks information on how to use parameters, expected output format, or data limitations. While annotations help, more detail (e.g., scoring output) would improve 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 67% (4 of 6 parameters have descriptions). The tool description does not mention any parameters or provide additional context beyond the schema. For parameters like childAge and latlng, the description offers no guidance on values or usage, failing to compensate for moderate 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 it assesses family-friendliness across education, safety, and healthcare axes for 10 prefectures. This is a specific verb+resource, differentiating it from sibling tools like compare_prefectures or assess_contract_risk. However, it does not specify which 10 prefectures, leaving slight 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 for family-friendliness evaluation but provides no explicit guidance on when to use this tool versus alternatives (e.g., compare_prefectures for broader comparisons). No exclusion criteria or prerequisites are mentioned.

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 declare readOnlyHint=true, so the description does not need to reiterate safety. It adds behavioral context about integrated scoring across 10 prefectures and three risk types, 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?

Two sentences, one English one Japanese, front-load critical purpose and scope with zero waste. Every clause is necessary.

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 should hint at return format or interpretation guidance. It mentions 'integrated scoring' but lacks detail on how scores are presented or used. Given 5 parameters including nested objects, more completeness would help.

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 60% (3 of 5 parameters described). The description mentions flood, landslide, earthquake which correspond to the riskTypes enum already in schema, adding no new meaning. The remaining parameters (latlng, riskTypes without description) are not addressed.

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 uses specific verb 'assess' and resource 'property disaster risk', enumerates risk types (flood, landslide, earthquake) and geographic scope (10 prefectures), clearly distinguishing it from sibling tools like assess_contract_risk or assess_family_friendly_score.

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 property risk assessment and provides geographic coverage, but does not explicitly state when to use it versus alternatives or exclude scenarios. Lacks guidance on prerequisites or 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 declare readOnlyHint=true and destructiveHint=false. The description adds that the output is Markdown (though schema has exportFormat) and produces rankings. It does not contradict annotations and provides useful behavioral context beyond the structured data.

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 (English + Japanese) with no wasted words. It front-loads the core purpose and key constraints (up to 5 prefectures, metrics, ranking, output format).

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 and no output schema, the description is brief. It covers the main intent but lacks details on how to use parameters like exportFormat or includeMarkdown, and does not explain return structure beyond 'Markdown output'. For a complex tool, more completion would be beneficial.

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 57%. The description adds meaning by listing key metrics (land price, population, risk, investment score) that correspond to the 'metrics' parameter. It also clarifies the tool compares up to 5 prefectures, which maps to 'prefectures' maxItems. However, it does not address other parameters like area, neighborhood, or propertyType.

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 compares up to 5 prefectures on metrics like land price, population, risk, and investment score, producing a ranking. This differentiates it from many sibling analysis tools that focus on single prefectures or other aspects.

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 comparing prefectures but provides no explicit guidance on when to use this tool versus alternatives like drill_down_local_analysis or composite_value_score. No exclusions or best practices are mentioned.

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, so no mutation concerns. The description adds useful behavioral details about outputs (radar, tier, peer comparison, AI narrative) and mentions fusion of axes. It does not contradict 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 two sentences, front-loads the core purpose and key outputs, and includes both English and Japanese for bilingual accessibility. Every sentence provides value 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 existence of an output schema, the description adequately covers the tool's main purpose and outputs. However, it omits that AI narrative requires a Gemini API key, which could affect tool usage. Still, for selection purposes it is largely 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 each parameter is already documented. The tool description does not add meaning beyond summarizing the 5 axes. Parameter defaults, constraints, and the API key requirement for narrative are only 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?

The description clearly states the tool fuses 5 specific axes into a single 0-100 score and lists additional outputs (radar, tier, peer comparison, AI narrative). This distinctively separates it from single-axis sibling tools like assess_family_friendly_score or forecast_land_price_trend.

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 when to use (composite scoring) but provides no explicit guidance on when not to use it or direct comparisons to siblings. It lacks context like 'Use this when you need an overall area value, not a specific metric.'

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 declare readOnlyHint=true and destructiveHint=false, so the description adds the operational scope (10 prefectures, output modes) and factors. However, no additional behavioral details like rate limits, data freshness, or error handling are provided.

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 in English and Japanese, front-loading the purpose and scope. No wasted words; every phrase adds 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?

For a complex tool with 14 parameters, the description covers the main analysis dimensions and scope (10 prefectures). It hints at output modes but does not explain what the report includes. Given no output schema, more detail on return value would improve 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 79%, so many parameters already have descriptions. The tool description adds high-level context (factors, prefecture limit) but does not deepen understanding of individual parameters beyond schema. Baseline 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?

Description clearly states the tool performs cross-analysis of multiple real estate market factors (land price trends, investment score, foot traffic, education, corporate presence) across 10 prefectures. The verb 'cross-analyze' and listed factors distinguish it from siblings like compare_prefectures or drill_down_local_analysis.

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 does not explicitly state when to use this tool versus alternatives. It mentions '10 prefectures' as a constraint but lacks guidance on scenarios where cross-analysis is appropriate vs. other tools like compare_prefectures or composite_value_score.

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 to add context. It does so by explaining the triangulation method (cross-checking three price types) and the signal categories, which informs the agent about the tool's scope and outputs. 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 brief (two sentences) and front-loaded with the core purpose. The bilingual format (English and Japanese) adds some redundancy but is useful for multilingual contexts. It is appropriately sized, with no wasted words, though the bilingual could be considered less concise for a single-language agent.

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 has 5 optional parameters, clear annotations, and an output schema (as indicated in context signals), the description provides sufficient context about what the tool does and what signals it produces. It does not explain return format, but the output schema fills that gap. The lack of usage guidance against siblings is a minor gap, but overall it is complete enough.

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?

All 5 parameters are described in the input schema with 100% coverage, so the baseline is 3. The description adds overarching context about the three price types but does not add per-parameter meaning beyond what the schema provides. It mentions output modes compact/detailed but these are already 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?

The description clearly states the tool's purpose: it is a price triangulation arbitrage scanner that cross-checks three valuation metrics (rosenka, koji, tx) to detect discount buys, inheritance-tax edges, and overheated markets. It uses specific verbs ('cross-checks', 'detect') and distinguishes from siblings by focusing on arbitrage signals, while siblings cover renovation yield, contract risk, etc.

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 scanning arbitrage opportunities in real estate, but it does not explicitly state when to use this tool versus alternatives (e.g., compare_prefectures, forecast_land_price_trend). There is no mention of prerequisites or when not to use it. Given the many sibling tools, more explicit guidance would be helpful.

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 the tool is read-only and non-destructive. The description adds that it performs a cross-scan and returns hypothesis cards with multi-source scoring, which provides some behavioral context but not details on execution limits, auth needs, or error handling.

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 two sentences (English and Japanese) that front-load the key function. However, the Japanese version is redundant and could be streamlined. Still, it is efficient and avoids unnecessary detail.

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 has 10 parameters (0 required) and an output schema, the description provides a high-level overview but does not explain default behaviors, parameter interactions, or the structure of outputs. It is sufficient for a basic understanding but not fully complete for complex use cases.

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 70%, so the input schema already documents most parameters. The overall description does not add new parameter-level meaning beyond what is in the schema. It briefly mentions 'goal' (investment/store/family/office/development) but does not elaborate on the others.

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 scans a prefecture for undervalued areas matching a goal and returns hypothesis cards with multi-source scoring. The verb 'scan' and resource 'prefecture' are specific, but it does not explicitly differentiate from sibling tools like 'search_area_candidates' which might have similar functionality.

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 over alternatives. The description implies it is for the discovery phase (e.g., 'next areas to look at'), but does not state conditions, prerequisites, or when not to use it.

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, establishing a safe read-only behavior. The description adds that the tool includes foot traffic, commercial, and education data, and outputs markdown. However, it does not explain behavioral traits like data source freshness, rate limits, or authorization requirements. Given the annotations, the description offers moderate added value.

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 English description is a single concise sentence followed by a Japanese translation. It is front-loaded with the key action and resource. While the Japanese version is redundant for English agents, it does not significantly hinder conciseness. Every element earns its place, though the sentence could be slightly more streamlined.

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 has 5 parameters (1 required, 2 enums) and no output schema, the description provides a high-level overview of the analysis content but omits details on output structure beyond mentioning markdown. It does not explain how parameters like 'focus' or 'exportFormat' affect the output. The description is adequate for understanding the tool's purpose but leaves gaps for complex usage scenarios.

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 80% (4 of 5 parameters have descriptions). The tool description does not add new parameter information beyond the schema; it mentions the types of analysis (foot traffic, commercial, education) but does not map these to parameters. The 'focus' parameter lacks a schema description, and the tool description does not compensate for this gap. Therefore, the description provides marginal added value over 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 the tool performs drill-down local analysis at block/neighborhood level, covering foot traffic, commercial, and education. It effectively distinguishes itself from sibling tools like 'compare_prefectures' and 'get_chochou_profile' by specifying the granularity and content scope. The verb 'drill-down' combined with the resource 'local analysis' provides a specific and actionable purpose.

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 offers no explicit guidance on when to use this tool versus alternatives, such as 'get_chochou_profile' or 'generate_area_report'. Without usage context or exclusions, an AI agent must infer the tool's applicability solely from the tool name and sibling list, which is insufficient for informed 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 declare readOnlyHint=true and destructiveHint=false. The description adds constraints like 10 prefectures but does not elaborate on return format or data sources. It meets the baseline but adds limited context 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 concise with two language versions, but the duplication adds unnecessary length. It is front-loaded with the main purpose, but the Japanese version is redundant for an English-dominant agent interface.

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 7 parameters, nested objects, and no output schema, the description should clarify return values (e.g., score format) and constraints. It only mentions '10 prefectures' but does not explain how the score is derived or what the output looks like.

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 high (86%), so the baseline is 3. The description does not add parameter-level detail beyond what the schema already provides. The bilingual text reiterates purpose but not parameter 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 evaluates store location suitability considering foot traffic, transport, and competitor distribution. However, it does not differentiate from sibling tools like compare_prefectures or search_area_candidates that may have overlapping functionality.

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 usage guidance is provided. The description does not indicate when to use this tool compared to alternatives, nor does it mention prerequisites like data availability for all 10 prefectures.

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. Description adds no additional behavioral context (e.g., side effects, auth). 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?

Two sentences (English and Japanese), front-loaded with action and output. No unnecessary words.

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 simple tool with one param and no output schema, description provides sufficient context: source (search results), output format (Markdown). Could mention dependency on search more explicitly, but it's clear enough.

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 detailed ID description. Overall description reinforces but adds no new parameter meaning beyond 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 it fetches full document by ID from search results, with specific return format (area analysis, forecasts, summaries in Markdown). It differentiates from sibling search tool by specifying 'from search results'.

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?

Implicitly suggests use after search to get full document, but no explicit when-not-to-use or alternatives mentioned. Context is clear but lacks exclusion criteria.

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 tool is safe. The description adds context about the forecasting methods (linear regression, moving average) and outputs (CAGR, signal), which are not in 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 relatively concise but includes a full Japanese translation that duplicates the English content, which adds length without new value. The purpose is front-loaded, but the duplication 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 complexity (7 parameters, no output schema), the description should more thoroughly explain data sources, historical range, and interpretation of confidence interval. It covers key outputs but lacks completeness for a forecasting tool, especially 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 86%, so most parameters are already well-described. The description adds value by mentioning '10 prefectures' (a constraint not in schema) and the return values (CAGR, signal). However, it does not provide additional semantics for individual parameters beyond what the schema offers.

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 forecasts land price trends using specific methods (linear regression, moving average) and returns concrete outputs (CAGR, confidence interval, investment signal). It distinguishes itself from siblings by focusing on trend forecasting with geographic limitation (10 prefectures).

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 land price trend forecasting but does not explicitly state when to use this tool versus alternatives like cross_analyze_real_estate_market or get_real_estate_macro_snapshot. No 'when not to use' or guidance on selection criteria.

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=true and destructiveHint=false, so the tool is safe. The description adds branding and format support but does not detail report contents or limitations. It neither contradicts nor significantly extends 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 two short sentences (English and Japanese), front-loaded with core purpose. It is concise but could be slightly more 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?

With 13 parameters, 2 required, and no output schema, the description is too brief. It does not explain parameter relationships (e.g., prefecture vs area) or what 'comprehensive' means. Incomplete for a complex report generator.

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 77%, so most parameters have inline descriptions. The tool description does not add parameter-level meaning beyond summarizing purpose. Baseline score 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 tool generates comprehensive area reports in Markdown/PDF with branding support, and mentions it covers 10 prefectures. This distinguishes it from sibling analysis 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?

No explicit guidance on when to use this tool vs alternatives like compare_prefectures or get_chochou_profile. The description does not mention use cases or 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 declare readOnlyHint=true, so the tool is read-only. The description adds that it generates Markdown and a branded PDF, providing additional context about the output format. No contradictions with annotations, and the description does not hide any behavioral traits.

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: two sentences in English followed by a Japanese translation. It front-loads the key outputs (risk matrix, negotiation anchors, clauses) and mentions the output format. No unnecessary words or repetition. The structure is 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?

Given the tool's complexity (generating a multi-component package) and no output schema, the description is somewhat vague about the exact structure and contents of the generated package. It states 'Markdown + branded PDF' but does not detail what each component contains. Adequate for a basic understanding but leaves gaps.

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. The description does not add meaning beyond what the schema already provides for individual parameters. The general mention of 'neighborhood/property data' provides context but no parameter-specific enrichment.

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 explicitly states the tool generates a contract support package including risk matrix, price negotiation anchors, and recommended clauses from neighborhood/property data. This clearly distinguishes it from sibling tools like assess_contract_risk, which only assesses risk, and other single-purpose 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 implies the tool is used when a comprehensive contract support package is needed, but it does not explicitly state when to use it versus alternatives, nor does it provide when-not-to-use guidance. Usage is implied by the tool's purpose.

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, safe. Description adds that it returns current metrics, but lacks details on error handling, pagination, or what happens with invalid input. Adds moderate value 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?

Two sentences, bilingual, front-loaded with core purpose. No wasted words. Perfectly concise and 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?

Given 3 params and no output schema, description explains what is returned (current metrics). Adequate for straightforward retrieval. Could mention use case like 'quick neighborhood overview' but not necessary.

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 there. Tool description only lists example metrics (land price, population) but doesn't add new meaning beyond 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 it returns current metrics (land price, population, etc.) for Nagoya wards/neighborhoods. Specific verb 'returns' and resource. Differentiates from siblings by focusing on current metrics for Nagoya, but no explicit comparison.

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 'drill_down_local_analysis' or 'generate_area_report'. No explicit when-not-to-use or 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 indicate readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety. However, it adds minimal behavioral context beyond stating it returns a timeline; it does not disclose data freshness, pagination, or error handling. With annotations covering the safety profile, a score of 3 is appropriate.

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 two focused sentences (English followed by Japanese translation). It front-loads the core purpose and resource, avoiding unnecessary details. Every sentence contributes useful information, though the dual-language format adds length without new 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 the tool has 2 parameters and no output schema, the description covers the input scope and general return type (timeline). However, it does not describe the structure of the timeline, whether it returns discrete records or aggregated data, or any limitations. It is adequate but not fully complete for an agent to confidently interpret results.

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 the baseline is 3. The description mentions ward and chochou but adds no meaning beyond the schema's property descriptions. It does not provide examples, format constraints, or usage context that would elevate the score.

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's purpose: retrieving a future timeline of redevelopment, infrastructure, and population projections for Nagoya wards/neighborhoods from 2025-2050. It distinguishes itself from siblings like get_population_outlook by focusing on a broader timeline with multiple categories, though it could be more explicit about its unique scope.

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 siblings like get_population_outlook, simulate_aichi_future, or get_chochou_profile. It lacks explicit when/not-to-use conditions or alternatives, which is a significant gap given the large number of closely related tools.

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 non-destructive. Description adds data source (NIPSSR) and time horizon, but no other behavioral traits like limitations or special cases.

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. Front-loaded with the core purpose. Efficient and clear.

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 no output schema and simple parameters, description covers data source, years, and decline rate. Almost complete, but lacks detail on return format (e.g., structure of output).

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 both parameters. Description does not add additional parameter meaning beyond what 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?

Description states specific verb and resource: get projected population outlook to 2050 with decline rate. It includes data source and years. However, it does not distinguish from sibling tools like get_future_timeline, so not a 5.

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 vs alternatives. No explicit context for usage or 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 indicate readOnlyHint=true. The description adds value by noting optional external series require ESTAT_APP_ID and that FRED CSV needs no key, plus mentions population decline projection. 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 adequate but includes dual-language text (English and Japanese) and multiple bullet points, making it less concise than ideal. Could be streamlined.

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 of data sources, the description explains what is included but lacks details about return format, aggregation, or potential performance considerations. Without an output schema, more return structure information would be helpful.

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 coverage, baseline is 3. The description adds practical context: 'area' is a city filter, 'prefecture' defaults to 愛知県, and 'includeExternalSeries' triggers external data with specific requirements, enhancing 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 that the tool provides a one-screen macro view with specific data points (land price YoY, transaction counts, population decline) and optional e-Stat/FRED series. However, it does not clearly distinguish from siblings like 'quick_visual_summary' or 'generate_area_report' which might overlap.

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. It does not specify when not to use it or which sibling is better suited for similar tasks.

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 non-destructive nature; description adds output structure (compared to national average) but no deeper behavioral insights like data freshness or rate limits.

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 sentence in two languages, efficiently front-loading key purpose and output details with no unnecessary words.

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?

Despite no output schema, description adequately specifies return fields (total vacant, for-rent, for-sale, other, national comparison); could mention update frequency but is sufficient for a stat retrieval 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 coverage is 100%; description adds context about output but offers no additional parameter meaning beyond what the schema 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?

The description explicitly states it returns vacancy rate statistics by municipality with breakdowns and national comparison, distinguishing it from sibling tools that focus on other real estate analyses.

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 vacancy statistics but provides no guidance on when not to use or how it compares to alternatives among many sibling tools.

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. The description adds that it returns specific data fields (zone type, ratios, height limits), which is helpful but not substantially beyond the annotations. No indication of additional side effects.

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 a single, well-structured sentence with an appended Japanese translation. It is front-loaded with the key purpose and contains no unnecessary words.

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 simple lookup tool with no output schema, the description adequately lists the returned data types. It could be improved by explicitly stating the return format (e.g., 'Returns a JSON object with...'), but it is sufficient for an AI agent to understand the output.

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 each parameter having a clear description. The tool description does not add significant new meaning 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?

Description clearly states the tool looks up zoning information including zone type, coverage ratio, floor area ratio, and height limits. It is specific and distinct from sibling tools which focus on analysis, simulation, and other real estate functions.

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 implicitly states when to use (to look up zoning information), but does not explicitly mention when not to use or alternative tools. However, the purpose is clear and no ambiguity exists for a standard lookup.

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, so the description does not need to reinforce safety. It adds 'MCP Apps UI' context but does not disclose behavioral details like authentication or browser dependency.

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 brief sentences with front-loaded action. Efficient but lacks structured formatting; still earns its place.

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?

Covers main purpose and modes, but does not explain return values or side effects. With 7 parameters and no output schema details, more context would help.

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 86%, so parameters are well-documented. The description adds minimal value beyond schema, and does not explain the undecorated 'propertyType' parameter.

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 'Open visualization dashboard' and specifies the tool provides 2D map or PLATEAU 3D view via MCP Apps UI, distinguishing it from sibling analytical 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 implies usage for opening a dashboard, but lacks explicit guidance on when to use this tool versus alternatives or when not to use it.

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 and destructiveHint=false, so the description does not need to reiterate safety. It adds the return values (expected return, risk score, Sharpe ratio) which is useful but not critical. 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?

Two sentences in English and Japanese, front-loaded with the key action and constraints. Every word adds value; no fluff or repetition.

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 5 parameters and no output schema, the description is adequate but could be more complete by explaining the optimization goals (e.g., risk_adjusted, diversification) which are in the schema but not in the description. Still, the core purpose is clear.

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 80%, so most parameters are already documented. The description adds the context of 'across up to 5 areas' (matching maxItems) and the output fields, but does not elaborate on parameter details 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 the verb 'optimize', the resource 'real estate investment portfolio', constraints 'across up to 5 areas', and outputs 'expected return, risk score, Sharpe ratio'. It distinguishes from sibling tools like 'scenario_what_if' and 'analyze_renovation_yield' by focusing on portfolio-level optimization.

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 on when to use this tool versus alternatives. There are many sibling tools for real estate analysis, but the description does not mention the appropriate context or exclude other tools. The agent has to infer 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 declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds that the tool predicts demand scores and mentions '10 prefectures,' but does not elaborate on data sources, model assumptions, or limitations. Minimal additional 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 extremely concise: two short sentences (English and Japanese) with no wasted words. Key information is front-loaded.

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 has 5 parameters and no output schema, the description is brief but covers basic purpose. However, it lacks details about response format or prefecture list, which would help completeness. Adequate but not rich.

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 80%, so the schema already documents parameters. The tool description does not add extra meaning beyond '10 prefectures,' which hints at the area parameter. Baseline 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 tool predicts corporate demand scores for manufacturing, office, and retail across 10 prefectures. This specific verb+resource+scope distinguishes it from sibling tools like assess_property_risk or analyze_renovation_yield.

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 or any prerequisites. It lacks explicit context for selection among the many sibling analysis tools.

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=true, which matches the non-destructive nature of rendering a visual summary. The description adds behavioral context beyond annotations, such as including a compact markdown fallback and being optimized for ChatGPT mobile/compact views, as well as detailing output components (map, charts, recommended next actions).

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: two sentences (English and Japanese) that are front-loaded with the main purpose. It contains no wasted words and effectively communicates the tool's function and usage guideline.

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 has 5 parameters, 2 enums, no required parameters, and an output schema, the description adequately covers the main functionality and usage context. It mentions the key output components and the compact fallback. However, it could be slightly more explicit about the fallback behavior.

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 baseline is 3. The description does not add additional meaning beyond what the schema already provides for each parameter (area, mode, intent, compact, prefecture).

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 uses a specific verb ('Render') and clearly identifies the resource ('ChatGPT-optimized real estate visual summary'). It distinguishes this tool from siblings by noting it should be used when the user asks to show, visualize, compare, or continue in ChatGPT.

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 ('Always use this when the user asks to show, visualize, compare, or continue in ChatGPT'), providing clear context. However, it does not explicitly list when not to use it or mention alternatives.

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. The description adds value by specifying the scanning behavior across all wards and ranking output, which is not conveyed by annotations alone.

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 concise with two sentences plus Japanese translation. While efficient, the Japanese version is redundant and could be omitted for brevity. Front-loads key purpose.

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?

No output schema exists, and the description does not clarify the exact output format (e.g., list of neighborhoods, yield scores, or other metrics). For a ranking tool, this omission leaves some 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 75% (3 of 4 parameters described). The description does not add any parameter details beyond what the schema provides, so baseline 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 explicitly states the tool scans all 16 Nagoya wards to rank neighborhoods by renovation yield, using specific verb 'scan' and resource 'wards'. It clearly distinguishes from siblings like 'analyze_renovation_yield' which likely focuses on a single target.

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 such as 'analyze_renovation_yield' for a specific area. The description implies its use for ranking, but does not provide when-not-to-use or context for decision-making.

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, so no destructive behavior. The description adds value by detailing the output structure (5-axis scores, decision, red flags, etc.), but it does not mention potential limitations like data dependencies.

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 and then expands with details. It mirrors English and Japanese versions, which adds length but remains efficient. No unnecessary sentences.

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 (25 parameters, nested object, output schema exists), the description covers inputs and outputs well. It mentions the evaluation axes and return items, sufficient for agent understanding, though output schema specifics are omitted.

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 rich parameter descriptions (e.g., city examples, district guidance). The tool description does not add parameter-level detail beyond the schema, which is acceptable at the baseline of 3.

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: a real estate purchase review for executives. It specifies the evaluation axes (asking price vs benchmarks, yield, risk, future potential, contract terms) and outputs (5-axis scores, decision, red flags, etc.), which distinguishes it from sibling tools like assess_property_risk that focus on specific aspects.

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 comprehensive purchase decisions but does not explicitly state when to use this tool versus alternatives like composite_value_score or assess_contract_risk. However, the sibling context and detailed output listing provide reasonable 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 declare readOnlyHint=true and destructiveHint=false, which align with 'simulate' (non-destructive). The description adds context about the geographic scope (10 prefectures) but does not disclose behavioral traits like response format, pagination, or rate limits. With annotations covering the core safety profile, the description provides moderate additional context.

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, bilingual (English and Japanese), and communicates the core purpose efficiently without extraneous information. Every word adds 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?

The tool has 6 parameters (2 required) and no output schema. The description provides the high-level purpose and geographic scope but lacks details about the return format, how the simulation works, or how to interpret results. Given the complexity and sibling tools like 'simulate_aichi_future', more context would help differentiate and guide proper use.

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 67% (4 of 6 parameters have descriptions). The description references 'new stations, commercial facilities, population changes' which map to scenario enum values, but adds no meaning beyond the schema. The city and prefecture parameters are not elaborated. Baseline 3 is appropriate given moderate 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: simulate impact of new stations, commercial facilities, and population changes on land prices and investment scores. It specifies the scope ('10 prefectures') and uses a specific verb ('simulate'). Among 32 sibling tools, this is unique in offering what-if scenario analysis, distinguishing it from prediction or analysis 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 implies usage for simulating certain scenarios but provides no explicit guidance on when to use this tool versus alternatives like 'simulate_aichi_future' or 'forecast_land_price_trend'. No when-not-to-use or prerequisite conditions 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 declare readOnlyHint=true and destructiveHint=false. Description adds 'ChatGPT-compatible' context and scope, which is useful but not extensive. 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?

Two sentences, front-loaded with English then Japanese. Concise but slightly repetitive. Would benefit from consolidation.

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?

Describes purpose and result type (list of candidates in Japanese). Lacks detail on output format or structure, which is more important given no 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 already covers the query parameter with examples (in Japanese). Main description adds English summary but no new semantics. With 100% schema coverage, baseline 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?

Description clearly states verb 'search' and resource 'real estate data catalog' with specific result types (areas, tools, data sources). However, it does not distinguish from sibling 'search_area_candidates' which may cause 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?

No explicit guidance on when to use vs. alternatives. The phrase 'ChatGPT-compatible' implies natural language queries, but no when-not-to-use or prerequisites are 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 safety profile is clear. The description adds that hiragana is supported, providing a minor behavioral detail 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 very concise with two sentences (English and Japanese), no redundant information, and front-loaded with the core action.

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 simple search tool with 3 parameters and no output schema, the description is adequate. It explains the core functionality and hiragana support, though it could mention the limit and prefecture parameters briefly.

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 the schema already documents all three parameters. The description does not add meaningful parameter information beyond what the schema provides, resulting in a baseline score of 3.

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 searches municipality name candidates by partial text, with hiragana support. This verb+resource combination is specific and distinguishes it from generic sibling tools like 'search'.

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. The description does not mention when not to use it or point to any sibling tool for different purposes.

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 tool is non-destructive. The description does not add behavioral context beyond stating it is a simulator and outputs a report. With annotations, a score of 3 is appropriate.

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 (English and Japanese) that front-load the main purpose. Every sentence adds value, no redundancy, and it is appropriately 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?

No output schema, but description states output is a Markdown report. Covers key scenarios and output format. However, it could be more specific about report content or how to interpret results, but overall sufficient for a simulation 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 75% (3 of 4 parameters have descriptions). The description adds meaning by naming the specific scenarios (linear_chuo, centrair_expansion, etc.) and mentioning 'Markdown report' which relates to the includeMarkdown parameter. However, it does not compensate fully for the missing schema description.

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 as a simulator for Aichi future value, listing specific factors (Shinkansen, Centrair runway, Toyota EV, Expo legacy) and output type (Markdown report on land prices). It is specific and distinguishes it from siblings like 'simulate_landscape_impact' or 'forecast_land_price_trend'.

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 alternative simulators. Siblings include similar tools like 'scenario_what_if' and 'simulate_landscape_impact', but the description does not explain when to choose this one.

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 safety profile is clear. The description adds data source context (PLATEAU, SunCalc) but doesn't disclose other behavioral traits like performance, network usage, or output type. It adequately supplements annotations without contradicting them.

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 very short (two brief statements in two languages) with no wasted words. However, it could be slightly more informative without sacrificing 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 complexity (7 parameters, no output schema), the description is insufficient. It does not explain output format, interpretation of results, or typical use cases. For a tool with no output schema, the description should cover return 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 high (86%), so the baseline is 3. The description does not add additional meaning beyond the parameter names and schema descriptions. It neither enhances nor detracts from 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 uses a specific verb ('simulate') and resource ('landscape impact' with sunlight/shadow) and mentions data sources (PLATEAU 3D buildings, SunCalc), clearly distinguishing it from sibling tools like 'analyze_renovation_yield' or 'assess_property_risk'.

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 versus alternatives. The description only states what it does, lacking explicit context for selection or exclusion criteria.

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, so the agent knows no side effects. The description supplements by detailing the computed metrics (NOI, IRR, etc.) and the sensitivity analysis, providing behavioral context beyond the schema.

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, information-dense sentence in both languages, front-loaded with key terms. Every phrase adds value; no 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 complexity (17 params, nested objects) and the presence of an output schema, the description covers essential inputs and outputs. It lacks mention of optional parameters like city or propertyType, but the schema compensates.

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 major parameter groups (loan, rent, vacancy, etc.) but does not add detailed semantics beyond the schema's descriptions. It slightly aids grouping but no new 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 performs a leveraged 10-year real estate pro-forma, listing specific inputs (loan, rent, costs) and outputs (NOI, DSCR, IRR). It distinguishes from siblings by focusing on leveraged cashflow simulation, a narrow domain among many analysis 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?

No explicit guidance on when to use this tool versus alternatives like scenario_what_if or analyze_renovation_yield. The description only states what it does, not the conditions for choosing it.

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