Skip to main content
Glama

ListHub – Japan B2B Sales List Quotes

地域を探す

search_areas
Read-onlyIdempotent

地域名の言葉(都道府県・市区町村・政令市の区)から、リストハブで選べる地域の候補と id を返します。get_quote の前に使います。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "search_areas"
  }
}

Input Schema

NameRequiredDescriptionDefault
queryYes地域名(日本語。例:札幌市、北海道、横浜、渋谷区)

Output Schema

NameRequiredDescriptionDefault
errorNo
queryNo
candidatesNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so safety is fully covered structurally. The description adds only that results are 'リストハブで選べる' candidates paired with ids, i.e. a selection list rather than an authoritative single match — useful but thin, and it never addresses what happens when a query matches multiple regions or none.

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?

Two short sentences, zero filler, with the input domain stated first and the downstream sequencing last. Nothing redundant or buried.

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

Completeness4/5

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

For a one-parameter lookup with full annotations and an output schema, the description covers purpose, input domain and call ordering. The only real gap is disambiguation behavior for ambiguous place names, which an agent would likely want to know before relying on the ids.

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 coverage is 100% and the single query parameter already ships with Japanese examples (札幌市、北海道、横浜、渋谷区). The description's parenthetical enumerating prefecture/city/ward types largely restates those examples, so the baseline 3 is appropriate.

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

Purpose4/5

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

Uses a specific verb+resource (地域名の言葉から…地域の候補と id を返します) and names the accepted input domain (都道府県・市区町村・政令市の区). It also positions the tool relative to get_quote, though it never explicitly differentiates itself from the similarly named search_industries sibling.

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?

'get_quote の前に使います' gives an explicit ordering constraint, so the agent knows this is a prerequisite lookup rather than a terminal call. It stops short of when-not guidance or naming any alternative lookup path.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources