Japan EDINET Filing Index

Large shareholding changes across issuers (Japan EDINET)

edinet_ownership_change_events

Read-only

Which large shareholdings in Japanese companies changed recently, across all issuers? One row per large shareholding report read from EDINET, newest first: issuer, holder (corporate names only), total ratio as filed and the previous total stated in it, and event types derived from those figures only: new_stake, increase, decrease, below_5_percent, crossed_up/down (10%, 1/3, 1/2, 2/3), amendment, change_unknown with reason. Unread reports are counted. No assessment of intent.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "edinet_ownership_change_events"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Maximum number of rows, 1-100 (default 50)
`since`	No	Only reports submitted on or after this date (YYYY-MM-DD, Japan time). Default: 6 days before until. since..until may span at most 31 days
`until`	No	Only reports submitted on or before this date (YYYY-MM-DD, Japan time). Default: today
`cursor`	No	next_cursor from a previous answer with the same other inputs, to get the next page
`holder`	No	Optional EDINET code (E12345) of a holder filed as a corporation: only reports that list it
`issuer`	No	Optional issuer: EDINET code (E12345) or securities code (4 or 5 characters)
`event_types`	No	Optional: only rows having at least one of these event types (new_stake, increase, decrease, unchanged, below_5_percent, crossed_up, crossed_down, amendment, change_unknown). Over HTTP, comma-separated

Output Schema

Name	Required	Description
`query`	Yes
`terms`	Yes	URL of the terms of service.
`events`	Yes	Newest first; derived from figures as filed; no assessment of intent.
`status`	Yes	found; none_in_range (none among reports read so far: see events_not_built); unknown.
`coverage`	Yes	What this service has indexed: the date range, missing days (backfill in progress) and freshness.
`label_note`	Yes
`provenance`	Yes	Freshness receipts for every upstream source used.
`answered_at`	Yes
`attribution`	Yes
`events_note`	Yes
`next_cursor`	Yes
`not_covered`	Yes
`events_total`	Yes
`legal_notice`	Yes
`privacy_note`	Yes
`interpretation`	Yes
`unknown_reason`	Yes
`events_not_built`	Yes	Filings in the range with no event (not read yet, no CSV, unreadable); not silently dropped.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already mark this readOnly and openWorld, so the description is not carrying the safety burden. It nevertheless adds real behavioral context: event types are derived from the filed total and prior total figures only, crossing thresholds are named, and unknown changes carry a reason. The terse 'Unread reports are counted' hints at partial-coverage semantics but never explains what unread means or how it affects result completeness.

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?

Front-loaded with the user-facing question, then a single colon-led enumeration of output shape and event derivation. It is dense but every clause carries information; only 'Unread reports are counted' reads as an unexplained fragment.

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 an output schema present, return values need no prose, and all seven optional parameters are fully documented in the schema. The description covers grain, ordering, derivation logic, and intent limits — everything an agent needs to decide and call correctly, except a sibling comparison.

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 already documents all seven parameters and the default date window, so the 3 baseline applies. The description does add the semantics behind the event_types values (thresholds for crossed_up/crossed_down) and the newest-first ordering, but nothing about how holder/issuer identifiers interact with the 'corporate names only' holder rule.

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?

Opens with a specific question scoping the resource ('large shareholdings in Japanese companies that changed recently, across all issuers') and then states the row grain and returned fields. The 'across all issuers' phrasing implicitly sets it apart from issuer-scoped siblings like edinet_large_holding_reports, but no sibling is named explicitly, so differentiation still requires a guess.

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?

Usage is implied by the scope statement ('across all issuers', filters for holder/issuer/event_types in the schema) rather than stated. There is no explicit when-to-use/when-not or pointer to the alternative tool for raw or per-issuer report lookups. 'No assessment of intent' is a limitation, not routing guidance.

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

All Japan EDINET Filing Index tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?