J-Quants for agents: what it covers, and when you need more

The short answer J-Quants is the official JPX product for Japanese market data, and for most agents it is the right first call. It is operated by the exchange, it is priced for individuals, and since December 2025 it authenticates with a plain API key instead of a token refresh dance, which removes the most annoying part of wiring it into an agent. There is a category of question it does not cover, and that category is why I built something else. This post is about where that line sits, with plan facts from JPX's own releases and numbers from my own ingest. What J-Quants does well From JPX's August 2025 release, four plans: free at 0 yen, Light at 1,650 yen a month, Standard at 3,300, Premium at 16,500 (all tax included). Data windows follow the price: two years with a twelve week delay on free, five years on Light, ten on Standard, everything on Premium. The free plan is generous in a way that is rare. It includes prices, the listed securities table, the trading calendar, earnings announcement dates, and 財務情報, the quarterly summary. Paying widens the history window and adds datasets, but the shape of the product is the same, so what you learn on the free plan still applies after you upgrade. Two rows in that release are worth knowing before you pick a plan: 財務情報 (quarterly summary financial data) is available on all four plans, including free. 財務諸表, meaning the balance sheet and profit and loss statement detail, plus 配当金情報 (dividend data), are Premium only. For an agent that screens companies, pulls a price series and reads headline figures, the free plan is a working setup at zero cost and Light is a reasonable upgrade. A later release from January 2026 added CSV bulk downloads for Light and above, and minute and tick data as a 5,500 yen addon. Where the edge sits An agent does not read a table the way a person does. It reads whatever fields the response carries, then either answers or asks for more. The questions that stall at summary level are the ones that need a number the summary does not carry: "Compare operating margin and equity ratio over five years." Needs a consistent time series of two ratios, derivable from summaries. Fine from Light. "Which segment drove the profit drop last quarter?" Needs the segment table, which lives in the XBRL rather than in a quarterly summary. "Show the raw line items behind that figure." Needs the element name, the context (consolidated or not) and the period. That is XBRL. This is a design boundary rather than a defect. J-Quants distributes curated datasets, and the element level table with contexts is a different artifact: it sits inside the filing, and the exchange sells it there. Every product in this space draws the same line somewhere, mine included. The part I built I needed the filing level, so I parse EDINET XBRL, TDnet disclosures and JPX listings into one shape and expose it over REST and MCP. Measured on the live service: Quantity Value Listed securities 4,471 with market segment and industry Annual and interim financial statements 28,863 rows across 3,715 codes XBRL line items 2,113,558 rows at element level Toyota, five years of annual figures 10.5 KB in 0.56 s That last row decides whether an agent can afford to ask. Ten kilobytes is smaller than most prompt preambles, so the model can hold five years of a company in context and reason over it instead of paginating. The line item count is also the honest measure of the work. Two million rows is not a download, it is a parse, a vocabulary mapping across three accounting regimes, and a decision about rows that appear in one year and vanish the next. Who should pick which Most people should start with J-Quants. You want an official, contracted, split adjusted price history, intraday bars or tick data. J-Quants, without hesitation. Mine has daily closes from 2023, unadjusted, and no intraday data at all. You want the shortest path from zero to a working screen. Either works from the free tier. J-Quants has the exchange behind it, which some teams need for procurement. You want the agent to read a filing the way an analyst reads it. Element level rows with their context. That is where mine fits, with one caveat I should state plainly: the rows are all there, but turning them into a clean segment table is work I have only done for one pilot company so far. You want an MCP endpoint with no wrapper. The official J-Quants spec is REST with API keys, so an agent needs a small wrapper. Mine speaks MCP directly, fourteen tools. You need someone to stand behind the number. J-Quants is the exchange's own product. My terms say the opposite of that: data comes as is, with no warranty of accuracy and no support obligation, so check the filing before you rely on a figure. That last point matters more than it sounds. If your use is regulated, or a wrong number costs money, the official route answers "where did this come from" in a way a personal project cannot. What mine does not do Prices start in 2023 and are not split adjusted, so a five year chart of a company that split in 2024 will look wrong. No intraday data. Forecast coverage depends on the upstream source still holding the release, which I measured at about five weeks, so guidance is narrower than financial statements. It is reference data, not investment advice, and not a licensed feed. The free tier is one hundred calls a month, enough to evaluate and to run a small agent, not enough for a nightly job over the whole market. Where this landed Both routes are legitimate and they answer different questions. Start with JPX if you want adjusted exchange grade prices, a contract and an accountable source. If the question is "what is inside this filing", that is the layer I build, and the product page with the free key form is at discli. The join key work behind it is in Japanese company data: three identifiers, and the disclosure side in TDnet as an API. If you have run both, what made you reach past the summary level the first time? Originally published at agentjournal.dev.