Skip to main content
Glama

ZENITH Code

Reverse shareholder lookup ★

search_by_shareholder
Read-only

REVERSE LOOKUP: given an investor/holder name, list every Japanese listed company where they appear as a major shareholder in the company's latest annual securities report (the same filing as get_major_shareholders), with rank, shares, the ownership ratio (0-1 decimal; 0.128 = 12.8%) and source document. A holder listed twice in one company comes back as two rows. Delisted companies are excluded unless includeDelisted=true. The name is a substring match, except that a name of exactly 2 letters or digits (such as a two-character personal name) is matched exactly. At most 100 rows per call; when more remain, call again with the offset given in the note. Use this to answer "what does own?". 保有者名から、その投資家が各社の最新の有価証券報告書で大株主として名を連ねる銘柄を逆引きします(例: 日本マスタートラスト、オアシス)。名前は部分一致で、空白を除いてちょうど 2 文字の名前(2 文字の個人名など)だけは完全一致です。同じ会社に 2 行あれば 2 行返します。上場廃止の会社は includeDelisted=true のときだけ。1 回に最大 100 行で、続きは注記の offset で取ります。Costs 10 tokens.

Input Schema

NameRequiredDescriptionDefault
nameYesHolder name, partial match, at least 3 consecutive letters or digits once spaces are removed; a name of exactly 2 letters or digits is matched exactly / 保有者名(部分一致。空白を除いて文字か数字が 3 文字以上続くこと。空白を除いてちょうど 2 文字の名前は完全一致。例: "日本マスタートラスト"・"包賢")
limitNo
offsetNoRows to skip, for the next page. / 続きを取るときに飛ばす行数
includeDelistedNoAlso include delisted companies. / 上場廃止の会社も含める

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond readOnlyHint, the description discloses duplicate-row behavior (a holder listed twice yields two rows), the 100-row ceiling with offset-based continuation, substring vs exact matching for 2-character names, delisted exclusion by default, and the 10-token cost. These are non-obvious behavioral traits the agent cannot get from annotations or schema.

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

Conciseness3/5

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

The English text is front-loaded and dense with useful detail, but the entire content is then repeated in Japanese, roughly doubling the length without adding information for a single-language reader. Other than that redundancy, sentences earn their place.

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?

With no output schema, the description still specifies the returned fields (rank, shares, ownership ratio as a 0-1 decimal with example, source document) and the pagination contract. An agent could call and paginate correctly from this text alone.

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

Parameters4/5

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

Schema coverage is 75%, and the description still adds meaning: it clarifies the exact-match exception for 2-character names, the effect of includeDelisted, the 100-row-per-call cap tied to limit, and how offset is used for the next page. It largely restates but usefully reinforces the name-matching rule that is easy to get wrong.

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?

States a precise verb and resource: given a holder name, list every Japanese listed company where it appears as a major shareholder in the latest annual securities report. It explicitly anchors itself to the same filing as get_major_shareholders, so the direction of the lookup (holder → companies rather than company → holders) is unmistakable.

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

Usage Guidelines5/5

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

Names the question it answers ('what does <investor> own?') and gives concrete example holders. It also states the alternatives' boundary implicitly via the sibling reference and describes when delisted companies appear, leaving little inference needed.

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