Agent intake desk for property renovation. Read only, CORS open, fail closed, receipts recompute.
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.6/5 across 5 of 5 tools scored.
The five tools are mostly distinct: intake_estimate handles specific quote verdicts, scan_tactics returns overcharge methods, draft_broadcast generates social media drafts, run_full_audit orchestrates all three, and route_request is a general router. The overlap between route_request and the others is somewhat unclear, as route_request seems to subsume all functions via keyword routing, which could confuse an agent about which tool to call for a direct action.
Names follow a reasonably consistent verb_noun pattern with clear action words: draft_broadcast, intake_estimate, scan_tactics, run_full_audit, and route_request. The mix of 'draft', 'intake', 'scan', 'run', and 'route' is not uniform but each communicates its role. The only minor deviation is that 'run_full_audit' is a composite verb while others are single verbs.
With exactly 5 tools, the set is well-scoped for a specialized audit service. Each tool covers a clear workflow step (intake, tactics research, broadcast drafting, orchestration, and general routing) without redundancy. The count is neither too few (each has a distinct job) nor too many (no tool bloat). This feels appropriate for the domain.
The tool surface covers the core lifecycle: receiving estimates (intake_estimate), analyzing overcharge tactics (scan_tactics), generating alerts (draft_broadcast), and a general router (route_request) plus orchestrator (run_full_audit). A minor gap is the lack of a dedicated tool for verifying past audits or managing user data. However, the key use cases are covered, and agents can use route_request as a fallback for unhandled requests.
draft_broadcast注意喚起の発信下書きAある工事の過剰請求への注意喚起を発信する下書き(note用長文・X用短文)を生成し、HORIZON SHIELDの該当解説ページ(実在URL)への被リンクを添える。価格はKIRA(検証可能SHA-256付き)の一次データのみ。推測の数字は入れない。下書きであり公開前に運営者が最終版にする(自動投稿しない)。 / Generates broadcast DRAFTS with backlinks. Verifiable first-party prices only. Draft; operator finalizes. No auto-posting. USE WHEN: the operator wants note/X draft text warning about overcharging for a given work type. DO NOT USE WHEN: the caller wants a verdict on a specific quote (call intake_estimate) or the tactic list itself (call scan_tactics). Output is a DRAFT for a human to finalise. This tool never posts.
| Name | Required | Description | Default |
|---|---|---|---|
| work | Yes | 工事名やキーワード(日本語)。例: 外壁塗装, トイレ, 火災保険 |
| Name | Required | Description |
|---|---|---|
| ok | Yes | Whether a draft was produced. |
| notice | No | This is a DRAFT. A human finalises it. Nothing is posted. |
| source | No | Which server produced this. |
| post_targets | No | Per-channel draft text (note long form, X short form) with backlinks. |
| price_source | No | Which first-party data any figure in the draft came from. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the bar is lowered. The description adds valuable context: drafts are for operator finalization, no auto-posting, only KIRA-verified prices are used, and speculation is forbidden. No contradictions found.
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 with a Japanese/English bilingual summary, followed by clear usage guidelines. Every sentence serves a purpose: stating output, constraints, and exclusions. 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 the tool has one required parameter, an output schema, and clear annotations, the description covers all necessary context: when to use, when not to use, what the draft contains, and behavioral guarantees. It is fully adequate for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema describes the 'work' parameter as a Japanese work name/keyword with examples. The description adds context by explaining the purpose of this parameter in generating warnings about overcharging, but does not extensively elaborate beyond what the schema already conveys.
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 generates broadcast drafts (note/X) with backlinks using verifiable first-party prices only. It clearly distinguishes itself from siblings like intake_estimate and scan_ttactics by specifying it does not post automatically and only produces drafts.
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 'USE WHEN' for warning about overcharging and 'DO NOT USE WHEN' for verdict on quotes or tactic lists, naming sibling tools as alternatives. This provides clear guidance on when to choose this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
intake_estimate見積もり適正診断(KIRA)A施主の建設・リフォーム見積もりを受け付け、HORIZON SHIELD KIRA(内部・中立)の適正価格診断へ橋渡しする集客窓口。工事名と業者提示額を渡すと、適正かどうかの判定と、無料の第三者チェック(EHN)への導線を返す。価格の断定はせず、確認すべき点を渡す。 / Intake desk: bridges a homeowner quote to the KIRA fair-price audit and returns the verdict plus a free third-party check (EHN) path. USE WHEN: a homeowner has a specific quoted price for a named construction or renovation work item in Japan and wants to know whether that price is reasonable. DO NOT USE WHEN: there is no price yet (call ask), the caller wants the known overcharge tactics rather than a verdict on their own quote (call scan_tactics), or the caller wants publishable text (call draft_broadcast). Returns a verdict and a free third-party check path. It does not draft or post.
| Name | Required | Description | Default |
|---|---|---|---|
| work | Yes | 工事名(日本語)。例: 外壁塗装 シリコン | |
| quoted_price | Yes | 業者提示の金額(円) |
| Name | Required | Description |
|---|---|---|
| ok | Yes | Whether the quote was accepted for audit. |
| next | No | Suggested follow-up tools or paths, including the free third-party check. |
| audit | No | The fair-price verdict from the internal KIRA audit. |
| source | No | Which server produced this. |
| message | No | Reason when ok is false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is clear. The description adds behavioral context: it returns a verdict and a free third-party check path, does not assert price definitively, and does not draft or post. This provides useful nuance beyond the annotations, though it does not discuss response formats or rate limits.
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: a concise purpose statement in both Japanese and English, followed by explicit usage guidelines and a clear statement of what it returns and does not do. It is slightly verbose due to bilingual repetition, but every sentence adds value and the critical information is front-loaded.
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 tool with only two required parameters and an output schema, the description covers all necessary context: the tool's purpose, exact input requirements, usage boundaries, and behavioral constraints (no drafting, no price finality). The presence of an output schema means the return structure does not need to be elaborated in the description.
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% (both work and quoted_price have detailed descriptions). The description re-emphasizes that work is a named construction item in Japan and quoted_price is the contractor's quoted amount, but adds minimal new semantic information beyond the schema. Baseline 3 is appropriate as the schema already handles parameter documentation.
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 role as an intake desk that accepts a homeowner's quote (work name and price) and returns a fairness verdict plus a path to a third-party check. It uses specific verbs ('bridges', 'returns') and resource ('KIRA fair-price audit'). It distinguishes from siblings by explicitly naming alternatives (ask, scan_tactics, draft_broadcast) in the DO NOT USE section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit USE WHEN and DO NOT USE conditions: use when a homeowner has a specific quoted price for a named construction item in Japan; avoid when no price yet (call ask), when wanting overcharge tactics (call scan_tactics), or when wanting publishable text (call draft_broadcast). Also notes it does not draft or post, which helps the agent rule out incorrect usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
route_request一文で聞けば、正しい窓口に繋ぐACheck whether a construction or renovation quote in JAPAN is fairly priced, against 65,520 open catalogue items and Bitcoin-anchored verification records. Single entry point: pass one sentence. USE WHEN: the user has a quote or a price for building/renovation work in Japan and wants to know if it is reasonable; or wants to check a HORIZON SHIELD receipt or a jidec: citation; or asks about overcharging tactics used by contractors; or is looking for a verified contractor. DO NOT USE WHEN: the work is outside Japan; the question is not about construction or renovation; the user has already signed or paid and needs consumer-protection help; or there is an active emergency (gas smell, collapse, water not stopping). In those cases this tool does not answer - it returns the appropriate outside destination instead, and says so. Every reply carries verify (a URL that checks the answer) and limits (what the answer does NOT prove). Routing is a deterministic keyword table, not an LLM, so the same input always routes the same way. Examples: "is 800,000 yen high for exterior wall painting?" / "is jidec:entry:9 genuine?" / "how do I refuse a door-to-door sales pitch?" 日本の建設・リフォーム見積もりが適正かを確認する単一入口。日本語の一文で渡してよい。適正診断・台帳(JIDEC)の記録検証・過剰請求の手口・検証済み加盟店の4方向へ決定的に振り分ける。日本国外/建設以外/契約後の紛争/緊急時は**答えずに適切な外部の窓口を返す。**返り値には必ず verify(検証URL)と limits(証明していないこと)が入る。
| Name | Required | Description | Default |
|---|---|---|---|
| ask | No | やりたいことを一文で。例:「外壁塗装80万は高いですか」「jidec:entry:9 は本物ですか」 | |
| ref | No | (任意)検証したい引用ID。jidec:entry:N / 64桁hex / エントリ番号 | |
| work | No | (任意)工事名。分かっているなら渡すと推測を挟まない。 | |
| amount | No | (任意)業者提示の金額(円) |
| Name | Required | Description |
|---|---|---|
| ok | Yes | Whether the request was handled. |
| next | No | Tool names to call next. |
| limits | No | What this answer does NOT prove. Always present. |
| result | No | The answering desk's payload. |
| verify | No | URL where the caller can recompute and check the claim. |
| message | No | Reason when ok is false. |
| routed_out | No | True when the question was routed to an external desk rather than answered here. |
| answered_by | No | Which desk answered: the router itself, an internal audit, the ledger, or a guide fallback. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the bar is lower. The description adds valuable behavioral context: 'Routing is a deterministic keyword table, not an LLM, so the same input always routes the same way' and 'Every reply carries verify (a URL that checks the answer) and limits (what the answer does NOT prove)' plus out-of-scope behavior. 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 with bold USE WHEN/DO NOT USE WHEN sections, a clear behavior sentence, and a Japanese summary. It is longer than minimal, but the length is justified for a router with complex routing logic and four routing destinations. Minor redundancy between English and Japanese sections keeps it from a 5, but it is front-loaded and organized.
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 tool with four routing destinations, out-of-scope handling, deterministic behavior, and a verify/limits envelope, the description covers all necessary aspects. An output schema exists (per context signals), so return values are not required, but the description still mentions verify and limits. The 100% schema coverage and clear annotations complete the picture, making it fully self-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?
Schema description coverage is 100%, so the baseline is 3. The description mentions 'pass one sentence' and gives examples, but does not substantially add to the schema's parameter descriptions. The schema already explains `ask`, `ref`, `work`, and `amount` with Japanese examples, so the description adds marginal value beyond what structured fields provide.
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: 'Check whether a construction or renovation quote in JAPAN is fairly priced' and identifies it as a 'single entry point' that routes requests. It distinguishes from siblings by covering multiple routing destinations (fair price check, JIDEC record verification, overcharging tactics, contractor lookup) and being deterministic. The verb+resource+scope is 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?
Explicitly provides USE WHEN and DO NOT USE WHEN lists, including concrete exclusions (outside Japan, non-construction topics, already-signed consumer protection matters, active emergencies). It states that in excluded cases the tool 'returns the appropriate outside destination instead' and says so, giving clear guidance for 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.
run_full_audit集客→診断→発信 一括実行A1回の呼び出しで HORIZON SHIELD の集客→診断→注意喚起→発信を一気通貫で回す司令塔。work(と任意の quoted_price)を渡すと、内部で intake(KIRA適正診断)・scan_tactics(検証済み手口+一次ソース)・draft_broadcast(発信下書き+被リンク)を順に実行し、結果を1つに束ねて返す。価格は検証可能な一次データのみ。発信は下書きで自動投稿しない。 / One-call orchestrator returning audit + tactics + broadcast draft. Verifiable first-party prices only. Drafts only, no auto-posting. USE WHEN: the caller wants all three steps (audit, tactics, broadcast draft) for one named work item in a single call and will act on the combined result. DO NOT USE WHEN: only one step is needed. Call intake_estimate for a verdict on a specific quote, scan_tactics for the documented overcharge tactics, or draft_broadcast for publishable text. If the request is still a free-form question with no work item, call ask first. This tool never posts anything.
| Name | Required | Description | Default |
|---|---|---|---|
| work | Yes | 工事名やキーワード(日本語)。例: 外壁塗装, トイレ, シロアリ | |
| quoted_price | No | (任意)業者提示の金額(円)。あればKIRA適正診断も実行する。 |
| Name | Required | Description |
|---|---|---|
| ok | Yes | Whether the flow ran. |
| flow | No | The fixed step order that was executed. |
| work | No | The work item the flow was run for. |
| steps | No | One entry per step: intake, scan_tactics, draft_broadcast. A step may be skipped or fail without failing the flow. |
| notice | No | Standing caveat: first-party prices only, drafts only, no auto-posting. |
| source | No | Which server produced this. |
| message | No | Reason when ok is false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds behavioral context: it executes three internal tools in sequence, only uses verifiable first-party prices, and never auto-posts. No contradiction with annotations; it supplements them with operational details like the draft-only constraint.
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 with a clear summary, then USE WHEN/DO NOT USE WHEN sections. It is somewhat lengthy due to bilingual repetition, but every sentence serves a purpose and the key points are front-loaded. Minor redundancy from the Japanese/English duplication 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?
For a complex orchestrator with an output schema present, the description covers the workflow sequence, data constraints (first-party prices), and behavioral guarantee (no auto-posting). It also clarifies the prerequisite of having a named work item, making the tool fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described. The description adds workflow semantics by explaining that 'work' triggers the intake/scan/draft chain and that passing 'quoted_price' activates the KIRA diagnosis. This goes slightly beyond the schema's individual descriptions, earning a 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 it is a 'One-call orchestrator returning audit + tactics + broadcast draft' and '司令塔' that runs the full intake→scan→draft sequence. It clearly distinguishes from sibling tools by emphasizing the combined execution of all steps and explicitly notes it never posts.
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 explicit 'USE WHEN' and 'DO NOT USE WHEN' conditions, names alternative tools (intake_estimate, scan_tactics, draft_broadcast, ask) for single-step or free-form needs, and clearly states the orchestrator is for when all three steps are needed. This is exemplary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
scan_tactics過剰請求の手口スキャンAある工事・キーワードに関する『過剰請求の手口』を、HORIZON SHIELD(大賀俊勝30年監修)の検証済みデータ(内部KIRA)から返し、一次ソース(国民生活センター/消費者庁/EHN実例ボード)の在処を添える。価格判定ではなく注意喚起。推測で新事例を断定しない。 / Returns verified overcharge tactics and points to primary sources. Awareness, not a price verdict. USE WHEN: the caller wants the documented overcharge tactics for a work type or keyword, together with their primary sources. DO NOT USE WHEN: the caller has their own quote and wants a verdict on it (call intake_estimate), or wants publishable text (call draft_broadcast). This returns awareness material and never a price verdict on a specific quote.
| Name | Required | Description | Default |
|---|---|---|---|
| work | Yes | 工事名やキーワード(日本語)。例: 外壁塗装, シロアリ, 火災保険 |
| Name | Required | Description |
|---|---|---|
| ok | Yes | Whether tactics were found. |
| source | No | Which server produced this. |
| scan_mode | No | How the set was assembled. |
| disclaimer | No | Awareness material. Not a price verdict on any specific quote. |
| primary_sources | No | Where each tactic is documented publicly. |
| verified_tactics | No | Documented overcharge tactics for the work type. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the agent knows it is safe and idempotent. The description adds value by stating that results are from verified data (KIRA), returns primary sources, and that the tool does not make price verdicts or invent new cases. The description aligns with and complements 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 concise—only 3 sentences in English plus a brief usage section. Every sentence adds value: the first states what it does and returns; the second clarifies it is awareness only; the third warns against using it for inferences. 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 a single required parameter with 100% schema coverage, a detailed output schema (not shown but present), and strong usage guidance, the description is complete. It covers purpose, inputs, returns, limitations, and alternatives. No gaps remain.
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% and the description already provides a clear example ('外壁塗装, シロアリ, 火災保険') for the single parameter. The description does not add additional constraints or format details beyond the schema example, but the combination is sufficient for the agent.
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 specific verbs ('returns', 'points to') and a clear resource (verified overcharge tactics with primary sources). It clearly distinguishes from siblings by stating what the tool does not do: it is for awareness, not a price verdict, and explicitly differentiates from 'intake_estimate' and 'draft_broadcast'.
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 explicit 'USE WHEN' and 'DO NOT USE WHEN' sections that name alternative tools ('intake_estimate', 'draft_broadcast') and clarify the tool's scope—documented tactics with sources, not price judgment. This provides clear contextual guidance beyond just purpose.
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.