stockbit-mcp

broker_activity

Read-only

Enter a broker code and date range to list every stock that broker traded, with buy/sell values, volume, lots, and average price per side. Use it to trace a broker's activity across stocks.

Instructions

Which STOCKS one broker traded, and how much of each. This is the reverse lookup of broker_summary: that tool fixes a stock and lists brokers, this one fixes a broker and lists stocks. Chain them to answer what neither answers alone — take the biggest net seller of a stock from broker_summary, then ask here what else that broker was distributing. broker_code is the two-letter code (YP, CC, XL); use the brokers tool to find one by name. An unknown or malformed code is rejected before any request goes out. CHOOSING THE WINDOW. Pass period for a preset, or from+to (YYYY-MM-DD) for an exact range; both ends are required together. Omit both and you get the server's default, which measured 2026-09-01 was that single day. Rows are per stock PER DAY, so a multi-day window returns several rows for the same ticker — one per session it traded. The period NAME never goes on the wire. This endpoint answers 400 to period on every spelling and every value (measured 2026-09-01), but it accepts from/to, so a preset is resolved into a date pair here and the dates are sent. That resolution is this server's own calendar arithmetic, checked against Stockbit's: asked for LAST_7_DAYS and LAST_3_MONTHS, broker_summary resolved them to the same dates this does. YEAR_TO_DATE it starts on January 1st where Stockbit starts on the first trading day — a difference that cannot move a figure, because a window padded with days the exchange was shut contains no extra trades (measured: a Saturday start and the following Monday returned identical rows). You never have to trust that arithmetic. request echoes the dates actually sent and from/to on the result are the window the SERVER says it served. FILTERS: market_types and investor_types each take a LIST, and each value is sent as its own repeated parameter. Passing several boards means the union of those boards. Omit a filter and it is not sent at all, in which case the server picks the default and this tool cannot tell you which one it picked. REGULER is the ordinary order book and what bandarmology normally means; ALL folds in negotiated block trades and can be several times larger. request in the result echoes exactly what was sent, so the filters behind the rows are always visible. BUY AND SELL ARE SEPARATE ROWS, and side is the only thing that tells them apart. The response splits the two halves into brokers_buy and brokers_sell and sends BOTH as positive numbers, so a sell row read without its side looks exactly like a buy. Never infer the direction from a sign, and never sum value across sides without grouping by side first — that total is turnover, not net flow. Each row carries symbol, side, date, value (rupiah), lot, avgPrice, freq and investorType, every one with readFrom naming the wire key it came from, and the whole untouched row beside them. Absent means the wire did not carry it — never zero. rowsFrom names the containers the rows came out of. count: 0 with a populated rowsFrom is a broker who traded nothing in that window; rowsFrom: null means the payload was NOT PARSED — a shape this tool does not recognise, with dataKeys naming what was actually there. Reporting the second as the first is the defect this tool was fixed for: it read count: 0 for a broker with 868 buy rows and 836 sell rows, because it searched for an array and this route nests the two sides inside an object.

Input Schema

TableJSON Schema

Name	Required	Description
`to`	No	Range end, YYYY-MM-DD (inclusive). Requires `from`.
`from`	No	Range start, YYYY-MM-DD. Requires `to`.
`page`	No	1-based page. Omitted means the server default.
`limit`	No	Rows per page. Omitted means the server default.
`period`	No	Preset window, resolved here into `from`/`to` and sent as dates — the name itself is refused by this endpoint. Ignored when `from`/`to` are given. Omitted means the server's own default window.
`date_to`	No	Alias for `to`.
`sort_by`	No	Sort key, without the SORT_BY_ prefix. Known values: TOTAL_VALUE, NET_VALUE, SELL_VALUE, TOTAL_VOLUME, TOTAL_FREQUENCY, CODE, NAME, GROUP. The list was read from Stockbit's own bundle and is partial, so any uppercase token is accepted.
`end_date`	No	Alias for `to`.
`date_from`	No	Alias for `from`.
`start_date`	No	Alias for `from`.
`broker_code`	Yes	Broker code, 2-4 uppercase letters or digits, e.g. YP
`market_types`	No	Boards to include, as a list. Each value is sent as its own repeated parameter.
`investor_types`	No	Investor classes to include, as a list. Also sent as repeated parameters.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv1.3.0Sep 1, 2026

addedInput schema / properties / date_from

Added value: +{
+  "description": "Alias for `from`.",
+  "type": "string"
+}

addedInput schema / properties / date_to

Added value: +{
+  "description": "Alias for `to`.",
+  "type": "string"
+}

addedInput schema / properties / end_date

Added value: +{
+  "description": "Alias for `to`.",
+  "type": "string"
+}

addedInput schema / properties / from

Added value: +{
+  "description": "Range start, YYYY-MM-DD. Requires `to`.",
+  "type": "string"
+}

changedInput schema / properties / period / description

Previous value: -"Window to aggregate over, e.g. LAST_1_DAY, LAST_7_DAYS, YEAR_TO_DATE. Omitted means the server's own default, which this tool cannot report."New value: +"Preset window, resolved here into `from`/`to` and sent as dates — the name itself is refused by this endpoint. Ignored when `from`/`to` are given. Omitted means the server's own default window."

addedInput schema / properties / start_date

Added value: +{
+  "description": "Alias for `from`.",
+  "type": "string"
+}

addedInput schema / properties / to

Added value: +{
+  "description": "Range end, YYYY-MM-DD (inclusive). Requires `from`.",
+  "type": "string"
+}

Addedv1.2.2Aug 30, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, destructiveHint=false, and the description adds extensive behavioral context without contradicting them: unknown broker codes are rejected before any request, `period` is not sent but resolved to dates, rows are per stock per day, buy and sell rows are separate with positive numbers, absences mean the wire did not carry the field rather than zero, and `count: 0` with populated `rowsFrom` vs `rowsFrom: null` have different meanings. This goes far beyond what annotations alone convey.

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?

The description is long but every sentence earns its place given the endpoint's many non-obvious behaviors: reversed lookup semantics, period resolution, repeated-parameter filters, side handling, and response shape quirks. It is front-loaded with the core purpose and sibling distinction, then organized under clear uppercase section labels, making it easy to scan. No filler or redundant repetition.

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?

There is no output schema, so the description must explain return values, and it does so thoroughly: row fields, `readFrom`, `rowsFrom`, `count: 0` semantics, `rowsFrom: null`, `dataKeys`, and the nested buy/sell containers. It also covers default window behavior, error handling for `period`, alias handling, and the measured date-resolution verification. For a 13-parameter tool with no output schema, nothing important is missing.

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

Parameters5/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds substantial extra meaning for nearly every parameter group: `broker_code` format and how to find it, `period` being resolved rather than sent, `from`/`to` required together, filters as repeated parameters with union semantics, omit behavior, and the critical warning never to infer direction from sign because both sides are positive. This is far more than the schema alone provides.

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?

The description uses a specific verb and resource: it tells the agent exactly what the tool returns ('which STOCKS one broker traded, and how much of each') and explicitly contrasts it with broker_summary as the reverse lookup. This makes it instantly distinguishable from the sibling tool without needing to open schemas.

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?

The description gives explicit when-to-use guidance: it names broker_summary as the forward lookup, explains how to chain the two, and tells the agent to use the `brokers` tool to resolve a name into a code. It also provides detailed window selection rules, including that `period` is resolved locally and the preset name never goes on the wire, and what happens when both `period` and `from`/`to` are omitted.

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

broker_activity

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools