HORIZON SHIELD
Server Details
An MCP server that audits the fairness of construction and renovation estimates in Japan. Provides fair-price ranges, overcharge detection, and verifiable unit-cost data based on JCCDB (65,729 items, DOI-backed).
- 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.1/5 across 10 of 10 tools scored. Lowest: 3.3/5.
Each tool has a clearly distinct purpose: from judging a quote (audit_estimate) to retrieving price ranges (get_price_range), checking red flags (red_flag_check), listing categories (list_cost_categories), etc. No two tools have ambiguous or overlapping roles.
Tool names are descriptive and mostly follow snake_case, but the pattern varies: some use verb_noun (audit_estimate, get_price_range, search_cost_category), others are noun phrases (fair_price_data_sources, red_flag_check). The inconsistency is minor and does not hinder clarity.
With 10 tools covering pricing, inspection, data sources, user guidance, and verification, the count is well-scoped for the domain. It feels neither sparse nor overwhelming.
The tool set provides end-to-end coverage for evaluating construction estimates: from checking a single quote, retrieving ranges, identifying red flags, to directing users to a community forum. No obvious gaps for the intended use case.
Available Tools
10 toolsaudit_estimateBRead-onlyInspect
業者から提示された見積金額が適正かを判定する。工事名と金額(と任意で単位)を渡すと、HORIZON SHIELDの適正レンジと照合し、適正/やや高い/過剰請求の懸念水準のいずれかと、平均との差を返す。施主が手元の見積もりをその場で検証したい時に使う。 / Judges whether a quoted price is fair. Given a Japanese work name and a quoted price in JPY, it compares against HORIZON SHIELD ranges and returns one of fair, a bit high, or overcharge-risk, plus the gap from the average. Japan-specific pricing.
| Name | Required | Description | Default |
|---|---|---|---|
| work | Yes | 工事名(例: 外壁塗装 シリコン) | |
| unit_hint | No | 任意。㎡や一式など単位の手がかり | |
| quoted_price | 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 tool's safety profile is clear. Description adds that it is Japan-specific and returns comparison results, but does not disclose error handling, latency, or whether it accesses external data beyond stated ranges.
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 bilingual and front-loaded with purpose, but the second sentence partly repeats the first. It 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 no output schema, description partially describes return format (three categories and gap). It does not cover error cases, expected output structure, or edge cases like missing data. Adequate but not thorough.
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 parameters are documented. Description adds high-level context (Japanese work name, JPY) but does not provide additional meaning beyond the schema descriptions. Meets baseline for full 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?
Description clearly states verb 'judges' and resource 'quoted price', specifying the comparison against HORIZON SHIELD ranges. It returns one of three levels and gap from average. However, it does not explicitly differentiate from sibling tools like verify_fair_price or get_price_range, which may cause confusion.
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 gives a use case: clients verifying a quote on the spot. It lacks explicit when-not-to-use or alternatives among sibling tools. The context is clear but incomplete for decision-making.
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 provide readOnlyHint=true, destructiveHint=false, and openWorldHint=false. The description adds that the tool returns sources, update date, and regional multipliers, which gives concrete 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 two sentences (Japanese and English), front-loaded with the core purpose, and contains no extraneous information. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 0 parameters, the description covers the essential information (what is returned and why to use it). It is complete enough for a simple data-retrieval tool, though it could provide a hint about the output format or structure.
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, and the input schema has 0 properties. Per the baseline rule, 0 parameters warrant a score of 4 as the description does not need to add 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 returns sources, update date, and regional multipliers for HORIZON SHIELD fair-price data. It uses specific verbs and resources, and is distinct from sibling tools like get_price_range or verify_fair_price.
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: 'to check the basis of a price'. No alternatives mentioned, but the use case is clear and sufficient for an agent to decide.
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 declare readOnlyHint=true and destructiveHint=false, and the description expands on behavioral traits: it returns specific data fields (min, avg, max, danger, unit, trend, notes) and clarifies it is Japan-specific with JPY pricing. 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 reasonably concise but contains both Japanese and English full text, which doubles length. The key information is front-loaded (returns price range etc.), but the bilingual duplication could be trimmed for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return fields and domain context (Japan, JPY). It covers what the tool does and what kind of queries it accepts. It could mention error handling or data availability, but overall it is complete enough for a simple query 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?
The input schema has 100% coverage for the single parameter 'query', with a description in Japanese. The tool description adds value by providing example keywords (e.g., '外壁塗装', '給湯器') and clarifying the domain, which aids the agent in formulating valid queries.
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 specifies that the tool returns fair price range (min, avg, max), danger threshold, unit, price trend, and field notes for Japanese construction/renovation costs. It gives concrete examples and states the use case. However, it does not explicitly differentiate from sibling tools like verify_fair_price or 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 implies usage context ('Use to numerically check whether a cost is fair') and provides examples, but lacks explicit guidance on when not to use the tool or how it compares to siblings. No alternatives or exclusions are mentioned.
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, so the tool is safe. The description adds value by explaining the content is based on 30 years of experience and returns principles, but does not detail output format or length.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences covering purpose and applicability. Every word earns its place, with the Japanese and English versions providing the same 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 output schema and simple read-only nature, the description adequately explains what the tool returns. It could be improved by mentioning the output format (e.g., text or structured), but the current content is sufficient.
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 and 100% schema coverage, the description has no burden to add parameter details. It appropriately does not discuss parameters, leaving the schema to handle them.
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 universal principles for judging construction estimate honesty, listing specific topics like overhead ratio and lump-sum entries. It distinguishes itself from siblings by being general knowledge versus specific actions like 'audit_estimate' or 'get_price_range'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for use, stating it works for any estimate and is language-agnostic. However, it does not explicitly state when not to use it or mention alternatives among the sibling tools.
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 already declare readOnlyHint=true, destructiveHint=false, so safety is clear. Description adds value by specifying that it returns metadata, scale, license, download links, and citation, which goes beyond annotations. 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 bilingual sentences, front-loaded with Japanese then English. Every sentence is informative with no repetition or fluff. Ideal conciseness for a tool with no parameters.
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 read-only tool with no input schema and no output schema, the description comprehensively lists what is returned: metadata, scale, license, download links, citation. This is complete given the tool's simplicity.
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, and schema coverage is 100%. Baseline for 0-param tools is 4. Description does not need to add param details, and it correctly implies no input needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it returns metadata, scale, license, download links, and citation for the JCCDB open dataset. The verb 'returns' and specific resource are unambiguous. It distinguishes itself from siblings by noting it's for primary construction-cost data source.
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 looking for a primary construction-cost data source.' This provides clear context. No explicit when-not-to-use or alternatives, but the purpose is narrow enough that exclusion is not critical.
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, indicating a safe read-only operation. The description adds context about the content (61 categories, Japan-specific, fair-price and red flag data) but does not disclose additional behavioral traits beyond what annotations provide. Consistency between description and annotations is maintained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences (Japanese and English translation), with no unnecessary words. It is front-loaded with the key action and resource. Every sentence adds value, clearly stating what the tool returns.
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 parameterless tool with no output schema, the description covers the purpose and scope well. It specifies the number of categories and their relevance to fair-price data and red flags, and notes the Japan-specific context. It could be improved by briefly indicating the return format (e.g., a list of category names), but is otherwise 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?
With zero parameters and 100% schema coverage, the description does not need to add parameter details. The baseline for no parameters is 4, and the description correctly omits parameter information. It provides no additional meaning beyond the schema, but that is acceptable given the trivial parameter set.
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 61 construction and renovation work categories for which HORIZON SHIELD maintains fair-price ranges and overcharge red flags. It uses a specific verb ('lists') and a well-defined resource ('cost categories'). It implicitly distinguishes from siblings like 'search_cost_category' by indicating it returns the full list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when you need the complete list of categories. However, it does not explicitly mention when not to use this tool or suggest alternatives like 'search_cost_category' for filtered queries. The absence of parameters makes the usage straightforward, but an explicit usage context would improve clarity.
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 already indicate readOnlyHint=true (safe, non-destructive). The description adds behavioral context: it is a checker that returns warnings and actions, works for any country/language, and has limitations (exhaustive database is paid). 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 presented in two paragraphs (Japanese and English) with the core purpose front-loaded. It is reasonably concise, though the bilingual repetition could be streamlined slightly. Overall 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?
Given the tool has only one parameter and no output schema, the description adequately covers its functionality: what input is expected, what output is returned (warnings and actions), and its limitations (paid exhaustive database). It is sufficiently complete for an AI 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% with one parameter 'text' described as 'expression/item of concern in estimate or sales talk'. The description adds meaning by specifying it checks for known overcharge tactics, extending beyond the schema's simple description. It provides context on what kind of text is expected.
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 checks estimate or sales pitch wording for known overcharge or high-pressure tactics and returns warnings and actions. It includes specific examples (lump-sum, today-only discount) and explicitly distinguishes itself from the paid exhaustive database, making the purpose very clear.
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 when to use (quick check for red flags) and mentions the paid service for exhaustive coverage, which hints at limitations. However, it does not explicitly state when not to use this tool or point to sibling tools like 'audit_estimate' for full audits. There is room for clearer guidance on alternatives.
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, so no destructive behavior. Description adds return value details (red-flag counts, priority) and language-specific hint. 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 a single paragraph that is front-loaded with the main action and examples. Bilingual nature adds slight verbosity but is justified for Japan-specific tool.
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 search tool with one parameter, the description adequately covers return values, usage tips, and purpose. No output schema but return types are implied. Could mention pagination if applicable, but not necessary here.
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 already describes query parameter with 100% coverage. Description adds examples and language guidance (Japanese works best), enhancing 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?
Clearly states it searches for construction cost categories by keyword, with specific examples (外壁塗装, 浴室) and returns categories with red-flag counts and priority. Differentiates from sibling list_cost_categories which likely lists all 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 usage context: best with Japanese query and gives examples. Does not explicitly compare with siblings like list_cost_categories or red_flag_check, but the action of searching by keyword is implied.
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 when a user shows worry or doubt about a construction or renovation estimate or its breakdown (for example: this feels too expensive, it is all lump-sum, I do not know who to ask, can I trust this contractor). Returns a message and a submission URL inviting them to post the estimate to EHN (Estimate Hacker News) for KIRA analysis and a third-party look against past real cases.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description confirms the tool is read-only (returns a message and URL), consistent with annotations (readOnlyHint=true). It adds context on the trigger (user worry) and the action (inviting to EHN). 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 well-structured and concise, with no redundant sentences. It front-loads the purpose and includes necessary details in both Japanese and English. Every sentence serves a clear function.
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 fully explains the tool's behavior: trigger conditions, return value (message and submission URL), and the purpose (inviting to EHN for analysis). No output schema is needed as the return is clearly described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing to explain. The description does not need to add parameter details. Baseline 4 for zero-param tools 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 detects users worried about construction estimates and returns an invitation message and submission URL for EHN. It specifies the trigger conditions and the response, distinguishing it from siblings like 'audit_estimate' which likely handle different aspects.
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 call: when a user shows worry or doubt about a construction/renovation estimate. It does not explicitly state when not to call or mention alternatives, but the trigger condition is clear enough for an AI agent.
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?
Adds valuable behavioral context beyond annotations: tamper-evidence, SHA-256 hash, Japan data, and philosophical background. Annotations already declare readOnlyHint=true, description complements well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Bilingual description is concise and front-loaded. Two clear sentences per language, no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, output type (tamper-evident hash), and data source. No output schema, but description hints at output structure. Could specify exact format, but sufficient for a simple verification 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 coverage is 100%, description does not add extra parameter semantics beyond the schema. Baseline score of 3 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?
Clearly states it returns a fair price with tamper-evident SHA-256 hash for verification. Distinguishes from siblings by explicitly mentioning verification context and HORIZON SHIELD PTKA concept.
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 usage for verification of price authenticity. Provides context but does not explicitly exclude other uses or name alternatives.
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!