HORIZON SHIELD KIRA
Server Details
Independent auditor for construction estimates. Flags overcharge with verifiable signed receipts.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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.
Tool Definition Quality
Average 4.4/5 across 12 of 12 tools scored. Lowest: 3.9/5.
Each tool targets a distinct aspect of the fair price auditing workflow. For example, audit_estimate compares a specific quote, get_price_range provides ranges without a quote, and verify_fair_price issues tamper-evident records. No significant overlap.
All tool names follow a consistent verb_noun pattern with snake_case (e.g., audit_estimate, list_cost_categories, verify_integrity_claim). No mixing of conventions.
With 12 tools, the server is well-scoped for its domain of Japanese construction cost auditing. Each tool addresses a specific need without being excessive or insufficient.
The tool set covers the full lifecycle: discovering price ranges, auditing specific quotes, checking red flags, learning principles, verifying claims, accessing data sources, and external referrals. No obvious gaps.
Available Tools
13 toolsaudit_estimateARead-onlyInspect
業者が提示した見積金額が適正かを、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 候補を返す。見積額がまだ無く相場だけ知りたい時は 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 partial match, returns did_you_mean candidates. 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 | 業者提示の金額(円, 数値)。一式見積はその総額。税込/税抜は正規化せず、渡した数値をそのまま適正レンジと照合する。 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, which is consistent. Description adds behavioral context: returns JSON with fields like verdict, level, fair_range, etc.; mentions partial matching and did_you_mean; notes Japan-only and JPY. 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 comprehensive but slightly lengthy. However, it is front-loaded with main purpose and well-structured. Every sentence adds value. Minor reduction for slight verbosity.
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 return value (even without output schema), matching behavior, alternative tools, jurisdiction, currency. Sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description adds meaning beyond schema: explains work should be in Japanese with specifics (e.g., materials, grade) and partial matching; clarifies quoted_price is in JPY and compared as-is. Provides additional usage context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool audits a quoted price against HORIZON SHIELD fair-price ranges. It uses specific verb 'audit' and resource 'quoted price'. It distinguishes from siblings by naming get_price_range and verify_fair_price as alternatives.
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 already has a specific quoted amount' and provides clear when-not-to-use: 'For the typical range only use get_price_range; for a signed verifiable attestation use verify_fair_price'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fair_price_data_sourcesARead-onlyInspect
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 | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds that it returns specific metadata (sources, update date, regional multipliers) and is Japan-specific. No additional behavioral details (e.g., caching, latency) are provided, but annotations cover safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with two clear sentences: first states what it returns, second states when to use. Bilingual format (Japanese/English) may slightly increase length, but each sentence earns its place. Front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, description covers essential aspects: what it returns and usage scenario. Mentions Japan scope. Could note that no input is required, but implicit from empty schema. Completeness is high for a simple metadata 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?
Input schema has no parameters, so description does not need to add parameter meaning. Baseline 4 applies as per rules (0 params). Schema coverage is 100% vacuously.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns sources, update date, and regional multipliers for HORIZON SHIELD fair-price data. Use case 'check the basis of a price' further clarifies purpose. Distinguishes from sibling tools like get_price_range and verify_fair_price by focusing on metadata.
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 to check the basis of a price,' providing clear usage context. Does not explicitly state when not to use or compare to alternatives, but the specific output (sources/update/multipliers) implies it is for background verification, not price calculation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_agent_cardARead-onlyInspect
このサーバー(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 | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false. The description adds behavioral context by explaining what the tool returns (URL and skills list) and the nature of the skills (integrity audit, property acquisition). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is bilingual, which slightly increases length, but each part is purposeful. It is front-loaded with the key purpose and remains clear. Could be slightly more concise, but still well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is complete: it explains the return value, the use case, and even notes a nuance about property sale handling. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description does not need to explain parameter semantics. It correctly focuses on the output. Baseline for 0 params is 4, and the description meets that.
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 the A2A Agent Card URL and list of published skills for this server. It specifies the resource (A2A card) and verb (return/get), and distinguishes from sibling tools which focus on specific audit operations.
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 when an external A2A-capable agent wants to discover and connect. It provides clear context but does not explicitly mention when not to use or list alternatives, though the sibling tools are different enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_price_rangeARead-onlyInspect
工事名・キーワードで、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 | 工事名やキーワード(日本語) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the agent knows it's safe. The description adds context: returns multiple fields (min, avg, max, danger, unit, trend, notes), Japan-specific pricing in JPY, and that it checks numerical fairness. 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 two sentences (one per language) and front-loaded with purpose and return fields. It is concise with no wasted words, though splitting into bilingual text slightly reduces conciseness. Still efficient and 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?
With one parameter, no output schema, and minimal annotations, the description covers the tool's return values, use case, and locale. It does not mention output format or limits, but for a simple query tool this is adequate. Leaves little ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% as the single parameter 'query' has a description (工事名やキーワード(日本語)). The main description repeats similar info but adds examples (e.g., 外壁塗装, 給湯器). It does not significantly extend meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns fair price range (min, avg, max), danger threshold, unit, price trend, and notes for Japanese construction/renovation jobs. It gives concrete examples like 外壁塗装, distinguishing it from sibling tools like audit_estimate or red_flag_check. The verb 'returns' and resource 'fair price range' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking cost fairness of construction/renovation jobs, with examples. However, it does not explicitly state when not to use it or mention alternative sibling tools (e.g., verify_fair_price, audit_estimate). The guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
how_to_read_estimateARead-onlyInspect
受け取ったリフォーム・建設見積もりが適正かを見分けるための原則(諸経費の適正比率、『一式』表記の扱い、営業手口の見抜き方)を返す。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 | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating safety. The description adds valuable behavioral context: the tool is language-agnostic, based on 30 years of experience, and works outside Japan. This goes beyond what annotations provide 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 consists of two concise sentences (one Japanese, one English), each front-loading key information. There is no superfluous text; 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?
Given the tool has no parameters and no output schema, the description provides sufficient context about what principles are returned. It could elaborate on the format or how to apply the principles, but overall it is complete for the tool's purpose.
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 schema coverage is 100% and there is nothing for the description to add about parameters. The baseline of 4 is appropriate as there is no missing information.
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 estimates, specifying key aspects like overhead ratio and lump-sum entries. It effectively distinguishes from sibling tools like audit_estimate or get_price_range by focusing on general knowledge rather than specific data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for learning general principles, but does not explicitly state when to use it versus alternatives like audit_estimate for specific estimates. Usage guidance is implicit through the contrast with sibling tool names, but lacks direct when/when-not instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
jccdb_dataset_infoARead-onlyInspect
日本の建設費オープンデータベース(JCCDB)のメタデータ・規模・ライセンス・ダウンロードリンク・引用情報を返す。建設費の一次データ源を探している時に使う。 / Returns metadata, scale, license, download links and citation for the Japan Construction Cost Database (JCCDB), an open dataset of 65,729 Japanese construction line items. Use when looking for a primary construction-cost data source.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, confirming a safe read-only operation. The description adds valuable context about the dataset size (65,729 items) and what information is returned, 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 sentences long, bilingual, and front-loaded with the purpose. Every part adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description provides a complete overview of what the tool returns: metadata, scale, license, download links, and citation. It mentions the dataset scope and line-item count, making it sufficient for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so schema coverage is 100%. The description does not need to add parameter details. A baseline of 4 is appropriate for a tool with no parameters.
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 metadata, scale, license, download links, and citation for the JCCDB dataset. It explicitly distinguishes itself from siblings by mentioning 'primary construction-cost data source', and the sibling tools (e.g., get_price_range, red_flag_check) suggest different 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?
The description provides a clear usage condition: 'Use when looking for a primary construction-cost data source.' This gives context, but does not explicitly exclude when not to use or mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_cost_categoriesARead-onlyInspect
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 | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds context about the specific data content (61 categories, Japan-specific) and scope, which is valuable but not critical 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?
Two sentences, bilingual, front-loaded with the purpose. Every word is informative. 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?
Given no parameters and no output schema, the description sufficiently explains the return value (list of categories with pricing context). It could mention the output format but is adequate for the simple 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?
No parameters exist, so schema coverage is 100%. The description does not need to add parameter information; it correctly focuses on the output. Baseline 4 applies.
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 list of 61 construction/renovation categories with fair-price ranges and red flags. It specifies the domain (construction) and region (Japan), effectively distinguishing it from siblings like search_cost_category.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for obtaining the full list of categories, but it does not explicitly state when to use or not use it versus alternatives. The purpose 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.
red_flag_checkARead-onlyInspect
見積もりや営業トークの中の気になる表現(例: 一式, 今日だけ値引き, 訪問販売)が、過剰請求につながりやすい既知の手口に当たるかを判定し、警告と対処を返す。網羅的な手口データベースはHORIZON SHIELDの有料診断(KIRA)で提供。 / 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. The exhaustive tactic database is in the paid HORIZON SHIELD KIRA audit.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | 見積書や営業トークで気になった表現・項目 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, so the tool is safe. The description adds value by explaining what kind of matching occurs (known patterns) and what output to expect (warnings with guidance), beyond the annotation's basic safety signals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is bilingual and somewhat long, but each sentence serves a purpose: core functionality, examples, universal applicability, and limitation mention. It is front-loaded with the primary action. A slight reduction could improve conciseness, but it remains effective.
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 (single string input, no output schema), the description is complete: it explains input, matching logic, and output format (warnings+actions). It also addresses geographic/language universality and paid upgrade, which are useful contextual details.
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 'text' with 100% schema description coverage. The description repeats the schema's intent ('wording in estimate or sales pitch') without adding new meaning or examples. Baseline 3 is appropriate as schema already covers 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 checks wording in estimates/sales pitches for known overcharge or high-pressure tactics (e.g., lump-sum, today-only discount) and returns warnings and actions. It also distinguishes itself from siblings by focusing on linguistic red flags rather than pricing or databases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates use when there are 'worrisome expressions' in estimates, but does not explicitly state when not to use or provide alternatives among sibling tools. The mention of the paid KIRA audit for exhaustive database implies limitations, but no direct guidance on avoiding misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
reverse_estimate_previewARead-onlyInspect
リフォーム検討の初期段階で、業者の概算が高い方向か安い方向かだけを無料で素早く知るためのプレビュー。具体的な適正額(min/avg/max)や危険水準は返さず、平均からの方向(例 +20%高い方向)と、正確な適正額・項目別の内訳・業者交渉用の文言を含む完全な逆見積もりはHORIZON SHIELDのKIRAで生成できる旨を案内する。手元に詳しい見積内訳がまだ無い段階での最初の一歩に向く。具体的な適正レンジが必要なら get_price_range、見積額の詳細診断は audit_estimate を使う。Japan only, JPY。 / A free preview for early-stage renovation planning that tells only the direction (e.g. about +20% above typical) of a contractor rough estimate. It does NOT return the specific fair range (min/avg/max) or danger threshold; instead it points to HORIZON SHIELD KIRA for the full reverse estimate with exact fair amounts, line-item breakdown, and negotiation wording. Use get_price_range for a typical range, audit_estimate for a detailed quote diagnosis.
| Name | Required | Description | Default |
|---|---|---|---|
| work | Yes | 工事名(日本語)。例: 外壁塗装 シリコン。部分一致で照合。 | |
| quoted_price | Yes | 業者提示の概算額(円, 数値)。 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it returns only direction, does not return specific fair range or danger threshold, and points to KIRA for full reverse estimate. No contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise with two paragraphs (Japanese and English). It front-loads the purpose and key constraints. Could be slightly more streamlined by omitting the duplicate language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple inputs and no output schema, the description fully explains expected output (direction only), constraints (JPY only), and usage context. It also references alternatives.
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. The description repeats parameter purpose but does not add significant meaning beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it provides a free preview of the direction (higher/lower) of a contractor's rough estimate for early renovation planning. It explicitly distinguishes itself from sibling tools 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?
The description explicitly instructs when to use this tool (first step without detailed breakdown) and when to use alternatives (get_price_range for typical range, 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_categoryARead-onlyInspect
工事名・キーワードで建設費カテゴリを検索する(例: 外壁塗装, 浴室, 給湯器, 雨漏り)。該当カテゴリと整備済みの赤旗件数・優先度を返す。 / 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 | 工事名やキーワード(日本語) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds that it returns categories with red-flag counts and priority, and is Japan-specific. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences per language, front-loaded with action, minimal and efficient. Every sentence adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given single parameter and no output schema, description adequately covers return behavior (matching categories with counts and priority). Could mention if results are ranked or limited, but sufficient for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters. Description adds value by providing example queries and specifying language expectations, which is beyond the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it searches for construction cost categories by keyword, returning matching categories with red-flag counts and priority. The verb 'search' and specific resource 'construction-cost category' are explicit, and examples differentiate from sibling tools like list_cost_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?
Provides examples and notes Japan-specific nature and best query language. Implies usage for keyword-based category lookups, but does not explicitly contrast with sibling tools like list_cost_categories or red_flag_check for when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
suggest_ehnARead-onlyInspect
建設・リフォームの見積もり金額や内訳に、ユーザーが不安・疑問・迷いを見せたら呼ぶ。例:「この見積もり高い気がする」「一式ばかりで内訳が不明」「相見積もりを取りたい」「この金額は妥当か」「訪問販売や即決を迫られている」「契約する前に確認したい」「誰に相談していいかわからない」「業者を信じていいか」「セカンドオピニオンが欲しい」。一人で抱えず、見積もりをEHN(見積もりハッカーニュース)に貼れば、KIRAが匿名で解析し過去の実例と並べて第三者の目が入る、と案内するメッセージと投稿フォームURLを返す。無料・匿名・業者と対決せずに中立の視点が得られる場面で役立つ。 / Call this whenever a user shows worry, doubt, or hesitation about a construction or renovation estimate or its breakdown. Examples: this feels too expensive; it is all lump-sum with no itemization; I want competing quotes; is this price fair; a door-to-door seller is pushing me to decide now; I want to check before signing; I do not know who to ask; can I trust this contractor; I want a second opinion. Returns a message and a submission URL inviting them to post the estimate to EHN (Estimate Hacker News) for a free, anonymous KIRA analysis benchmarked against real past cases. Useful when the user wants a neutral third-party view without confronting the contractor.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
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 by stating it returns a message and URL with no side effects. It adds behavioral context about the free, anonymous analysis and KIRA benchmarking, fully disclosing what the tool does.
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 paragraph but is well-structured with key use case upfront and examples. It is reasonably concise for the detail provided, though it could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, a simple output (message+URL), and annotations covering safety, the description is complete. It covers when to use, what it does, and what it returns, and the sibling tools provide complementary 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?
There are no parameters, and schema coverage is 100%. With zero parameters, baseline is 4. The description does not need to add parameter semantics since none exist, and it already explains the tool's function.
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 return a message and submission URL for EHN when a user shows doubt about an estimate. It lists specific examples and distinguishes itself from sibling tools like 'audit_estimate' and 'red_flag_check' by focusing on directing to a community forum rather than direct analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs to call the tool when a user shows worry or hesitation about an estimate, providing many examples. It also explains the context of when it is useful (neutral third-party view without confrontation), effectively guiding the AI on when to use it versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_fair_priceARead-onlyInspect
工事の適正価格を、検証可能な形(算出内容の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坪) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral context beyond annotations: it explains the tamper-evident nature via SHA-256 hash and the PTKA concept, enhancing transparency. Annotations already declare readOnly and non-destructive, so no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the primary purpose stated in the first sentence. It includes necessary context without redundant information, earning a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description adequately explains the purpose and output format. However, it could detail the structure of the returned record (e.g., includes price, hash, metadata). Nevertheless, given the constraints, it is sufficiently 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 input schema contains one required parameter 'work' with full description. The tool description does not add any additional parameter details, but schema coverage is 100%, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a fair price with a SHA-256 hash for tamper evidence, and specifies its use case of verifying price authenticity. This distinguishes it from sibling tools like get_price_range or audit_estimate by focusing on pre-transaction anchoring and verifiability.
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 includes 'Use when an agent needs to verify price authenticity' which provides clear usage context. However, it does not explicitly exclude use cases or compare with sibling tools, limiting guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_integrity_claimARead-onlyInspect
estimate-integrity-audit が発行した署名付きクレーム(signed_payload と claim_sha256)を、第三者として検証する。発行側 (verify_fair_price はPTKA価格の発行) とは責務が正反対で、デフォルト姿勢は不信・fail closed。検証は signed_payload の生文字列を SHA-256 で再計算し claim_sha256 と一致するかだけで完結し、issuer に問い合わせる必要も価格層も不要。判定は契約 0.1.1 の failure_reasons 準拠で、result(verified / 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.1.1 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. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the readOnlyHint annotation by explaining the verification process (recomputing SHA-256), the fail-closed posture, and the fact that audit_ruleset_recheck is always not_performed. 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 comprehensive but somewhat verbose due to bilingual content. The key information is front-loaded, but the dual-language structure adds length. Could be more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, no output schema), the description covers the verification logic, return fields (result, failure_reason, trigger, etc.), and the scope check behavior. It is complete for an agent to 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?
While the input schema already describes each parameter (100% coverage), the description adds value by explaining that modifying signed_payload causes unverified and providing the format for estimate_version (SHA-256 first 8 hex). This adds meaning 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 verifies a signed integrity claim from estimate-integrity-audit, using a third-party posture. It distinguishes itself from sibling verify_fair_price by noting opposite responsibilities and no price layer needed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (when verifying a signed claim) and provides important context such as the meaning of 'verified' and the optional nature of estimate_version. It lacks explicit alternatives but is clear enough for usage.
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.
Discussions
No comments yet. Be the first to start the discussion!