stockbit-mcp

broker_summary

Read-only

See which brokers net-bought or net-sold any IDX stock, with volumes in lots and IDR value and foreign/local/govt labels, to identify institutional accumulation or distribution from bandarmology data.

Instructions

Broker summary for an IDX stock: which brokers net-bought/sold, in lots and IDR value, with foreign/local/govt classification. This is the core bandarmology signal — TradingView has no equivalent. DATES: omit from/to for the latest completed session. Supply BOTH from and to (YYYY-MM-DD) for a historical window — the server aggregates net flow across it in one request, so a multi-month range is as cheap as one day. For a single past day pass the same date twice. Both ends are required; a half-specified range is rejected because the API would silently return the latest session instead. An empty result for a weekend or public holiday is expected, not an error. SIGNS: sell-side rows carry NEGATIVE netLots and netValueIdr, because that is how Stockbit sends them. Do not negate them again. A row omits netLots or netValueIdr when that figure could not be read — missing on the wire, empty, or in a format this server refuses to guess at. Absent is NOT zero, it means unknown, so do not sum these rows without checking. unreadable on the envelope names the wire keys and counts, per side, how many listed brokers a total over these rows would miss. resolve_names: true adds the securities house to each row as name, joining against the brokers directory so you do not have to. The directory is cached for five minutes, so this is usually free. It is best-effort: if the directory cannot be read the rows and every figure on them are unchanged and names.note says why, and a code the directory does not carry simply has no name — an unresolved code is not a nameless broker.

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`.
`limit`	No	Max brokers per side (default 50; API default 25 truncates)
`period`	No	Preset window instead of from/to — LATEST (default), YESTERDAY, LAST_7_DAYS, LAST_3_MONTHS, YEAR_TO_DATE. The server aggregates the whole window in ONE request, so YEAR_TO_DATE costs the same as today. Ignored when from/to are given.
`symbol`	Yes	IDX ticker, e.g. BBRI
`date_to`	No	Alias for `to`.
`end_date`	No	Alias for `to`.
`date_from`	No	Alias for `from`.
`start_date`	No	Alias for `from`.
`market_board`	No	Default REGULER — the ordinary order book, and what bandarmology means. ALL folds in negotiated blocks and can be several times larger. NEGO and TUNAI select those boards alone.
`investor_type`	No	Default ALL
`resolve_names`	No	Add each broker's securities house as `name`, joined from the cached directory.
`transaction_type`	No	NET (default) nets each broker's buys against its sells; GROSS does not.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.3.0Sep 1, 2026

addedInput schema / properties / resolve_names

Added value: +{
+  "description": "Add each broker's securities house as `name`, joined from the cached directory.",
+  "type": "boolean"
+}

Changed11 schema fields changedv1.2.2Aug 30, 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 / market_board / description

Previous value: -"Default REGULER (use for bandarmology)"New value: +"Default REGULER — the ordinary order book, and what bandarmology means. ALL folds in negotiated blocks and can be several times larger. NEGO and TUNAI select those boards alone."

changedInput schema / properties / market_board / enum

Previous value: -[
-  "REGULER",
-  "NEGOTIATED",
-  "CASH"
-]New value: +[
+  "REGULER",
+  "ALL",
+  "NEGO",
+  "TUNAI"
+]

addedInput schema / properties / period

Added value: +{
+  "description": "Preset window instead of from/to — LATEST (default), YESTERDAY, LAST_7_DAYS, LAST_3_MONTHS, YEAR_TO_DATE. The server aggregates the whole window in ONE request, so YEAR_TO_DATE costs the same as today. Ignored when from/to are given.",
+  "enum": [
+    "LATEST",
+    "YESTERDAY",
+    "LAST_7_DAYS",
+    "LAST_3_MONTHS",
+    "YEAR_TO_DATE"
+  ],
+  "type": "string"
+}

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"
+}

changedInput schema / properties / transaction_type / description

Previous value: -"Default NET"New value: +"NET (default) nets each broker's buys against its sells; GROSS does not."

changedInput schema / properties / transaction_type / enum

Previous value: -[
-  "NET",
-  "BUY",
-  "SELL"
-]New value: +[
+  "NET",
+  "GROSS"
+]

First observedv0.1.0Aug 2, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare this a safe read, and the description layers on substantial behavior beyond that: the server aggregates multi-date windows in one request, half-specified ranges are rejected, sell-side rows already carry negative signs, absent values mean unknown rather than zero, and name resolution is best-effort with a cache. It also flags the 'unreadable' envelope so the agent understands totals may miss rows.

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 text is long but tightly sectioned (DATES, SIGNS, resolve), front-loaded with the core purpose, and every addition addresses a real failure mode an agent would otherwise hit. No filler or tautology.

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?

For a 13-parameter tool with no output schema, this is unusually complete: it covers date edge cases, sign conventions, missing-data semantics, board selection, limit truncation, and the optional name enrichment behavior. An agent has enough to invoke it correctly and interpret the response.

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%, but the description goes well beyond it by explaining the date-pair constraint, sign conventions for output rows, market_board 'ALL' being several times larger, default limit vs API truncation, and resolve_names semantics. This gives the agent enough to choose and populate parameters correctly without inspecting the schema alone.

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 opening sentence names the verb/resource relationship ('Broker summary for an IDX stock') and enumerates the exact output dimensions: net buys/sells, lots, IDR value, and investor classification. Calling it 'the core bandarmology signal' gives the agent a clear inference target and separates it from generic quote/orderbook tools.

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

Usage Guidelines4/5

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

The description gives strong when-to-use context — bandarmology signal, no TradingView equivalent — and detailed call conventions (latest session if dates omitted, both dates required for history, weekend results are not errors). It does not explicitly name sibling alternatives such as broker_distribution or broker_activity and say when to choose them instead, so it stops short of a 5.

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

broker_summary

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools