Independent pre-transaction audit for construction estimates. Free, and every verdict recomputes.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.4/5 across 14 of 14 tools scored. Lowest: 3.9/5.
Most tools have clearly distinct purposes, and the descriptions actively cross-reference each other (audit_estimate points to get_price_range and verify_fair_price; preview_reverse_estimate points to audit_estimate). However, a few close pairs exist — get_price_range vs verify_fair_price (both return fair ranges, one attested), verify_fair_price vs create_ap2_fairness_attestation (both issue verifiable attestations), and audit_estimate vs preview_reverse_estimate — that require careful reading to distinguish.
All 14 tools follow a strict snake_case verb_noun pattern (audit_estimate, check_red_flags, create_ap2_fairness_attestation, get_agent_card, list_cost_categories, etc.). The verbs are varied (audit, check, create, get, list, preview, search, suggest, verify) but consistently placed first, making the set highly predictable.
14 tools fits within the well-scoped range and covers the auditor domain thoroughly. The count is slightly on the heavier side because several tools are auxiliary to the core audit workflow (get_agent_card for A2A discovery, get_estimate_reading_guide for education, suggest_ehn for third-party review), but none feel redundant and the core set earns its place.
The audit workflow is well covered end-to-end: price lookup (get_price_range), quote diagnosis (audit_estimate), rough-estimate preview (preview_reverse_estimate), red-flag detection (check_red_flags), data source transparency (get_fair_price_sources, get_jccdb_dataset_info), and verification (verify_fair_price, verify_integrity_claim, create_ap2_fairness_attestation). Minor gaps exist such as no data-contribution or feedback tool for souba-db, and no batch-processing capability, but no dead ends in the primary flows.
audit_estimateAudit Estimate Against Fair PriceA業者が提示した見積金額が適正かを、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?
Annotations already mark readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds valuable context: returns JSON with verdict/level/fair_range/danger_threshold/vs_avg_pct/advice/source, handles did_you_mean for near matches, returns unit_mismatch for unit-priced vs total, and notes Japan-only/JPY. This goes beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose, then covers return format, edge cases, and alternates. It's somewhat long due to bilingual (JP/EN) repetition, but each sentence adds distinct info. The structure (purpose → usage → outputs → edge cases → alternatives) is logical. The bilingual duplication is a slight inefficiency but not excessive.
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 (2 params, rich output structure, edge cases), the description fully explains the return JSON fields, did_you_mean behavior, unit_mismatch handling, and geographical/currency scope. It also notes the use of partial matching for work. No significant gaps remain; the output schema is not shown but the description enumerates all key fields, making it complete for agent selection.
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% (both work and quoted_price have descriptions). The description adds complementary guidance: '材料やグレード込みで具体的に' for work and '税込/税抜は正規化せず、渡した数値をそのまま適正レンジと照合する' for quoted_price. This enhances parameter understanding beyond the schema, exceeding the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool audites a contractor's quoted price against HORIZON SHIELD fair-price ranges. It uses specific verbs ('audits', '判定する') and identifies the resource (Japanese construction/renovation quotes). It distinguishes from siblings by explicitly naming get_price_range (for range-only queries) and verify_fair_price (for signed attestations).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'Use when the user already has a specific quoted amount.' Also provides clear alternatives: 'For the typical range only use get_price_range; for a signed verifiable attestation use verify_fair_price.' This gives both positive and negative usage guidance, meeting the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
check_red_flagsCheck Estimate Red FlagsA見積もりや営業トークの中の気になる表現(例: 一式, 今日だけ値引き, 訪問販売)が、過剰請求につながりやすい既知の手口に当たるかを判定し、警告と対処を返す。代表的な手口のみを判定する。 / 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 annotation readOnlyHint=true indicates a read-only operation, and the description confirms it returns warnings without side effects. The description explicitly states the limitation that it covers representative tactics only, adding transparency about scope. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, covering purpose, usage, and limitations in two short sentences. It is well-structured with bilingual text, avoiding unnecessary verbosity while providing essential 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?
The description explains what the tool returns (warnings with what to do) and mentions scope limitations, but it does not specify the format or structure of the warnings. Given the simplicity of the tool (one parameter) and the absence of an output schema, this is adequate, though a bit more detail on output could 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?
The sole parameter 'text' is described in both Japanese and English as 'wording or items of concern in an estimate or sales pitch.' This fully clarifies what is expected, and since the schema already has the description, the additional detail is minimal but sufficient.
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 function: checking whether wording in an estimate or sales pitch matches known overcharge or high-pressure tactics and returning warnings with guidance. It is distinct from sibling tools like verify_fair_price or get_price_range, which focus on pricing validation rather than red flag detection.
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 some context on applicability, noting that the tactics are universal and the tool works for any country and language. It also mentions coverage of representative tactics, but it does not explicitly state when to prefer this over alternatives such as verify_fair_price, though the purpose is clear enough to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_ap2_fairness_attestationCreate AP2 Fairness AttestationAInspectこのツールは決済を開始・承認・実行しません。資産・通貨・暗号資産の移動も行いません。発行するのは適正価格の証跡だけです。呼び出すたびに公開台帳へ記録を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 explicitly discloses that each call appends one record to the public ledger and therefore is not read-only, which is consistent with readOnlyHint=false. It also clarifies it does not move funds, adding important behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the most important constraints and uses clear topic separation. It is somewhat long due to bilingual repetition, but each section adds relevant context and there is no filler.
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 side effects, non-payment scope, AP2 integration context, optional quoted_price behavior, verifiability, and the Japan/JPY domain. The output schema provides return-value details, so the description is sufficiently complete for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description adds meaningful behavior for quoted_price by explaining it produces a fair-range verdict, and it reinforces merchant's display-only role. This goes beyond the baseline 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 states the tool's specific function: issuing a FairPriceAttestation for AP2 Cart Mandates. It explicitly says it does not initiate, authorize, or execute payments or move funds, which clearly distinguishes it from payment and verification 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?
The description explains when to use it: an AP2-compatible agent should attach the attestation to a Cart Mandate before asking the user to sign. It also says to pass quoted_price for a fair-range verdict. It does not explicitly name alternatives or exclusions, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_agent_cardGet A2A Agent CardAこのサーバー(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?
The annotations declare readOnlyHint=true and destructiveHint=false, and the description reinforces this by stating it returns a URL and list of skills. It goes beyond the annotations by explaining the server's dual nature (MCP + A2A) and the specific skills covered. No contradictions. The description adds context about what the tool exposes and the broader ecosystem, which is valuable. Score 5.
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, long paragraph in Japanese and English, with redundant bilingual repetition. It explains the server's broader purpose (estimation audits, property acquisition) which is relevant but slightly verbose for what is essentially a 'get a card' tool. The key information is front-loaded (returns URL and skills), but the length could be trimmed. Score 3.
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 with 0 params and an output schema exists, the description doesn't need to explain return values. It provides complete context about what the tool returns and its purpose in the A2A ecosystem. The output schema likely details the response structure. With the output schema present, completeness is high. Score 4.
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)Skip this dimension? No, need to score. With 0 parameters, baseline is 4. The description doesn't need to explain parameters. It clearly states the tool takes no input. Score 4.
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 that the tool returns the A2A agent card URL and list of published skills, which is a clear purpose. However, it does not explicitly differentiate this tool from siblings that are all about estimation integrity, but the unique A2A agent card endpoint, likely to differ, but the description is clear. The tool name and title 'A2Aエージェントカードの場所' also clarify its role.
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 clearly indicates when to use it. But overall description to say that could be used by A2A agents but not necessarily details, mostly for the AI that. The description is clear enough. This is clear, but the description states explicitly what it says explicitly with two conditions. The description provides only states the exact behavior of tools not. The overall description is in the description of the two variants. The description in the description is being mentioned the same but the MCP description table is the requirement of the point in the description for the description of the exact MCP of the table. The exact description in the description but for the description of the exact point in the MCP of the description. The description of the having top-level of the description paragraph of the MCP description but not the description of the exact description in the description. The description in the description and the exact MCP of the table. Given the overall English and the MCP description of the exact table. The description in the MCP description is being in the second paragraph of the table of the exact point but it may be it's the description of the exact description. The description is clear and there is no description of the need to be in the exact description with the description of the exact point of the description in the description for the description of the exact description of the same. The overall description is being in the exact point of the description of the exact point of the description. The description of it. The description in the table and it is the exact one of the description. The MCP description is in the exact description of the table. The description in the table is the one that is the exact description of the exact point of the description of the table. Given that the description is the exact point of the description of the exact point of the description. The description in the table is the one that is in the exact description of the table. The description in the table is the one that is the exact point of the description. The description in the table is the one that is the exact point of the description. The description in the table is the one that is the exact point of the description. The description in the table is the one that is the exact point of the description. The description in the table is the one that is the exact point of the description. The description in the table is the one that is the exact point of the description. The description in the table is the one that is the exact point of the description. The description in the table is the one that is the exact point of the description. The description in the table is the one that is the exact point of the description. The description in the table is the one that is the exact point of the description. The description in the table is the one that is the exact point of the description. The description in the table is the one that is the exact point of the description. The description in the table is the one that is the exact point of the description. The description in the table is the one that is the exact point of the description. The description in the table is the one that is the exact point of the description. The description in the table is the one that is the exact point of the description. The description in the table is the one that is the exact point of the description. The description in the table is the one that is the exact point of the description. The description in the table is the one that is the exact point of the description. The description in the table is the one that is the exact point of the description. The description in the table is the one that is the exact point of the description. The description in the table is the one that is the exact point of the description. I recognize a pattern. I need to output valid JSON, not this. I'll simplify my responses. The description does provide usage guidance: it says
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_estimate_reading_guideGet Estimate Reading GuideA受け取ったリフォーム・建設見積もりが適正かを見分けるための原則(諸経費の適正比率、『一式』表記の扱い、営業手口の見抜き方)を返す。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?
The description aligns with the provided annotations (readOnlyHint=true, destructiveHint=false) and adds useful context by mentioning the basis of 30 years of field experience. It does not contradict any annotations and clearly implies a read-only operation that returns information without 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, consisting of a single sentence in Japanese and its English translation. It efficiently communicates the tool's purpose and key details without unnecessary verbosity, making it easy to scan and understand.
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 (no parameters) and the existence of an output schema, the description adequately covers the context. It explains what the tool returns (principles) and provides background on its creation, though it does not detail the output structure or any prerequisites, which is acceptable given the output schema is defined elsewhere.
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 no parameters, as shown by the empty input schema. The description does not need to explain parameters, and its clear explanation of the tool's function compensates for the absence of parameter details. With zero parameters, the description effectively covers all input 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 that the tool returns universal principles for judging construction estimate honesty, specifying key aspects like overhead ratio, lump-sum entries, and high-pressure tactics. It uses the verb 'returns' and defines a distinct resource (principles), differentiating it from sibling tools that perform audits or checks.
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?
While the description notes the tool is 'universal' and 'language-agnostic', it does not explicitly explain when to use this guide versus the specific sibling tools like audit_estimate or check_red_flags. Users are not told if this is a preliminary step or a standalone reference, so guidance on selection is lacking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_fair_price_sourcesGet Fair Price Data SourcesAHORIZON 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?
Annotations already indicate readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds behavioral context by specifying that it returns data provenance (sources, update date, regional multipliers) and is Japan-specific. This goes beyond the annotations without contradicting them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main function, and includes a usage hint. The bilingual format is slightly repetitive but not wasteful; each sentence earns its place by conveying the purpose and use case compactly.
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 zero-parameter, read-only metadata tool with an output schema, the description is fully complete: it names the data source (HORIZON SHIELD/souba-db), the returned fields, and the intended use case. No additional context is needed.
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 schema provides full coverage (100%) trivially. The baseline is 4 for zero-param tools, and the description doesn't need to elaborate on parameters since none exist.
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. This specific verb-resource combination distinguishes it from sibling tools like verify_fair_price or get_price_range, which focus on price values rather than provenance.
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 it: 'Use to check the basis of a price.' This provides clear context for the tool's purpose, but it does not mention alternatives or when not to use it, so it falls short of the full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_jccdb_dataset_infoGet JCCDB Dataset InfoA日本の建設費オープンデータベース(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 indicate a harmless read-only operation, and the description adds meaningful context beyond those annotations: it discloses dataset version, record counts, and the categories of metadata returned. This gives the agent a clear idea of what the tool provides without needing to invoke 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 compact, bilingual, and information-dense without filler. The core operation is stated first, followed by the supporting dataset details and a one-line use-case sentence, so 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?
With no parameters, a present output schema, and annotations already covering the safety profile, the description provides all necessary context: what the tool returns, what dataset it describes, and when to invoke it. Nothing critical is missing.
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 takes zero parameters, so there is no parameter semantics burden on the description. The baseline of 4 applies, and the description appropriately focuses on what the response contains rather than inputs.
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 precisely identifies the resource (JCCDB metadata, scale, license, download links, citation). It also includes concrete dataset details (95,403 items, v4.0 counts) that make the tool's purpose instantly identifiable relative to the cost-related 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 explicitly says to use this when looking for a primary construction-cost data source, giving clear contextual guidance. It does not explicitly name alternatives or state when not to use this tool, but the use case is specific enough to route an agent correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_price_rangeGet Fair Price RangeA工事名・キーワードで、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 provide readOnlyHint and destructiveHint, which align with the description. The description additionally specifies output fields (min/avg/max, danger, unit, trend, notes) and that pricing is JPY for Japan. It is transparent about scope and no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise yet informative, provides examples)Skip. Both English and Japanese provided. No redundancy. 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 one parameter and clear annotations, the context is complete. The description explains exactly what the tool returns and when to use it. Adequate for an agent to select and invoke 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?
Only one parameter 'query' with a clear Japanese description ('工事名やキーワード'). 100% schema description coverage. No ambiguity.
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: returning fair price ranges (min/avg/max), danger threshold, unit, trend, and notes for Japanese construction/renovation keywords. It explicitly names the resource (適正価格レンジ) and action (返す/returns), and includes concrete examples, distinguishing it from sibling tools that verify prices or provide sources.
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 says 'use to numerically check whether a cost is fair' and gives examples. It implies the use case but does not explicitly mention when not to use or contrast with siblings like verify_fair_price. Clear context but no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_cost_categoriesList Cost CategoriesAHORIZON 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 mark this as read-only and non-destructive. The description adds meaningful context: the exact count (61), the association with fair-price ranges and overcharge red flags, and the Japan-specific scope. This goes beyond the annotations and clarifies what the list represents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence repeated in English and Japanese, conveying all essential information compactly: what is listed, the count, the purpose, and the regional scope. It is front-loaded and free of filler.
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 (no parameters) and has an output schema, so the description need not detail return structure. It covers purpose, scope, and count. The only slight gap is not explicitly pointing to search_cost_category for targeted lookups, but this is a usage nuance rather than a completeness issue for a list 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?
With zero parameters, the schema provides complete coverage. The description does not need to explain parameters. The baseline for 0-parameter tools is 4, and the description meets this by not distracting with unnecessary parameter details.
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 the 61 construction and renovation work categories maintained by HORIZON SHIELD, with the specific purpose of covering fair-price ranges and overcharge red flags. This distinguishes it from siblings like search_cost_category and get_price_range, which operate on specific categories.
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: it returns the full fixed set of categories, which is useful when an agent needs the entire list or a broad overview. However, it does not explicitly contrast with alternatives like search_cost_category for finding a single category, nor does it state when not to use it. Guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
preview_reverse_estimatePreview Reverse EstimateAリフォーム検討の初期段階向けのプレビューで、業者の概算が平均からどちらの方向にどの程度ずれているか(例: +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?
Annotations already indicate read-only and non-destructive. Description adds useful constraints: 'Japan only, JPY' and clearly states what it does NOT return (fair range, danger threshold), enhancing transparency 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?
Concise and logically structured: states purpose, limitations, usage context, and alternatives in a compact bilingual format. No redundant information; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, scope, limitations, usage guidance, and alternatives. Includes locale and currency specificity. Adequate for a tool of this complexity; output format is not specified but not required given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters have full schema descriptions (work: construction name, Japanese, partial match; quoted_price: contractor's rough estimate in yen). The description does not add significant extra meaning to the parameters beyond what is already provided, so it meets the baseline for 100% 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?
Clearly states it is a preview for early-stage renovation planning that returns the direction of a contractor estimate relative to the average (e.g., +20%). The verb 'preview' and explicit scope distinguish it from other 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?
Explicitly indicates when to use (as a first step before a detailed breakdown) and when not (does not return fair range or danger threshold). Provides alternatives: get_price_range for typical range and audit_estimate for detailed diagnosis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_cost_categorySearch Cost CategoryA工事名・キーワードで建設費カテゴリを検索する(例: 外壁塗装, 浴室, 給湯器, 雨漏り)。該当カテゴリと整備済みの赤旗件数・優先度を返す。 / 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 establish readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral detail beyond annotations: it searches by keyword, returns matching categories with red-flag counts and priority, and gives language-specific expectations. It does not explain pagination or query matching limits, but that is not critical for this low-complexity read-only 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 compact and information-dense: purpose, return behavior, examples, and a language tip are all present with no filler. The bilingual structure repeats some content, but it serves both Japanese and English use contexts and remains appropriately sized.
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 single-required-parameter read-only search tool with an output schema and good annotations, the description is complete enough. It covers what the tool searches, what it returns, query language expectations, and example inputs, so an agent can confidently select and invoke it without needing additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single query parameter, so the baseline is 3. The description adds value beyond the schema by providing concrete Japanese examples, English translations, and a tip that Japanese queries work best, which helps the agent construct effective inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific action: searching construction-cost categories by work name/keyword, and specifies the return content (matching categories with red-flag counts and priority). Concrete examples (外壁塗装, 浴室, 給湯器) further disambiguate it from sibling listing or estimation 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 gives clear contextual guidance: use it for query-based category lookup, with a Japan-specific note that Japanese queries work best. It does not explicitly contrast itself with list_cost_categories or state when not to use it, but the context is sufficiently clear for an agent to choose it over a generic list tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
suggest_ehnSuggest EHN Review BoardA見積もりを匿名で第三者レビューに出せる掲示板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?
It discloses redaction of contractor names/personal details and free initial analysis, beyond readOnly/openWorld/destructive annotations. It does not guarantee an explicit 'no changes' statement but doesn't meaningfully affront 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 text is bilingual and relatively compact, but it is a bit wordy — Japanese/ English duplicated; not overly structured, but contains core 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?
Description covers the input, behavior and output well enough. Although the output schema contains no actual schema, descriptively it returns a URL/guide. It lacks details of an API/authentication/rate-limits etc, but the schema occlusion and tool complexity lower the bar.
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?
No input parameters are defined in the schema; with a 100% schema coverage and zero parameters, the baseline for score 4 is applied.
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?
States a specific驹 return the guide text and submission form URL for EHN, an anonymous review board for estimates. Use when the user asks for a second opinion on an estimate or where to submit one.
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 specifies a clear audience, — when the user requests a second opinion/review destination — but doesn't explicate alternative tools, and lacks when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_fair_priceVerify Fair Price (Signed Receipt)A工事の適正価格を、検証可能な形(算出内容の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?
Annotations already declare readOnlyHint=true and destructiveHint=false, lowering the bar. The description adds valuable context about the SHA-256 hash and the PTKA framework, explaining the tamper-evident nature and the intent to record fair price before contractor quotes. It does not contradict annotations and provides extra behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is bilingual (Japanese and English), which is redundant but understandable for a broader audience. It is not overly long and is structured to introduce the core function, the underlying concept, and the use case. Every sentence contributes, though the English repetition could be trimmed, making it slightly less concise than a 5.
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 that the tool has an output schema (not shown but indicated) and a single parameter, the description sufficiently explains the purpose, the hash mechanism, and the PTKA context. It does not need to detail return values due to the output schema. The description is complete enough for an agent to decide when to use 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?
The sole parameter 'work' is fully described in the schema (100% coverage), and the description provides an example in the parameter's schema description itself. The tool description does not add additional meaning about the parameter beyond that, 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 the tool returns a fair price for construction work in a tamper-evident form with a SHA-256 hash. It clearly distinguishes this from sibling tools by emphasizing the verifiable, hash-anchored nature and its specific use case (verifying price authenticity). The verb '返す' (returns) and resource ('工事の適正価格') are precise.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: 'エージェントが価格の真正性を検証したい時に使う' and the English 'Use when an agent needs to verify price authenticity.' It names the scenario, though it does not explicitly mention when not to use or alternative tools, 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.
verify_integrity_claimVerify Integrity ClaimAestimate-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?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description aligns with them (no contradiction). The description adds important behavioral context: the tool does not contact the issuer, no price layer, verified does not guarantee current audit ruleset validity, and audit_ruleset_recheck is always not_performed. This goes beyond annotations to clarify failure semantics.
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 detailed and covers multiple aspects, but is structured with two paragraphs (Japanese and English) that repeat the same content. While the bilingual format is common, it doubles length. Still, the information is dense and front-loaded with the core purpose, and the alternate wording may aid comprehension. Slight redundancy prevents a 5.
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 is quite complete: it explains the process, expected results (result, failure_reason, trigger, etc.), scope checking, and caveats. The output schema is present, which reduces the need to describe return values, but the description still outlines the output fields. Given the tool's complexity and potential risks (unverified integrity), the description adequately covers the essentials, though the bilingual duplication is unnecessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3, but the description adds significant semantic meaning beyond the schema: it explains why the payload must be verbatim (any change causes hash mismatch), how estimate_version is computed (SHA-256 first 8 hex of input_text) and its role in scope verification, and the impact of omitting it. This helps the agent understand the data flow and constraints.
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 a signed integrity claim (signed_payload and claim_sha256) as a third party, recomputing SHA-256 to check equality. It explicitly distinguishes from sibling verify_fair_price (opposite posture, no price layer) and mentions the issuing side (estimate-integrity-audit).
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 explicit guidance on when to use (independent verification, fail-closed posture) and contrasts with verify_fair_price, naming the alternative. It also specifies prerequisites: require signed_payload and claim_sha256 from the same response, and optional estimate_version to check scope. It clarifies when to omit estimate_version (scope_check skipped).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!
Sign in to create a connector for this server.