Skip to main content
Glama

Get major shareholders

get_major_shareholders
Read-only

Return the major shareholder reports (大量保有報告書) filed for a Japanese listed company by EDINET entity code. Returns a list of shareholders with ownership percentage, shares held, and filing date. Reports that are identical in filer, report date, percentage, shares, change type and purpose are merged into one row; doc_ids lists every source filing. ownership_pct is in percent and shares_held in shares (see units). Results are ordered by report date, newest first. An empty list means no such reports were found in EDINET filings for this company. Source: EDINET (https://disclosure2.edinet-fsa.go.jp/), PDL 1.0 (https://www.digital.go.jp/resources/open_data/public_data_license_v1.0). Data is processed by Kabuken, not raw unprocessed FSA data. Not investment advice.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of shareholder rows to return (1-500, default 100)
cursorNoOpaque next_cursor from the previous response; send it with the same entity_code and limit to get the next page
entity_codeYesEDINET entity code of the company (e.g. E02144)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / cursor
      Added value: +{
      +  "description": "Opaque next_cursor from the previous response; send it with the same entity_code and limit to get the next page",
      +  "maxLength": 512,
      +  "type": "string"
      +}
    • addedInput schema / properties / limit
      Added value: +{
      +  "description": "Maximum number of shareholder rows to return (1-500, default 100)",
      +  "maximum": 500,
      +  "minimum": 1,
      +  "type": "number"
      +}
  2. First observed

TDQS

A3.7/5.0
Behavior5/5

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

Annotations already cover read-only/non-destructive behavior, but the description adds important behavior: duplicate reports are merged by filer, report date, percentage, shares, change type, and purpose; doc_ids lists every source filing; results are ordered newest first; units are specified; and empty-list semantics and data-processing disclaimers are disclosed.

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

Conciseness4/5

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

The purpose and return behavior are front-loaded, followed by necessary deduplication, units, ordering, source/license, and disclaimer details. It is slightly dense with license URL and compliance text, but no major waste.

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 explains returned fields, deduplication and doc_ids behavior, units, ordering, and empty results; pagination parameters are adequately covered by the input schema. This is complete enough for correct invocation.

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%, so entity_code, limit, and cursor are fully documented in the schema. The description adds return-field units and merging semantics but little parameter-specific meaning beyond what the schema already provides.

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?

Clearly states it returns major shareholder reports for a Japanese listed company by EDINET entity code. The resource is specific and distinguishable, but it does not explicitly contrast with siblings such as get_company_financials or list_documents.

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

Usage Guidelines2/5

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

No guidance is given on when to choose this over sibling tools, nor are prerequisites beyond entity code explained. It clarifies empty-list meaning, but that is result semantics rather than usage guidance.

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.