Skip to main content
Glama

縦綱 Tatezuna — o-sumo

Search rikishi(力士検索)

search_rikishi
Read-only

Search Grand Sumo rikishi by 四股名 (shikona) or 読み (yomi). Returns up to 20 matching rikishi with their ID, name, reading, current rank, and profile URLs.

Input Schema

NameRequiredDescriptionDefault
queryYesSearch query for rikishi name or reading (e.g. "大の里", "おおのさと")

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real behavioral detail beyond them: a hard cap of 20 results and the exact fields returned (ID, name, reading, current rank, profile URLs). It stops short of disclosing match semantics (exact vs. partial/substring matching), which is the main unknown for a search tool.

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 sentences, no filler, and the search scope plus accepted inputs are front-loaded before the return-value clause. Every clause carries information an agent can act on.

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 single-required-parameter, read-only search tool with no output schema, the definition covers input domain, result cap, and returned fields, which is enough to call it correctly. The remaining gaps are matching behavior and what happens when no rikishi match.

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%, and the query parameter's schema entry already states it accepts name or reading with concrete examples ("大の里", "おおのさと"). The description restates the same fact rather than adding meaning, so the baseline 3 applies.

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?

The description opens with a specific verb and resource ("Search Grand Sumo rikishi") and names the two accepted key types (四股名 shikona / 読み yomi). It also enumerates returned fields, which implicitly separates it from get_rikishi_profile, but it never names that sibling, so the differentiation is left to inference.

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

Usage Guidelines3/5

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

Only implied usage: you search to obtain an ID and profile URLs, which suggests a lookup-then-fetch workflow with get_rikishi_profile. There is no explicit when-to-use statement, no guidance for zero results, and no mention of when get_banzuke or get_rikishi_profile should be preferred instead.

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.