bimhouse

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

In the absence of annotations, the description covers behavioral traits: immediate DB + cache update, admin-only access, bulk overwrite. It does not detail error handling or reversibility, but the main effects are clearly stated.

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 bilingual and somewhat long, but each sentence adds value, with clear structure: what, how, use case, and example format. It could be slightly trimmed, but remains 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 no output schema or annotations, the description lacks information on return values (e.g., success/error). It adequately covers input format and behavior for a bulk-set tool, but could be more complete by stating what the response 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?

The schema provides minimal definitions, but the description expands fully, listing all optional fields for the entries array and clarifying the slug parameter as an alternative. Schema coverage is high, so the description adds meaningful context beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it is for bulk-setting site conditions for houses, admin-only, with immediate effect. It distinguishes from sibling tools like set_site_context by specifying 'admin only, admin_token; no edit_token'.

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 it is for operators to backfill data like zoning/road-width, and that admin_token is required (no edit_token). This implies when to use versus the non-admin variant, though it does not explicitly list 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?

With no annotations, the description carries full burden. It discloses authentication requirements and free usage limits, but does not detail side effects, data handling, or whether the tool modifies state. For a chat tool, this is acceptable but not comprehensive.

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 mixes English and Japanese, and includes some extraneous details (e.g., URL). It is structured but could be more concise. It is not overly long, but not optimally brief.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers authentication, domain, and cost, but lacks mention of the response format or return value. Given no output schema, this is a gap. It is adequate but not fully 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 coverage is 100%, and the description repeats the parameter names and types from the schema without adding new semantic information. It does not elaborate on expected formats or constraints 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 clearly identifies the tool as an AI chat specifically about architecture, BIM, code, and MU, distinguishing it from sibling CRUD tools. The verb 'chat' and resource 'AI chat' are explicit and unique among siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context on authentication and cost (API key, free initial calls), but does not explicitly state when to use this tool versus alternatives or when not to use it. Usage is implied from the domain.

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?

Discloses geocoding, auto-naming, climate-aware upgrades, auto-element placement based on keywords, and rate limiting. With no annotations, description carries full burden and meets it well, though could detail 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?

Bilingual structure is organized and front-loaded with key actions. Some repetition between languages, but complexity justifies length.

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 many aspects: parameters, auto-generation, return values (slug, edit_token, URLs). Missing detail on output format and exact verdict structure, but still comprehensive.

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%, and description adds significant context beyond schema, e.g., address alone builds a house, keywords in rooms trigger auto-elements. This enriches 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 creates a new house (bim.json) from an address or full elements. It distinguishes from siblings like update_house and list_houses by focusing on creation behavior.

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?

Describes when to provide only address vs full elements, and mentions optional parameters like rooms for auto-placement. Lacks explicit 'when not to use' but sibling context compensates.

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?

In the absence of annotations, the description discloses key behaviors: authentication necessity, insert-only constraint, and immediate propagation to catalog and search. It does not cover rate limits or error handling on duplicate SKU, but covers major 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 and front-loaded: two sentences in English efficiently convey the core purpose and constraints, followed by Japanese translation. 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 the complexity (18 params, no output schema, no annotations), the description covers authentication, insert-only behavior, immediate reflection, and category guidance. It lacks error scenarios but is overall sufficient for the agent to use the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with detailed descriptions for all 18 parameters. The description text adds little extra meaning beyond the schema, so 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 explicitly states 'Register a new catalog product SKU' with verb+resource, and notes it is insert-only and no overwrite. This clearly distinguishes from sibling tools like update_product and retire_product.

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 mentions requirement for Bearer API key and the insert-only constraint, providing context for when to use. However, it does not explicitly compare with alternatives or state when not to use this tool, leaving room for improvement.

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?

No annotations provided, so description carries the burden. It discloses the action (remove, revert) and access restriction (admin only). However, it does not mention error behavior or idempotency.

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 concise sentences, bilingual, front-loaded with the essential action. No wasted 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 delete tool with 3 parameters and no output schema, the description covers the core purpose and access restriction. Lacks details on error conditions or return value, but is adequate.

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 does not add additional meaning to the parameters beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool removes a zoning rule override and reverts to engine defaults, distinguishing it from sibling tools like upsert_zoning_rule. Specific verb and resource.

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 only mentions 'admin only' but does not explicitly state when to use this tool versus alternatives like upsert_zoning_rule. No guidance on prerequisites or scenarios.

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?

No annotations are provided, so the description carries the burden. It describes the output (schedule, packages) but does not disclose whether the tool is read-only, destructive, or requires authentication. The description adds some context about auto-generation but lacks 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 front-loaded with English and includes Japanese for completeness. It is reasonably concise but could be shortened by removing the redundant bilingual repetition of the same information. Overall, it is well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has one parameter, no output schema, and no annotations, the description provides a detailed account of the output structure. However, it lacks usage context, such as prerequisites or when to call this tool instead of similar ones. It is mostly complete but could be improved.

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% coverage for the single parameter 'slug', but its description is minimal ('物件 slug'). The tool description does not add meaning beyond the schema, though it explains the output in detail. 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 clearly states that the tool returns a construction plan for a house, specifying components like schedule (Gantt) and per-trade order packages. This distinguishes it from other tools in the sibling list, which focus on houses, products, contractors, 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 its use for retrieving a construction plan but does not provide explicit guidance on when to use this tool versus alternatives, such as get_house_bim or list_houses. No exclusions or context are given.

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

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

No annotations are provided, so the description carries the full burden. It describes the output (law refs, overrides, optional site conditions/verdict) but does not mention any behavioral aspects such as authentication requirements, rate limits, or whether it is read-only. The description is straightforward but lacks 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 concise, consisting of two sentences (one English, one Japanese). It is front-loaded with the English version. However, the bilingual duplication slightly reduces conciseness for an English-speaking 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's simplicity (one optional parameter) and no output schema, the description adequately covers the return values: lists of law refs, zoning overrides, and optionally site conditions with verdict. It is sufficient for the agent to understand the tool's functionality.

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% coverage with a single optional parameter 'slug'. The description adds value by explaining that passing a slug includes additional site conditions and a verdict, which goes beyond the schema's minimal 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 that the tool lists building-code checks and zoning-rule overrides, and optionally returns site conditions and verdict for a specific house when a slug is provided. Both English and Japanese versions are provided, leaving no ambiguity about the tool's 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 explains what the tool does, but does not explicitly state when to use it over alternatives like 'houki_check' or 'get_site_context'. The usage is implied but not clearly differentiated from siblings.

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

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

The description indicates a read operation ('Fetch'), but without annotations, it does not explicitly confirm safety, idempotence, or side effects. It mentions the include_elements parameter effect but lacks broader behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with English but repeats the same information in Japanese, making it less concise than a single-language version. It could be streamlined without the bilingual 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 simple read tool with two parameters and no output schema, the description covers the purpose and parameter semantics adequately. It could mention the return format briefly but is mostly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds value beyond the schema by explaining that include_elements=false returns only meta, clarifying the default behavior. With 100% schema coverage, this extra context earns a higher 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 states the tool fetches a house's full bim.json v1 by slug, specifying the resource (house) and action (fetch). It distinguishes itself from sibling tools like get_product or get_build_plan by focusing on bim.json data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for fetching bim data but does not explicitly state when to use this tool versus alternatives or when not to use it. No 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?

No annotations are provided, so the description carries the full burden for behavioral disclosure. It describes the tool as a read operation ('get') that returns product details. However, it lacks explicit statements about side effects (e.g., read-only), authentication needs, or error behavior. The description is adequate but could be enhanced.

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 consists of two brief sentences (bilingual), each serving a clear purpose: stating the action and listing returned fields. There is no unnecessary text, making it easily scannable for an AI 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 simplicity of the tool (one parameter, no output schema, no annotations), the description is relatively complete: it explains the input (SKU) and output fields. However, it does not mention error conditions (e.g., non-existent SKU) or response structure. Still, for a straightforward get-by-key tool, it suffices.

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% for the single parameter 'sku', which is described as '製品 SKU' (product SKU). The description adds context by stating 'by SKU' and listing returned fields, but the parameter meaning is fully covered by the schema. Baseline score of 3 is appropriate because the description adds marginal value 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 explicitly states the tool's purpose: to get a single product's full detail by SKU, listing the fields returned (price, U-value/η, stock, JAN, successor). This clearly distinguishes it from sibling tools like 'search_catalog' (which lists products) or 'update_product' (which modifies).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when needing full details of one product by SKU but does not provide explicit guidance on when not to use it or mention alternatives. For example, it doesn't state that this tool is for retrieval purposes only, distinguishing it from search or update 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?

No annotations are provided, so the description carries the full burden. It discloses the return contents but does not explicitly state read-only behavior, authorization needs, or side effects. For a simple getter, this is adequate but not fully transparent.

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 (one English, one Japanese) with no fluff. It is front-loaded with the key action and lists return fields efficiently.

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 simplicity (one required parameter, getter, no output schema), the description is mostly complete: it specifies the input, output fields, and relation to houki_check. It could mention existence checks or error responses, but this is a minor gap.

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 a description for the 'slug' parameter. The description does not add additional meaning beyond the schema for the parameter itself, but it explains what the tool returns. Baseline is 3 due to high schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb ('get') and the resource ('effective site conditions used by houki_check'), and lists the specific fields. It distinguishes itself from the sibling 'set_site_context' by being the getter counterpart.

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 to retrieve site conditions for a house, but lacks explicit guidance on when to use this tool versus alternatives like 'set_site_context'. No exclusions 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?

No annotations provided, so the description must fully disclose behavior. It only states the action and output, omitting whether the tool modifies data, requires authentication, or has 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?

Single sentence covering both English and Japanese is concise and front-loaded with the key action and checks performed.

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, the description could elaborate on return format or error conditions. As is, it provides basic functional info but lacks completeness for a check 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?

Only one parameter (slug) with schema description '物件 slug'. Schema coverage is 100%, so the description adds no new semantics. 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 it runs a Japanese Building Standards Act check covering specific areas (coverage, FAR, slopes, daylight, ventilation) and returns pass/fail. This distinguishes it from siblings like get_houki_rules.

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 get_houki_rules or get_build_plan. No context about prerequisites or conditions.

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

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

No annotations are present, so the description must cover behavioral traits. It only states the basic function without disclosing aspects like pagination, ordering, permissions, or side effects. For a simple read tool, more detail is warranted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise, with no superfluous information. It is front-loaded with the purpose and uses a bilingual format efficiently.

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 simplicity of the tool (2 optional params, no output schema), the description covers the basic function but lacks details about result ordering, pagination, or return format. It is adequate but not fully 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 parameters are documented in the schema. The description adds no extra meaning beyond what the schema already provides for 'trade' and 'prefecture'. 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 it lists registered contractors with optional filtering by prefecture/trade. It uses a specific verb and resource, and although it doesn't explicitly differentiate from sibling tools like 'match_contractors', the action is distinct enough.

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 'match_contractors' or 'register_contractor'. The description only mentions optional filters without any context for 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?

No annotations provided, so the description carries full burden. It describes the set of houses included (curated public) and that user houses are excluded by default. It also mentions the returned fields. It does not mention authentication or rate limits, but as a read-only list, these are less 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?

The description is bilingual and concise, conveying all necessary information in two sentences. It front-loads the main purpose and includes brief notes on behavior. While slightly longer due to dual language, it remains 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 simplicity (1 optional parameter, no output schema, no annotations), the description is complete. It specifies what the tool returns and what it excludes by default. No additional information is needed for correct agent usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers 100% of parameters with a description. The tool description adds context about user houses (u-* prefix) and default behavior, slightly augmenting the schema definition. This adds value by explaining when and why to use the 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?

Description clearly states that the tool lists curated public houses (famous buildings, landmarks) and optionally includes user houses. It distinguishes from sibling tools like get_house_bim or update_house by focusing on listing. It also specifies the return fields (slug, scale, element count, bim.json sufficiency rate).

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 explains when to set include_user=true and notes that user houses are excluded by default but accessible via direct link. This provides guidance on typical usage. However, it does not explicitly state when to avoid this tool in favor of alternatives, though the context is sufficient for a listing tool.

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?

With no annotations, the description carries the full burden. It discloses the admin requirement and the condition of incomplete addresses, but omits details like pagination, sorting, or error behavior. The read-only nature is implied but not confirmed.

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, efficient sentence (with bilingual repetition) that conveys purpose, condition, and usage restriction without unnecessary words. All content is relevant and 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 simplicity of the tool (2 params, no output schema), the description is largely complete: it explains the purpose, admin requirement, and the incompleteness condition. It could be improved by briefly differentiating from list_houses, but overall it serves well.

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% for both parameters (limit and admin_token). The description adds no additional meaning beyond what the schema provides, so a baseline 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 verb (list), the resource (public houses with incomplete addresses), and the scope (admin only, for correction to enable zoning derivation). It clearly distinguishes from sibling tools like list_houses.

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 indicates admin-only usage and the purpose for fixing addresses, but does not explicitly state when to use this tool versus alternatives (e.g., list_houses) or when not to use it. Usage context is implied but not fully articulated.

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?

No annotations are provided, so the description carries full burden. It discloses the auth requirement and that it lists registered products, but lacks details on pagination, ordering, response format, or error behavior. For a read-only list, this is adequate but minimal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is extremely concise with two sentences (English and Japanese). Every word adds value, no redundancy, and critical info (auth + resource) 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 no parameters and no output schema, the description is minimal. It covers purpose and auth but omits error handling, response structure, and rate limits. For a simple tool, it's acceptable but could be more 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?

Input schema has zero parameters, so baseline is 4. The description does not add parameter info because none exist. Schema coverage is trivially 100%, meeting expectations.

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 lists products registered by the user, distinguishing it from sibling tools like list_houses (different resource) and create_product (different action). The bilingual format ensures clarity across languages.

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 specifies the need for a Bearer API key, indicating authentication context. However, it does not explicitly guide the agent on when to use this tool over alternatives like list_contractors or list_houses, though the resource type is clear.

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

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

With no annotations, the description carries full burden. It discloses matching criteria and order splitting behavior but does not mention if the tool has side effects, requires authentication, or any rate limits. The lack of annotation contradiction is neutral.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and front-loaded with English, containing two clear sentences plus a Japanese duplicate. No unnecessary content, but could be slightly leaner without the Japanese if not needed.

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 is provided, and the description fails to explain what the tool returns (e.g., list of contractors with scores). Additionally, the location input is ambiguous given the schema does not include location parameters, leaving a significant gap.

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% for the two parameters (slug, trade), but the description introduces location parameters (prefecture, lat/lng+radius) that are not present in the schema, causing confusion and reducing the added value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool matches contractors to a house based on trade and location, with an explicit verb and resource. It distinguishes from sibling tools like list_contractors by specifying the matching criteria and the natural splitting of orders across local builders.

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 indicates when to use the tool (matching contractors for a house by trade/location) and mentions that omitting trade matches all trades. However, it lacks explicit comparisons to alternatives or when not to use it, such as vs. list_contractors.

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?

With no annotations, the description fully carries the behavioral disclosure burden. It discloses that the tool uses BIM takeoff and catalog prices, and returns specific outputs including lead times and critical path. However, it does not explicitly state whether the tool is read-only or if it modifies state, which is a minor gap.

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, dense sentence that efficiently conveys purpose, inputs, and outputs. It is front-loaded with the key phrase 'Catalog-priced cost estimate' and includes both English and Japanese for clarity.

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 simple input schema and lack of output schema, the description covers the tool's purpose and outputs well. It implies prerequisites (BIM takeoff) but does not explicitly state them or address error conditions. Still, it is fairly complete for a tool with one parameter.

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 one parameter 'slug' described as '物件 slug'. The description adds no new semantic information beyond this, so it meets the baseline of 3 but does not exceed it.

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 is a catalog-priced cost estimate generating BOM, total, unit price, lead times, and critical path from BIM takeoff. It distinguishes itself from siblings like search_catalog and get_build_plan by its specific focus on cost estimation with catalog integration.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when to use the tool (when a catalog-priced cost estimate from BIM takeoff is needed) but does not explicitly state when not to use it or list alternatives. The sibling tools imply there are other search and build functions, but no direct distinctions are made.

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?

With no annotations, the description carries the full burden. It discloses that the tool creates a live reference (not a copy), requires edit_token, and that the viewer resolves the reference at view time for live stock. It does not discuss error handling or idempotency, but the provided information is sufficient for an agent to understand the core behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is bilingual and relatively concise for the complexity of the tool. It front-loads the purpose and uses bullet-like structure for sources. Could be slightly more streamlined but is well-organized.

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 (two sources, live reference concept) and the absence of an output schema, the description provides a solid understanding of what the tool does and how parameters work. It does not explain the return value, but the core behavior is well captured.

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, and the description adds significant context: it explains the two source types ('mu' and 'device') and their corresponding ref formats, as well as the optional room parameter. This goes beyond the schema descriptions and helps the agent understand parameter values.

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 places a live reference (not a copy) from another service into a house, distinguishing it from sibling tools like create_house or update_house which manage houses directly. The verb 'place' and resource 'live reference' are specific.

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 explains when to use the tool (to place a live reference) and notes the required edit_token. It does not explicitly state when not to use it or list alternatives, but the context of 'live reference' vs. 'copy' implies when other tools might be more appropriate.

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?

With no annotations, the description carries the full burden. It discloses that the order is a draft, does not send, and includes spec/inspection lists. This covers key behavioral traits beyond basic creation.

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 in English and one in Japanese. It front-loads the most critical information (draft, no send) and wastes no 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 no annotations and no output schema, the description covers the input purpose, behavior, and what is included. It is fairly complete for a draft creation tool, though it could mention post-creation steps.

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%, baseline 3. The description adds value by explaining that slug is for a house, trade comes from get_build_plan, and contractor_id from match_contractors/list_contractors, providing context beyond the schema descriptions.

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 creates a DRAFT purchase order for one trade of a house to a contractor. It uses specific verbs and resources, and the scope is well-defined. The warning that it does not send anything differentiates it from potential sending 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 explicitly says it creates a draft and does not send, which implies when to use. However, it does not mention alternatives or when not to use, but the context is clear enough.

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?

No annotations are present, so the description must disclose all behavioral traits. It only mentions the authentication requirement. It omits what happens on success/failure, whether the operation is idempotent, or any side effects. The 'self-serve' hint is present but insufficient.

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 (with Japanese translation) that front-load the purpose and authentication, then succinctly explain key parameter categories. No redundant or unnecessary 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 9 parameters, no output schema, and no annotations, the description is adequate but not complete. It covers purpose, auth, and parameter summaries, but lacks details on return values (e.g., created contractor ID), error scenarios, or constraints like uniqueness.

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%, providing baseline value. The description adds meaning by grouping parameters (trades, location) and clarifying acceptable values ('trade codes or 'all', 'prefectures and/or lat/lng+service_radius_km'). This enhances understanding beyond the schema's individual Japanese descriptions.

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 'Register a contractor' with a specific verb and resource. It distinguishes from siblings like list_contractors (read) and match_contractors (search) by focusing on creation. Scope (supply side, self-serve) adds clarity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description mentions 'Requires Bearer API key' as authentication guidance. It implies when to use this tool (to register a contractor) versus alternatives by context, but does not explicitly state when not to use or provide alternative tool names.

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

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

With no annotations, the description fully discloses behavioral traits: the tool performs a soft delete, requires authentication, and has restrictions on which products can be retired. 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 concise, with two clear sentences (English and Japanese) plus a note on authorization. It is front-loaded with key information. Slightly verbose due to bilingual text but still 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 simplicity (one param, no output schema), the description covers purpose, prerequisites, and constraints adequately. It lacks return value info but that is acceptable without 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 coverage is 100% (single 'sku' parameter described). The description adds no further parameter detail beyond 'required SKU', so 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's purpose: 'Retire (discontinue) a product you created'. It specifies it's a soft delete (not hard), and distinguishes from siblings like create_product or update_product by focusing on discontinuation.

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 explicit usage guidance: requires Bearer API key, only for own products (not others or official SKUs), and clarifies it's a soft delete. This helps the agent decide when to use this tool versus 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly describes a read-only search operation without any destructive or safety concerns. While it doesn't explicitly state non-destructiveness, the term 'search' makes it clear enough for typical use.

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 and Japanese) that front-load the key purpose and search capabilities. Every word serves a purpose, and there is 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 lack of an output schema, the description could have mentioned what fields are returned or the structure of results. It only states that it searches the catalog, missing details like response format or pagination. The catalog size provides some context, but overall completeness is average.

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 Japanese descriptions for each parameter. The tool description adds only a brief summary ('by keyword/brand/category') and mentions the catalog size. This does not significantly enhance understanding beyond what the schema already provides, so 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 searches a building-materials catalog with 3,900+ SKUs by keyword, brand, or category. It uses a specific verb and resource, and distinguishes itself from sibling tools like get_product (single product) and create_product (creation).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for searching the catalog but does not explicitly state when to use this tool over alternatives. No exclusions or when-not-to-use guidance is provided, leaving the agent to infer context from the sibling list.

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?

With no annotations, the description carries the full burden. It discloses the main behavior (toggle forkability), the required authorization (edit_token), and the default state (all allowed). It does not mention error conditions or reversibility but is sufficient for a simple boolean toggle.

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?

Very concise, bilingual, front-loaded. Every sentence serves a purpose with no wasted 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 the simplicity of the tool (single boolean toggle) and no output schema, the description covers the essential aspects. Minor gaps like error handling but overall complete enough for an AI agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description reinforces parameter meanings (e.g., forkable=false forbids copying) but adds little beyond the schema's own descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states the tool's purpose: allowing or forbidding others from forking (copying) a house. The verb 'Allow or forbid' is specific, and the resource 'house' is identified.

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?

Mentions prerequisite 'needs edit_token' and default behavior ('forkable=false で他者のコピー作成を禁止 (既定は全て可)'), giving some usage context. However, no explicit guidance on when to use this tool vs alternatives like set_visibility or update_house.

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?

No annotations are provided, so the description carries the full burden. It discloses that an edit_token is required, updates are partial, and the result is a re-run verdict. However, it does not discuss whether changes are reversible, rate limits, or other side effects. For a mutation tool, this is adequate but not exhaustive.

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: two sentences in English encapsulating purpose, behavior, and example, followed by a Japanese translation. No wasted words, and the key action is front-loaded. Every sentence 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?

Given 12 parameters and no output schema, the description provides sufficient context: it explains the purpose, the edit_token requirement, partial update behavior, and a motivating example. It could mention the return format explicitly, but overall it is complete for a complex 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 parameters are well-documented in the schema. The tool description adds minimal extra semantics, like noting that shadow_regulation auto-determines if omitted. The road_width_m example is helpful but basic. 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 overrides site conditions for houki_check and returns a new verdict. It uses specific verbs ('Override', 'returns') and resource ('house's site conditions'), distinguishing it from sibling tools like 'houki_check' or 'get_site_context'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explains that only provided fields are updated and gives an example use case: fixing false NGs from defaults (e.g., road width). It does not explicitly mention when not to use the tool or alternatives like admin_set_site_context, but the context is clear enough for typical AI reasoning.

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?

With no annotations, the description carries the full burden of behavioral disclosure. It explains that setting private=true hides the house from the listing but preserves the direct link. It also notes the dependency on edit_token from create_house. This is transparent for a simple toggle, though it could mention reversibility or idempotency.

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, using a single English sentence for the core purpose and additional Japanese sentences for context. Every sentence is informative and non-redundant. It is well-structured with the essential information 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's simplicity (3 required params, no output schema, no nested objects), the description is complete. It covers the action, required parameters and their origins, the effect on listing, and a practical use case. An agent has sufficient information to invoke the tool correctly.

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 adds value by explaining the source of edit_token (from create_house) and the effect of the private parameter (hides from list but direct link remains). This provides meaningful context beyond the schema descriptions.

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: 'Toggle a house's public listing on/off'. It specifies the resource ('house's public listing') and uses a specific verb ('toggle'). The mention of requiring 'edit_token' from create_house distinguishes it from other tools like update_house, as it is specific to houses created via create_house.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides context on when to use this tool: when you have an edit_token from create_house. It also gives a concrete use case: 'evolution loop low-score property elimination'. However, it does not explicitly mention when not to use it or list alternative tools, but the context is sufficient for an agent to infer appropriate usage.

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

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

With no annotations, the description carries the full burden. It discloses return value (houki verdict), versioning, and token requirement, but lacks details on error handling, idempotency, or authentication scope.

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 portion is concise and front-loaded with the main purpose. The inclusion of a Japanese translation adds minor redundancy, but overall structure is good.

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?

Without an output schema, the description explains the return value and versioning. It also outlines a practical workflow. Missing details on error conditions or validation, but covers key aspects for usage.

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%, but the description adds context: explains elements as full replacement, project for meta patching (with examples), and note as change memo. It also clarifies elements_json for strict-schema clients.

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 updates an existing house's bim.json, specifying it requires an edit_token and can either swap elements or patch project metadata. It distinguishes from siblings like create_house and get_house_bim.

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 a clear workflow (get_house_bim -> edit -> update_house -> check houki) and indicates the prerequisite of an edit_token. It does not explicitly mention when not to use it, but the context is sufficient for appropriate 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?

With no annotations provided, the description carries the full burden. It discloses authorization requirements (Bearer token), ownership constraint (your SKUs only), and partial update behavior ('only specified fields overwrite'). It could additionally mention idempotency or error handling, but the essential behavioral traits are communicated.

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 short sentences in English plus a Japanese translation. Key information (scope, auth, partial update) is front-loaded without extraneous text.

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 17 parameters, no output schema, and no annotations, the description covers critical context (auth, ownership, partial update). It omits return value details, but this is acceptable without an output schema. Minor gaps like rate limits or error scenarios could be added, but overall it is adequate.

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 low (18%), but the description adds meaningful context: updates are limited to self-registered products and only overwrite the specified fields (partial update). This adds value beyond the schema, though it does not detail each parameter's 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 it updates fields of a product the user created, differentiating from create_product (creation) and retire_product (deletion). It specifies the scope 'your SKUs only', leaving no ambiguity about what the tool does.

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 requires a Bearer API key and indicates the tool is for updating only self-registered products. It implies when not to use (others' SKUs) but does not explicitly list alternatives; however, sibling tools (create_product, retire_product) provide clear context for when to use each.

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?

With no annotations, the description fully discloses that the tool is admin-only, performs upsert (add/update), and retroactively applies to all matching houses. This transparently communicates important side effects for a mutation tool.

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 with key information front-loaded in English. The bilingual inclusion is justified for a Japanese audience, though it adds length. No wasted 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?

While the description covers behavior and parameters, it omits return values or error conditions (e.g., invalid token). For a complex mutation with 11 parameters and no output schema, this information 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?

All 11 parameters have schema descriptions (100% coverage), so baseline is 3. The description adds extra context for complex parameters like 'road_slope_d' with example '1.25=4' and 'profile' default 'Japan', improving understanding 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 'Add/update a zoning regulation rule' with specific constraints like 'admin only (admin_token)' and effect 'applies to all houses matching (profile, zoning)'. This distinguishes it from sibling tool 'delete_zoning_rule' and other admin 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 specifies admin-only access and that the rule applies to houses matching profile and zoning, giving clear context for when to use. However, it does not explicitly mention when not to use or provide alternatives like delete_zoning_rule for removal.

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?

With no annotations, the description carries the burden. It discloses the requirement for a Bearer token and the return of the account email. It also mentions it works from Web/CLI. However, it does not explicitly state idempotency or lack of 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 concise with two language versions. It is front-loaded with the English summary. Could be slightly more structured but is very short and to the point.

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, the description fully explains the return value (account email). With zero parameters and no similar sibling tools, the description provides complete context for an agent to select and use this tool correctly.

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?

There are no parameters, so the baseline is 4. The description adds context by explaining the authentication mechanism (Bearer token) and that no input parameters are needed.

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 verifies API-key authentication and returns the account email, which is distinct from all sibling tools (houses, products, orders, etc.). The verb 'verify' and resource 'API-key auth' are specific.

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 checking authentication but does not explicitly state when to use vs alternatives. No exclusions or when-not-to-use guidance are provided.

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