Skip to main content
Glama

HORIZON SHIELD YAKUMO (verified contractor directory)

by io.github.ogasurfproject-jpg

名指しの業者を照会

check_named_contractor
Read-onlyIdempotent

施主が名前を挙げた業者について答える。Yakumoの加盟店ならその測定結果を返す。加盟していない場合、その会社の良し悪しは一切判定せず、『Yakumoは測っていない』という事実だけを返し、施主が自分で確かめられる公的な照会先(国土交通省の建設業者検索・国民生活センター・住まいるダイヤル)と、同条件の検証済み加盟店を返す。掲載が無いことはその会社への評価ではない。金額は返さない。紹介料なし。Japan only。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
areaNo(任意)地域。代わりの検証済み店を探すのに使う
workNo(任意)工種。代わりの検証済み店を探すのに使う
companyYes施主が名前を挙げた業者名(日本語)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
roster_readNotrue = the contractor roster was read successfully; any counts below are real facts about the roster. false = the roster could NOT be read, and this response makes no claim about how many contractors exist. A count of 0 with roster_read true means nobody matched. There is no case where a failed read reports a count.
pending_countNo
roster_sourceNo
verified_countNo

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • addedOutput schema / properties
      Added value: +{
+  "pending_count": {
+    "type": "number"
+  },
+  "roster_read": {
+    "description": "true = the contractor roster was read successfully; any counts below are real facts about the roster. false = the roster could NOT be read, and this response makes no claim about how many contractors exist. A count of 0 with roster_read true means nobody matched. There is no case where a failed read reports a count.",
+    "type": "boolean"
+  },
+  "roster_source": {
+    "enum": [
+      "kv",
+      "published",
+      "none"
+    ],
+    "type": "string"
+  },
+  "verified_count": {
+    "type": "number"
+  }
+}
  2. Added

TDQS

A4.5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark this as read-only, idempotent, and non-destructive. The description adds substantial behavioral context beyond those hints: it states that no judgment is made about non-member companies, only returns the fact that 'Yakumo hasn't measured,' provides public inquiry contacts, does not return monetary amounts, and charges no referral fee. This significantly clarifies the tool's behavior and boundaries.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, focused paragraph that front-loads the main purpose ('施主が名前を挙げた業者について答える') then efficiently lists key behaviors and exclusions. Every sentence contributes critical information, with no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is moderately complex with a detailed output schema. The description covers the core decision logic (member vs non-member), return content, explicit non-actions (no judgment, no amounts, no referral fee), geographic scope, and fallback sources. Given the output schema exists, return value details are not needed. This description is thorough and self-sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents all parameters. The description mentions that 'area' and 'work' are used to find alternative verified stores, which aligns with their schema descriptions but adds no new meaning. Thus the description provides no extra value beyond the schema for parameter understanding.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the specific verb '答える' (answer) and resource '施主が名前を挙げた業者' (contractor named by the owner), distinguishing it from siblings like find_contractor and list_verified_stores. It further clarifies scope by outlining behavior for both member and non-member cases, making the tool's unique role unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description establishes clear context: it is used when an owner has named a specific contractor. It implies the tool is not for general searches (there are siblings for that) and states 'Japan only' as a constraint. However, it does not explicitly name alternative tools for different scenarios, so it lacks explicit exclusions or 'when not to use' guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All HORIZON SHIELD YAKUMO (verified contractor directory) toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.4/5.0
Disambiguation4/5

The tools are mostly distinct: check_named_contractor handles specific named contractors, find_contractor handles free-text searches, get_contractor_profile retrieves a single profile, list_verified_stores lists stores, mall_overview gives an overview, and how_verification_works explains the process. There is slight overlap between find_contractor and list_verified_stores (both return verified stores), but the former is a natural-language command tower while the latter is a direct filterable list, so the boundary is clear enough.

Naming Consistency4/5

Most tools follow a verb_noun pattern: check_named_contractor, find_contractor, get_contractor_profile, list_verified_stores, mall_overview. The exception is how_verification_works, which uses a question-like phrase rather than a verb_noun structure, but it is still readable and consistent in style. Overall, the naming is predictable and clear.

Tool Count5/5

With 6 tools, the server is well-scoped for its purpose: a verified contractor directory. Each tool serves a distinct function: checking a named contractor, finding contractors, viewing profiles, listing stores, explaining verification, and providing an overview. No tool feels redundant or missing; the count is appropriate for the domain.

Completeness4/5

The tool surface covers the core workflows: searching, listing, profiling, and explaining the verification process. However, there is no tool for submitting a contractor for verification or for updating store information, which might be expected in a directory that manages verified stores. That said, the server appears to be consumer-facing (for homeowners), so those gaps are acceptable and agents can work around them by directing users to the mall links.

Resources