[EN] List public houses whose address is incomplete (missing town name / placeholder), so they can be corrected — admin only. Fixing them lets zoning be derived from coordinates. / 住所が不完全 (町名欠落・プレースホルダ) な公開物件を一覧する。管理者のみ。直すと座標から用途地域を判定でき投入できる。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 返す最大件数 (既定200・最大2000) | |
| admin_token | Yes | 管理者トークン (必須) |
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 admin-only access and the purpose behind fixing addresses for zoning. However, it lacks details on side effects, rate limits, or data freshness, which are important for a list operation.
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, which adds length but is justified for international users. It is front-loaded with the core purpose, and each sentence adds value: what, why, and access control. 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?
For a list tool with no output schema, the description explains the purpose and condition of the data but does not mention output fields, pagination, or error conditions. It is adequate for basic usage but missing details that could help an agent handle results 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 both parameters described. The description adds no extra meaning beyond the schema, such as formatting or constraints on limit. The admin-only context is already implied by the required admin_token.
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 public houses with incomplete addresses for correction, specifying the exact condition (missing town name/placeholder) and admin-only access. It distinguishes from siblings like list_houses and update_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 implies usage when needing to find incomplete addresses for zoning correction, and notes admin-only restriction. However, it does not explicitly state when not to use or provide alternatives, leaving room for ambiguity among 27 siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Most tools have distinct purposes, but some potential overlap exists (e.g., get_site_context and get_houki_rules both provide site conditions, and set_site_context vs. upsert_zoning_rule could be confused). Overall, descriptions help disambiguate.
Tools predominantly use a verb_noun pattern (e.g., create_house, update_house, set_visibility). A few outliers like houki_check and whoami break the pattern, but naming is mostly consistent.
29 tools is heavy but covers a broad domain (house design, construction, catalog, contractors, admin). Some tools are niche (e.g., list_incomplete_addresses, set_forkable), but each serves a clear purpose. Could be streamlined.
Core operations for house lifecycle (create, read, update, check) are present. Lacks explicit delete/archive for houses (only set_visibility), and no tool to update site context directly (only set via set_site_context). Minor gaps but domain is well-covered.