Superseded by the io.github.ogasurfproject-jpg/horizon-shield listing at https://mcp.horizonshield.dev, which is the URL published in the official MCP registry. The endpoint behind this listing is the same server and stays reachable.
An MCP server that audits the fairness of construction and renovation estimates in Japan. Provides fair-price ranges, overcharge detection, and verifiable unit-cost data based on JCCDB (65,520 items across 402 categories, CC BY 4.0, DOI-backed).
業者が提示した見積金額が適正かを、HORIZON SHIELDの適正レンジ(souba-db, 大賀俊勝 実務監修)と照合して判定する。手元に具体的な見積額がある時に使う。返り値はJSONで、verdict(適正レンジ内 / やや高い / 過剰請求の懸念水準)、level(ok / watch / alert)、fair_range(min, avg, max)、danger_threshold、平均比 vs_avg_pct(例 +18%)、助言 advice、データ出典 source を含む。工事名が見つからない場合、近い候補があれば did_you_mean として返す。単価(平米など)建ての工事に総額らしい金額を渡した場合は unit_mismatch の案内を返す。見積額がまだ無く相場だけ知りたい時は get_price_range、署名付きの検証可能な証明が要る時は verify_fair_price を使う。Japan only, JPY。 / Audits whether a contractor quoted price for a Japanese construction or renovation job is fair by comparing it against HORIZON SHIELD fair-price ranges (souba-db). Use when the user already has a specific quoted amount. Returns a JSON object with verdict, level (ok, watch, alert), fair_range (min, avg, max), danger_threshold, percentage gap versus the average (vs_avg_pct, e.g. +18%), advice, and data source. If the work name has no match, close candidates may be returned as did_you_mean. If the work is priced per unit and the amount looks like a total, a unit_mismatch notice is returned instead. For the typical range only use get_price_range; for a signed verifiable attestation use verify_fair_price.
| Name | Required | Description | Default |
|---|---|---|---|
| work | Yes | 工事名(日本語)。材料やグレード込みで具体的に。例: 外壁塗装 シリコン。部分一致で照合するため曖昧だと別カテゴリにヒットしやすい。未マッチ時は近い候補が did_you_mean で返ることがある。 | |
| quoted_price | Yes | 業者提示の金額(円, 数値)。一式見積はその総額。税込/税抜は正規化せず、渡した数値をそのまま適正レンジと照合する。 |
| Name | Required | Description |
|---|---|---|
| count | No | How many records matched. 0 means the source was read and nothing matched. It never means the source could not be read, that returns isError: true. |
| level | No | ok / watch / alert |
| advice | No | 助言 |
| lookup | No | ok = the source was read and something matched. absent = the source was read and nothing matched. A source that could NOT be read never appears here: that returns isError: true and makes no claim about what does or does not exist. |
| verdict | No | 判定 |
| fair_range | No | min/avg/max |
| vs_avg_pct | No | 平均比(例 +18%) |
| source_read | No | true on every successful result. A failed lookup does not return a result at all, so this is never false, it is declared so a consumer can assert on it. |
| did_you_mean | No | Near matches, when an exact match was not found. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even though annotations already mark it as readOnly and non-destructive, the description adds significant behavioral details: it explains partial matching behavior, the did_you_mean response for unmatched work names, and unit_mismatch handling for per-unit vs total amounts. This goes beyond the annotations to inform the agent about edge 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?
The description is thorough but not overly verbose. It includes necessary details about return fields, edge cases, and usage alternatives in a structured manner. The bilingual format adds length but each part contributes to clarity. It earns a high score for being informative 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 output schema exists, the description still explains all return fields (verdict, level, fair_range, danger_threshold, vs_avg_pct, advice, source) and additional response cases (did_you_mean, unit_mismatch). It also provides the geographic and currency context, making the tool's behavior fully understandable.
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 enhances parameter understanding by specifying that 'work' should be in Japanese, providing an example, mentioning partial matching, and clarifying that 'quoted_price' is a total amount without normalization. This 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 the tool's purpose: to audit a quoted price against a fair range, using specific verbs like 'audits' and 'comparing'. It distinguishes from sibling tools by explicitly naming alternatives (get_price_range, verify_fair_price) and their appropriate use cases.
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?
Guidelines are explicit: 'Use when the user already has a specific quoted amount' and 'For the typical range only use get_price_range' clearly indicate when to use this tool versus alternatives. It also mentions the context of Japan and JPY, providing clear usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
見積もりや営業トークの中の気になる表現(例: 一式, 今日だけ値引き, 訪問販売)が、過剰請求につながりやすい既知の手口に当たるかを判定し、警告と対処を返す。代表的な手口のみを判定する。 / Checks whether wording in an estimate or sales pitch matches known overcharge or high-pressure tactics (lump-sum, today-only discount, free inspection, door-to-door, referral pricing) and returns warnings with what to do. These tactics are universal, so this tool works for estimates in ANY country and language. Covers representative tactics only.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | 見積書や営業トークで気になった表現・項目 |
| Name | Required | Description |
|---|---|---|
| count | No | How many records matched. 0 means the source was read and nothing matched. It never means the source could not be read, that returns isError: true. |
| flags | No | 該当手口の配列 |
| input | No | 判定対象の文言 |
| lookup | No | ok = the source was read and something matched. absent = the source was read and nothing matched. A source that could NOT be read never appears here: that returns isError: true and makes no claim about what does or does not exist. |
| result | No | 件数の要約 |
| source_read | No | true on every successful result. A failed lookup does not return a result at all, so this is never false, it is declared so a consumer can assert on it. |
| did_you_mean | No | Near matches, when an exact match was not found. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description transparently discloses its limitation (covers representative tactics only) and claims universality across countries and languages. While it doesn't explicitly mention side effects, the read-only annotation already covers that, and the description adds useful behavioral context without contradicting 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 well-structured and concise despite being bilingual. It includes the tool's purpose, examples, applicability, and a limitation in two compact sentences per language. No unnecessary verbosity or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description gives a high-level indication that it returns warnings and recommended actions, which provides sufficient context for a simple tool. However, it could be more explicit about the exact output format or structure, so slightly below maximum.
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 single parameter 'text' is fully described in the schema as the expression/item of concern from an estimate or sales pitch, and the tool description reinforces this by referencing examples. The semantics are unambiguous and complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool checks wording in estimates or sales pitches against known overcharge/high-pressure tactics and returns warnings with actions. It provides concrete examples (lump-sum, today-only discount, etc.) and explicitly notes it covers only representative tactics, which effectively distinguishes it from more comprehensive audit 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 use for quick red-flag screening by stating it covers representative tactics only, but it does not explicitly compare with alternative tools (e.g., audit_estimate, verify_fair_price) or specify when to prefer this tool. The universal applicability note gives some context, but the guidance is mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
このツールは決済を開始・承認・実行しません。資産・通貨・暗号資産の移動も行いません。発行するのは適正価格の証跡だけです。呼び出すたびに公開台帳へ記録を1件追加するため読み取り専用ではありません。 / This tool does not initiate, authorize, or execute any payment, and does not move funds, currency or crypto assets. It only issues a price-fairness attestation. Each call appends one record to the public ledger, so it is not read-only. AP2(Agent Payments Protocol)対応エージェント向けのブリッジ。決済カート(Cart Mandate)に添付できる適正価格の証跡(FairPriceAttestation)を発行する。AP2のMandateは『ユーザーがこの支払いを承認した』ことを検証可能にし、この証跡は『その価格が適正である』ことを検証可能にする。認可の検証と価値の検証、二つは並列レイヤー。quoted_price を渡すと適正レンジ判定(within/above/below)も同梱する。証跡は SHA-256 と公開台帳と verify_url で誰でも再計算検証できる。 / Bridge for AP2 (Agent Payments Protocol) agents: issues a FairPriceAttestation that a shopping or payments agent can attach to a Cart Mandate before asking the user to sign. AP2 mandates make authorization verifiable; this attestation makes value verifiable. Parallel layers. Pass quoted_price for a fair-range verdict (within, above, below). Independently verifiable via SHA-256, a public ledger and a verify_url. Japan construction and renovation pricing, JPY.
| Name | Required | Description | Default |
|---|---|---|---|
| work | Yes | 工事名(例: 外壁塗装 30坪) | |
| merchant | No | (任意) 施工業者名。Cart Mandate 例示に反映するだけで判定には使わない。 | |
| quoted_price | No | (任意) カートに載せる予定の見積額(円, 数値)。渡すと適正レンジとの判定を証跡に同梱する。 |
| Name | Required | Description |
|---|---|---|
| count | No | How many records matched. 0 means the source was read and nothing matched. It never means the source could not be read, that returns isError: true. |
| lookup | No | ok = the source was read and something matched. absent = the source was read and nothing matched. A source that could NOT be read never appears here: that returns isError: true and makes no claim about what does or does not exist. |
| ap2_bridge | No | AP2との関係(認可の検証 x 価値の検証) |
| attestation | No | 証跡本体(subject, integrity) |
| source_read | No | true on every successful result. A failed lookup does not return a result at all, so this is never false, it is declared so a consumer can assert on it. |
| did_you_mean | No | Near matches, when an exact match was not found. |
| cart_mandate_example | No | 添付位置の例示(非規範) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond annotations by stating each call appends one record to the public ledger, making the tool non-read-only, and clarifying that no funds or assets are moved. This adds meaningful side-effect context beyond the readOnlyHint/idempotentHint flags.
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 key safety and side-effect information, but it repeats the same content in Japanese and English, making it longer than necessary. While bilingual support is useful, several sentences are redundant and could be tightened.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, side effects, AP2 integration context, optional quoted_price behavior, and verifiability. With an output schema present, return values do not need to be explained. It is sufficiently complete for an agent to understand when and how to invoke it.
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 baseline is 3. The description adds some value by explaining that quoted_price yields a within/above/below verdict, but this largely duplicates the schema's own parameter description. No major new parameter semantics are introduced.
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 specific function: it issues a FairPriceAttestation and explicitly does not initiate or execute payments. It distinguishes itself from siblings like verify_fair_price and get_price_range by focusing on creation of an attestation for AP2 Cart Mandates.
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 gives clear context: use this tool to create a price-fairness attestation that an AP2 agent can attach to a Cart Mandate before user signing. It does not explicitly name alternatives or exclusion conditions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
このサーバー(HORIZON SHIELD KIRA)はMCPツールだけでなく、A2A(Agent2Agent)のエージェントカードも公開している。外部のA2A対応エージェントから発見・連携したい場合の、エージェントカードURLと公開スキルの一覧を返す。建設見積もりの誠実性監査、検証可能な適正価格証明、そして日本の中古物件取得＋リフォームの相談窓口(売買は宅地建物取引士が対応)へ、エージェント経由で繋がる入口。 / Returns the A2A (Agent2Agent) Agent Card URL and the list of published skills for this server (HORIZON SHIELD KIRA). Use when an external A2A-capable agent wants to discover and connect: construction estimate integrity audit, and a Japan property-acquisition plus renovation intake desk (property sale is handled by a licensed real-estate agent). This is how agents reach the desk over A2A.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| count | No | How many records matched. 0 means the source was read and nothing matched. It never means the source could not be read, that returns isError: true. |
| lookup | No | ok = the source was read and something matched. absent = the source was read and nothing matched. A source that could NOT be read never appears here: that returns isError: true and makes no claim about what does or does not exist. |
| skills | No | 公開スキル配列 |
| source_read | No | true on every successful result. A failed lookup does not return a result at all, so this is never false, it is declared so a consumer can assert on it. |
| did_you_mean | No | Near matches, when an exact match was not found. |
| agent_card_url | No | エージェントカードURL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds meaningful behavioral context: the tool returns an AgentCard URL and a skill list, and clarifies the boundaries of related services (e.g., property sale is handled by a licensed real-estate agent). This exceeds the annotation baseline without contradicting it.
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 key purpose but is written in both Japanese and English, duplicating the same content. This lengthens it unnecessarily, though the structure is clear and information is presented in a logical order.
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 provides enough context about what the tool returns and when to use it, and there is an output schema so return value details are not required. It could be slightly tighter, but it is complete for its narrow discovery purpose and includes additional useful context on related services.
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 tool has zero parameters and the schema covers 100% of them (none). With no parameters to describe, a baseline of 4 is appropriate. The description does not need to elaborate on parameter semantics.
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 returns the A2A Agent Card URL and the list of published skills, with a specific verb ('get'/'返す') and a distinct resource (the server's A2A agent card). It is distinct from sibling tools that audit estimates and check red flags, so there is no ambiguity about what this 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?
It explicitly says to use the tool when an external A2A-capable agent wants to discover and connect to this server. It provides context for when it applies without giving formal 'when-not-to-use' exclusions, but that is sufficient given the tool's narrow, discovery-focused role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
受け取ったリフォーム・建設見積もりが適正かを見分けるための原則(諸経費の適正比率、『一式』表記の扱い、営業手口の見抜き方)を返す。30年の現場経験に基づく判断軸。 / Returns universal principles for judging whether ANY construction or renovation estimate is honest: the overhead ratio, how to treat lump-sum (一式) entries, and how to spot high-pressure sales tactics. Language-agnostic and works outside Japan. Based on 30 years of field experience.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| count | No | How many records matched. 0 means the source was read and nothing matched. It never means the source could not be read, that returns isError: true. |
| lookup | No | ok = the source was read and something matched. absent = the source was read and nothing matched. A source that could NOT be read never appears here: that returns isError: true and makes no claim about what does or does not exist. |
| source_read | No | true on every successful result. A failed lookup does not return a result at all, so this is never false, it is declared so a consumer can assert on it. |
| did_you_mean | No | Near matches, when an exact match was not found. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds meaningful context: the tool provides general knowledge content rather than a custom assessment, is applicable outside Japan, and is based on 30 years of field experience. 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 efficiently front-loaded with the core purpose and content topics, and every clause adds value—coverage areas, language agnosticism, and basis of authority. The bilingual duplication is acceptable given the tool's context, and there is no wasted 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?
The tool has no parameters, an output schema is present, and the description fully explains the tool's scope and content. It covers what the tool returns, how general it is, and why it is trustworthy. No additional context is needed for an agent to select and invoke it 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?
With zero parameters, the baseline is 4. The description appropriately focuses on what the tool returns without needing to explain input semantics. It also indirectly clarifies there is no filtering or user-input dependency by describing the output as universal.
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 a specific verb and resource: 'returns universal principles for judging whether ANY construction or renovation estimate is honest.' It also lists concrete content areas (overhead ratio, 一式 entries, sales tactics), which distinguishes it from sibling tools like audit_estimate or check_red_flags that perform targeted checks rather than provide general principles.
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 communicates clear context for use: it is a language-agnostic, universal guide applicable to any estimate, not a Japan-specific or single-estimate tool. However, it does not explicitly name alternatives or specify when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
HORIZON SHIELDの相場データ(souba-db)の出典・更新日・地域係数を返す。価格の根拠を確認したい時に使う。 / Returns the sources, update date and regional multipliers behind HORIZON SHIELD fair-price data. Japan. Use to check the basis of a price.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| count | No | How many records matched. 0 means the source was read and nothing matched. It never means the source could not be read, that returns isError: true. |
| lookup | No | ok = the source was read and something matched. absent = the source was read and nothing matched. A source that could NOT be read never appears here: that returns isError: true and makes no claim about what does or does not exist. |
| source_read | No | true on every successful result. A failed lookup does not return a result at all, so this is never false, it is declared so a consumer can assert on it. |
| did_you_mean | No | Near matches, when an exact match was not found. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and destructiveHint=false, so the safe read nature is covered. The description adds that it returns 'sources, update date and regional multipliers' and notes 'Japan' context. It does not describe output format or any edge cases, but with such a simple read-only tool and a readOnlyHint, this is adequate but not 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 two concise sentences with no wasted words. It is front-loaded with the main purpose, includes the Japanese context, and provides a usage hint. Excellent structure for its 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?
Given the tool is simple, has an output schema, and has annotations for safety, the description covers the essential context. It explains the tool's scope (HORIZON SHIELD data, Japan), what it returns, and when to use it. It could mention that no parameters are needed, but that is implied by the schema. For a zero-parameter tool with an output schema, this is quite 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 tool has zero parameters, and schema description coverage is 100% (trivially). The description adds meaning by explaining what data is returned, which is the only semantic needed. Since there are no parameters to describe, the description fulfills its role well.
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 returns sources, update date, and regional multipliers for HORIZON SHIELD fair-price data. The verb 'get' and specific resource 'fair price sources' make the purpose clear. It does not explicitly differentiate from siblings like get_price_range or verify_fair_price, but the focus on metadata (sources, date, multipliers) 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?
The description provides clear context: 'Use to check the basis of a price.' This indicates when to use it. It doesn't explicitly mention alternatives or when not to use it, but the sibling tools like get_price_range or verify_fair_price are distinct enough that the usage context is reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
日本の建設費オープンデータベース(JCCDB)のメタデータ・規模・ライセンス・ダウンロードリンク・引用情報を返す。建設費の一次データ源を探している時に使う。 / Returns metadata, scale, license, download links and citation for the Japan Construction Cost Database (JCCDB), an open dataset of 95,403 Japanese construction line items (v4.0: 43,090 verified + 52,313 extended). Use when looking for a primary construction-cost data source.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| count | No | How many records matched. 0 means the source was read and nothing matched. It never means the source could not be read, that returns isError: true. |
| lookup | No | ok = the source was read and something matched. absent = the source was read and nothing matched. A source that could NOT be read never appears here: that returns isError: true and makes no claim about what does or does not exist. |
| source_read | No | true on every successful result. A failed lookup does not return a result at all, so this is never false, it is declared so a consumer can assert on it. |
| did_you_mean | No | Near matches, when an exact match was not found. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds meaningful behavioral context: the dataset version, size, verified vs. extended breakdown, and exactly which categories of information are returned. This gives the agent a solid expectation of what invoking the tool will surface.
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 compact and front-loaded: it leads with the most important output facts, follows with scale/version details, and closes with the usage trigger. The bilingual version adds modest length but each half carries the same complete information without redundancy beyond the language requirement.
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 no-parameter, read-only metadata tool with an output schema, the description covers everything an agent needs: what data is returned, what the dataset contains, and when to use it. The output schema covers return structure, so no additional return-format explanation is required.
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 tool has zero parameters, so the baseline is 4 per the rubric. The description does not need to explain parameter semantics because there are none, and it instead clarifies the scope of the returned dataset.
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 opens with a specific verb ('returns') and names the exact deliverable set: metadata, scale, license, download links, and citation for the JCCDB. It identifies the resource unambiguously and grounds it with concrete dataset figures (95,403 items, v4.0 breakdown), making it easy to distinguish from generic financial-data 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 states a clear usage context: 'Use when looking for a primary construction-cost data source.' It does not explicitly say when not to use it or name alternative sibling tools, but for a zero-parameter informational tool the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
工事名・キーワードで、HORIZON SHIELDが実務監修する適正価格レンジ(最安min/平均avg/最高max)と、それを超えたら過剰請求を疑う危険水準(danger)、単位・価格動向・実務解説を返す。建設・リフォーム費用が適正か数値で確かめたい時に使う(例: 外壁塗装, 給湯器, ユニットバス, クロス)。 / Returns the fair price range (min, avg, max), the overcharge danger threshold, unit, price trend and field notes for a Japanese construction or renovation job. Japan-specific pricing in JPY. Use to numerically check whether a cost is fair.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 工事名やキーワード(日本語) |
| Name | Required | Description |
|---|---|---|
| work | No | 工事名 |
| count | No | How many records matched. 0 means the source was read and nothing matched. It never means the source could not be read, that returns isError: true. |
| lookup | No | ok = the source was read and something matched. absent = the source was read and nothing matched. A source that could NOT be read never appears here: that returns isError: true and makes no claim about what does or does not exist. |
| fair_range | No | 適正レンジ |
| source_read | No | true on every successful result. A failed lookup does not return a result at all, so this is never false, it is declared so a consumer can assert on it. |
| did_you_mean | No | Near matches, when an exact match was not found. |
| danger_threshold | No | 危険水準 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, so the description need not repeat safety. It adds value by enumerating the full return payload (min/avg/max, danger, unit, trend, notes) and specifying Japan-specific JPY pricing, providing behavioral context beyond what annotations offer.
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 but efficiently packed with all key information: what it returns, the scope (Japanese construction), and usage. No wasted words; it front-loads the action and result immediately.
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 an output schema exists, the description need not detail return fields, but it still lists the key outputs. It covers purpose, usage context, regional specificity, and examples. The tool is simple (1 parameter), and the description fully equips an agent to invoke it 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?
The single parameter 'query' is fully described in the schema (100% coverage). The description enhances schema meaning by listing example keywords (外壁塗装, 給湯器, ユニットバス, クロス), clarifying the expected input domain and giving the agent concrete usage patterns.
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 'Returns' and clearly identifies the resource: fair price range with min/avg/max, danger threshold, unit, trend, and field notes. It distinguishes itself from sibling tools like verify_fair_price or get_fair_price_sources by focusing on retrieving the range data rather than verifying or sourcing it.
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: 'Use to numerically check whether a cost is fair' and gives concrete examples of queries. It does not mention alternatives or exclusions, but the intent is clear enough to guide selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
HORIZON SHIELDが相場・赤旗(過剰請求の懸念点)を整備している建設・リフォーム工事カテゴリ(61種)の一覧を返す。 / Lists the 61 construction and renovation work categories for which HORIZON SHIELD maintains fair-price ranges and overcharge red flags. Japan-specific data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| count | No | How many records matched. 0 means the source was read and nothing matched. It never means the source could not be read, that returns isError: true. |
| lookup | No | ok = the source was read and something matched. absent = the source was read and nothing matched. A source that could NOT be read never appears here: that returns isError: true and makes no claim about what does or does not exist. |
| categories | No | カテゴリ配列(id, name, group, priority, red_flags) |
| source_read | No | true on every successful result. A failed lookup does not return a result at all, so this is never false, it is declared so a consumer can assert on it. |
| did_you_mean | No | Near matches, when an exact match was not found. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description transparently states the count (61), the data specificity (Japan-specific), and the nature of data (fair-price ranges and overcharge red flags). This adds value beyond annotations, though it doesn't detail pagination or return format (output schema exists).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, both dense with relevant information: the count, the data purpose, the region. No filler, no repetition of the title or schema. Front-loaded with the 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?
The tool is simple with 0 parameters and an output schema (which likely lists the categories). However, the description doesn't mention how the list is returned (detailed fields vs. names), or whether any filtering is possible. It is mostly complete for a simple list, but given the output schema exists, the description needn't explain return values. A score of 3 is fair: adequate but would be 4 with a hint about the output's shape.
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 tool has 0 parameters, so the baseline for parameter semantics is 4. The description doesn't need to add parameter meaning; it correctly describes the fixed output set. The schema covers everything, and the description complements it by specifying the scope.
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 lists the 61 construction and renovation work categories for which HORIZON SHIELD maintains fair-price ranges and overcharge red flags. This clearly distinguishes it from sibling tools like search_cost_category (search) and get_price_range (query range), both in 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 is clear that this tool is for retrieving the category list. However, it does not explicitly state when not to use it or mention alternatives. Given the no-parameter nature and simple listing purpose, clear context is provided, but explicit exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
リフォーム検討の初期段階向けのプレビューで、業者の概算が平均からどちらの方向にどの程度ずれているか(例: +20%高い方向)だけを返す。具体的な適正額(min/avg/max)や危険水準は返さない。手元に詳しい見積内訳がまだ無い段階での最初の一歩に向く。具体的な適正レンジが必要なら get_price_range、見積額の詳細診断は audit_estimate を使う。Japan only, JPY。 / A preview for early-stage renovation planning that returns only the direction of a contractor rough estimate versus the average (e.g. about +20% above). It does not return the specific fair range (min/avg/max) or danger threshold. Suited as a first step before a detailed breakdown exists. Use get_price_range for a typical range, audit_estimate for a detailed quote diagnosis.
| Name | Required | Description | Default |
|---|---|---|---|
| work | Yes | 工事名(日本語)。例: 外壁塗装 シリコン。部分一致で照合。 | |
| quoted_price | Yes | 業者提示の概算額(円, 数値)。 |
| Name | Required | Description |
|---|---|---|
| count | No | How many records matched. 0 means the source was read and nothing matched. It never means the source could not be read, that returns isError: true. |
| lookup | No | ok = the source was read and something matched. absent = the source was read and nothing matched. A source that could NOT be read never appears here: that returns isError: true and makes no claim about what does or does not exist. |
| source_read | No | true on every successful result. A failed lookup does not return a result at all, so this is never false, it is declared so a consumer can assert on it. |
| did_you_mean | No | Near matches, when an exact match was not found. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=true, destructiveHint=false), the description discloses the tool's intentionally limited behavior: it does not return min/avg/max fair range or danger thresholds, only direction. This behavioral limitation is essential for setting correct expectations and is not visible in the schema or 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 bilingual description is somewhat long but each section earns its place: purpose, limitation, usage timing, alternatives, and locale constraints. It is front-loaded with the core behavioral result and avoids unnecessary flourish.
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 an output schema present, a 100% documented input schema, and strong annotations, the description adds the remaining necessary context: early-stage suitability, exclusion of detailed outputs, alternative tools, and Japan/JPY scope. This is complete for an agent 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% with detailed descriptions for both parameters, including examples and partial-match behavior for work. The description adds context about comparing against an average but does not materially extend parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's specific function: it returns only the direction of a contractor's rough estimate relative to the average (e.g., +20% above). It also explicitly distinguishes itself from siblings by noting what it does not return and naming alternatives like get_price_range and audit_estimate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is explicit: it is for early-stage renovation planning before a detailed breakdown exists. The description gives clear when-to-use guidance and names specific alternative tools for different needs, making it easy for an agent to select correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
工事名・キーワードで建設費カテゴリを検索する(例: 外壁塗装, 浴室, 給湯器, 雨漏り)。該当カテゴリと整備済みの赤旗件数・優先度を返す。 / Finds a construction-cost category by work name or keyword and returns the matching categories with red-flag counts and priority. Japan-specific; a Japanese query works best (e.g. 外壁塗装 exterior painting, 浴室 bathroom).
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 工事名やキーワード(日本語) |
| Name | Required | Description |
|---|---|---|
| count | No | How many records matched. 0 means the source was read and nothing matched. It never means the source could not be read, that returns isError: true. |
| lookup | No | ok = the source was read and something matched. absent = the source was read and nothing matched. A source that could NOT be read never appears here: that returns isError: true and makes no claim about what does or does not exist. |
| source_read | No | true on every successful result. A failed lookup does not return a result at all, so this is never false, it is declared so a consumer can assert on it. |
| did_you_mean | No | Near matches, when an exact match was not found. |
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 known. The description adds beyond that by specifying that it returns matching categories with red-flag counts and priority, and notes the Japan-specific nature. This gives the agent a clearer picture of the tool's output without contradicting annotations. A score of 4 acknowledges this added 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 (in both Japanese and English) that are front-loaded with the core purpose, followed by examples. There is no redundant filler, and the structure effectively conveys the key information in a compact form. Achieves a perfect score for conciseness and 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?
With only one parameter, no nested objects, and an existing output schema, the description is sufficiently complete. It covers the search behavior, examples, and return value highlights (red-flag counts and priority). The tool's simplicity and the presence of an output schema mean no additional context is 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?
The schema covers 100% of parameters with a simple description (工事名やキーワード), so baseline is 3. The description adds value by providing concrete example queries (外壁塗装, 浴室, 給湯器) and clarifying that Japanese keywords work best, which helps the agent form effective queries. This enrichment justifies one point above baseline.
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: 'Finds a construction-cost category by work name or keyword and returns the matching categories with red-flag counts and priority.' It uses a specific verb ('finds') and identifies the resource (construction-cost category) plus what it returns. It also gives concrete examples (外壁塗装, 浴室) that help distinguish it from siblings like list_cost_categories, which presumably lists all categories without a search query.
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: use this tool when you need to search by a work name or keyword rather than listing all categories. It provides examples of suitable queries and notes that Japanese queries work best, which gives practical guidance. However, it does not explicitly mention alternatives like list_cost_categories or state when NOT to use this tool, so it stops short of a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
見積もりを匿名で第三者レビューに出せる掲示板EHN(見積もりハッカーニュース)の案内文と投稿フォームURLを返す。投稿と一次解析は無料で、業者名や個人情報は掲載前に運営が伏せる。ユーザーが見積もりのセカンドオピニオンや相談先を求めた時に使う。 / Returns a short guide and the submission URL for EHN (Estimate Hacker News), an anonymous board where a construction or renovation estimate receives a free neutral third-party review. Personal and contractor names are redacted before posting. Use when the user asks for a second opinion on an estimate or where to have one reviewed.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| count | No | How many records matched. 0 means the source was read and nothing matched. It never means the source could not be read, that returns isError: true. |
| lookup | No | ok = the source was read and something matched. absent = the source was read and nothing matched. A source that could NOT be read never appears here: that returns isError: true and makes no claim about what does or does not exist. |
| board_url | No | 公開ボード |
| submit_url | No | 投稿フォーム |
| source_read | No | true on every successful result. A failed lookup does not return a result at all, so this is never false, it is declared so a consumer can assert on it. |
| did_you_mean | No | Near matches, when an exact match was not found. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a safe read-only operation, but the description adds meaningful behavioral context: the review is free, neutral, anonymous, and personal/contractor names are redacted before posting. It does not describe the exact return shape, but an output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, bilingual, and front-loaded with the core action. Both language versions add complementary value, and the 'Use when' sentence provides practical guidance without 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 zero parameters, existing annotations, and an output schema, the description fully covers what the tool does, when to use it, and important behavioral caveats like redaction and free review.
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 tool has zero parameters, which gets a baseline of 4. The description needs no parameter explanation and appropriately focuses on the tool's purpose and output.
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 states a specific verb and resource: 'Returns a short guide and the submission URL for EHN,' an anonymous estimate review board. It clearly distinguishes this from sibling tools like audit_estimate or get_price_range by focusing on referral to a third-party review platform.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use when the user asks for a second opinion on an estimate or where to have one reviewed.' This gives clear context, though it does not mention when not to use it or name direct alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
工事の適正価格を、検証可能な形(算出内容のSHA-256ハッシュ付き)で返す。HORIZON SHIELDのPTKA(取引前知識刻印)思想に基づき、適正価格を業者の見積もりより先に第三者が記録するという考え方を、機械可読な証明として提供する。エージェントが価格の真正性を検証したい時に使う。 / Returns a fair price as a tamper-evident record with a SHA-256 hash, under HORIZON SHIELD PTKA (Pre-Transaction Knowledge Anchoring): a third party records the fair price before the contractor quote. Japan price data. Use when an agent needs to verify price authenticity.
| Name | Required | Description | Default |
|---|---|---|---|
| work | Yes | 工事名(例: 外壁塗装 30坪) |
| Name | Required | Description |
|---|---|---|
| count | No | How many records matched. 0 means the source was read and nothing matched. It never means the source could not be read, that returns isError: true. |
| lookup | No | ok = the source was read and something matched. absent = the source was read and nothing matched. A source that could NOT be read never appears here: that returns isError: true and makes no claim about what does or does not exist. |
| provenance | No | データ出典・監修・再計算手順 |
| source_read | No | true on every successful result. A failed lookup does not return a result at all, so this is never false, it is declared so a consumer can assert on it. |
| did_you_mean | No | Near matches, when an exact match was not found. |
| verification | No | claim_sha256, verify_url, ptka |
| fair_price_claim | No | 刻印対象の主張(JSON.stringifyしてSHA-256すると claim_sha256 になる) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds that the output is a tamper-evident record with a SHA-256 hash and explains the PTKA concept, providing useful behavioral context about the proof mechanism.
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, but includes a philosophical explanation that is slightly extraneous. It front-loads the core function and structure is 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?
With an output schema present, annotations covering safety, and a single parameter, the description provides sufficient context about the tool's purpose, usage, and underlying concept. It lacks some details about potential error cases, but these are likely in the 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?
The single parameter 'work' is fully described in the schema with an example. The description does not add additional parameter semantics, but the schema coverage is 100%, so the 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 clearly states the tool returns a fair price as a tamper-evident record with a SHA-256 hash, and explicitly notes its use for verifying price authenticity. This distinguishes it from siblings like get_price_range or audit_estimate, which have different purposes.
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?
It explicitly says 'Use when an agent needs to verify price authenticity,' providing a clear usage context. It does not name specific alternatives, but the context is clear enough 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.
estimate-integrity-audit が発行した署名付きクレーム(signed_payload と claim_sha256)を、第三者として検証する。発行側 (verify_fair_price はPTKA価格の発行) とは責務が正反対で、デフォルト姿勢は不信・fail closed。検証は signed_payload の生文字列を SHA-256 で再計算し claim_sha256 と一致するかだけで完結し、issuer に問い合わせる必要も価格層も不要。判定は契約 0.3 の failure_reasons 準拠で、result(verified / partial / unverified)・failure_reason(stale_data / changed_scope / missing_evidence)・trigger(expired_declaration / changed_estimate_version / missing_receipt / unverifiable_chain)・recomputed_sha256・scope_check・audit_ruleset_recheck を返す。重要: verified は『この宣言が改ざんされていない』ことの証明であって『監査ルールが今も有効』である保証ではない(audit_ruleset_recheck は常に not_performed)。estimate_version を渡すと scope(見積もり内容が発行時から変わっていないか)も照合し、渡さない場合は scope_check:skipped を明示する。 / Verifies a signed integrity claim (signed_payload and claim_sha256) issued by estimate-integrity-audit, as an independent third party. Opposite posture to the issuing side: distrust by default, fail closed. Recomputes SHA-256 over the raw signed_payload string and checks it equals claim_sha256; no issuer contact and no price layer needed. Follows contract 0.3 failure_reasons. IMPORTANT: verified means the declaration is untampered, NOT that the audit ruleset is still valid (audit_ruleset_recheck is always not_performed). Pass estimate_version to also check scope (whether the estimate changed since issuance); if omitted, scope_check is skipped and stated explicitly.
| Name | Required | Description | Default |
|---|---|---|---|
| claim_sha256 | Yes | そのレスポンスの claim_sha256 (64桁16進)。 / The claim_sha256 (64-char hex) from the same response. | |
| signed_payload | Yes | 検証対象の署名付きペイロード(estimate-integrity-audit のレスポンスの signed_payload を生文字列のまま)。改変するとハッシュ不一致で unverified になる。 / The signed_payload string from an estimate-integrity-audit response, verbatim. Any change makes the hash mismatch and the result unverified. | |
| estimate_version | No | (任意) 呼び出し側が現在の見積もりテキストから算出した estimate_version (input_text の SHA-256 先頭8桁hex)。渡すと発行時の版と一致するか照合する。省略可。 / (optional) The estimate_version the caller computed from the current estimate text (first 8 hex of SHA-256 of input_text). If provided, scope is checked against the issued version. |
| Name | Required | Description |
|---|---|---|
| count | No | How many records matched. 0 means the source was read and nothing matched. It never means the source could not be read, that returns isError: true. |
| lookup | No | ok = the source was read and something matched. absent = the source was read and nothing matched. A source that could NOT be read never appears here: that returns isError: true and makes no claim about what does or does not exist. |
| result | No | verified / unverified |
| source_read | No | true on every successful result. A failed lookup does not return a result at all, so this is never false, it is declared so a consumer can assert on it. |
| did_you_mean | No | Near matches, when an exact match was not found. |
| failure_reason | No | stale_data / changed_scope / missing_evidence |
| recomputed_sha256 | No | 再計算ハッシュ |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint and openWorldHint annotations by detailing the fail-closed behavior, the SHA-256 recomputation, and the distinction between 'verified' (hash match) and 'audit ruleset still valid'. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is thorough but slightly redundant (e.g., 'fail closed' and 'no price layer needed' appear more than once). However, the structure is logical, covering purpose, method, and caveats, and each sentence adds useful 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?
Despite having an output schema, the description provides essential behavior context: return fields (result, failure_reason, etc.), edge cases (scope_check skipped if estimate_version omitted), and the crucial caveat that verified does not imply audit ruleset validity. This makes the tool's behavior fully understandable.
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 three parameters are described with clear semantics: claim_sha256 as expected hash, signed_payload as verbatim string (with warning about mutation causing unverified), and estimate_version as optional for scope checking. This fully complements 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 it verifies signed integrity claims from estimate-integrity-audit and distinguishes itself from verify_fair_price by noting 'no price layer needed' and 'opposite posture'. This clearly separates it from the sibling 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?
Provides explicit guidance on when to use (when you have signed_payload and claim_sha256) and how to invoke (optionally pass estimate_version to also check scope). It also clarifies that no issuer contact is needed and that it fails closed, which helps the agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
建設・リフォーム見積もりの誠実性を適正レンジで監査するMCP App(UI付き・出典検証込み)
Read-only MCP server for searching Japan government procurement bid information from the KKJ portal.
Neutral, verification-gated MCP directory of Japan construction contractors (KIRA-audited).
Hosted MCP server for LLM cost estimation, model comparison, and budget-aware routing.
Add one secure layer between your agents and this server.
Most tools have distinct purposes: audit_estimate for detailed quote diagnosis, get_price_range for typical ranges, preview_reverse_estimate for early-stage direction, verify_fair_price for tamper-evident records. However, audit_estimate, get_price_range, and preview_reverse_estimate overlap in the price-checking domain, and verify_fair_price vs verify_integrity_claim could be confused (both involve SHA-256 verification), though descriptions clarify the opposite postures.
Most tools follow a verb_noun pattern (audit_estimate, check_red_flags, get_price_range, list_cost_categories, search_cost_category, suggest_ehn, verify_fair_price). Minor deviations: create_ap2_fairness_attestation is longer and more specific, and get_agent_card/get_estimate_reading_guide/get_fair_price_sources/get_jccdb_dataset_info all start with 'get' but vary in noun phrasing. Overall consistent and predictable.
14 tools is within the ideal 3-15 range, and each tool serves a distinct function in the domain of construction estimate auditing and fair-price verification. Slightly on the higher end but justified by the breadth of features (price lookup, audit, attestation, verification, data sources, educational guides).
The server covers the core workflow: lookup price ranges, audit specific quotes, check red flags, generate attestations, verify claims, and access data sources. Minor gaps: no tool for submitting new price data or updating categories, and no direct tool for comparing multiple quotes side-by-side, but agents can work around these with existing tools.
