Skip to main content
Glama
INo-xious

stockbit-mcp

by INo-xious

bandar_detector

Read-only

Check whether an IDX stock is being accumulated or distributed by reading broker summary net buy/sell totals, top brokers per side, and concentration measures.

Instructions

A typed accumulation/distribution reading for one IDX stock, computed from the same broker summary broker_summary returns: net buy and net sell totals for the window, the top accumulators and distributors, and how concentrated each side is. It returns no verdict, no score and no price forecast. A broker code is a pipe carrying thousands of unrelated clients, not a person — the bandar-check skill has the rest of what this cannot prove, and reading it before drawing a conclusion is the difference between flow and a story. SIGNS: values are IDR, volumes are LOTS. Sell figures are NEGATIVE — sellValueIdr, sellLots, and netValueIdr on anything in topDistributors — because that is how Stockbit sends them. Do not negate them again. netValueIdr is buyValueIdr minus the MAGNITUDE of sellValueIdr: how lopsided the two sides are, not how much was bought. Near zero is the normal reading of a complete NET table, since both sides describe the same trades from opposite ends. A large magnitude means they do not cover the same trades — usually truncation, sometimes GROSS. limit applies PER SIDE, so equal list lengths prove nothing; check whether buyersListed or sellersListed has REACHED limit, and if so raise it and see whether the totals move. topDistributors is largest seller FIRST, by size of flow. Concentration shares are fractions of one side taken on magnitudes, so both sides are positive; a null share means the question cannot be asked — that side is empty, or none of its figures could be read. unreadable.buyers / .sellers count listed brokers left out of that side's totals, so buyers: 1 against buyersListed: 16 means every buy figure covers 15 brokers. Broker codes come back bare; the brokers tool turns them into names. DATES: omit from/to for the latest session, or supply BOTH (YYYY-MM-DD). A half-specified range is rejected because the API would silently answer with the latest session instead.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoRange end, YYYY-MM-DD (inclusive). Requires `from`.
topNoBrokers to keep per side (default 5, max 50)
fromNoRange start, YYYY-MM-DD. Requires `to`.
limitNoMax brokers per side fetched from the summary (default 50). Raising it widens the totals and the concentration denominators; it is not the same as `top`, which only trims the two lists that are returned.
periodNoPreset window instead of from/to — LATEST (default), YESTERDAY, LAST_7_DAYS, LAST_3_MONTHS, YEAR_TO_DATE. Aggregated server-side in one request, so YEAR_TO_DATE costs the same as today. Ignored when from/to are given.
symbolYesIDX ticker, e.g. BBRI
date_toNoAlias for `to`.
end_dateNoAlias for `to`.
date_fromNoAlias for `from`.
start_dateNoAlias for `from`.
market_boardNoDefault REGULER — the ordinary order book, and what bandarmology means. ALL folds in negotiated blocks and can be several times larger.
investor_typeNoDefault ALL
transaction_typeNoNET (default) nets each broker's buys against its sells; GROSS does not.
Behavior5/5

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

Discloses sign conventions (`sellValueIdr`, `sellLots`, and `netValueIdr` in topDistributors are negative and should not be re-negated), the exact meaning of `netValueIdr`, per-side `limit` behavior, ordering of `topDistributors`, and `unreadable` counts. This goes far beyond the readOnly/openWorld/destructive annotations and prevents misinterpretation.

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 section earns its place: SIGNS, netValue semantics, limit pitfalls, output-field interpretation, unreadable counts, and DATES. Purpose is front-loaded, and the dense warnings are organized rather than rambling.

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 compensates by explaining return-value semantics in depth: sign conventions, concentration shares, `unreadable`, `buyersListed`, and list ordering. Combined with the full input schema and annotations, no critical invocation or interpretation detail is missing.

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

Parameters4/5

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

Schema shows all properties with descriptions, so the baseline is 3; the description adds important cross-parameter semantics like `limit` applying per side, `limit` versus `top`, `period` being ignored when `from`/`to` are given, and date pairing. It does not define every parameter again, but it clarifies the subtle ones beyond the schema.

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?

States a specific operation and object: typed accumulation/distribution reading for one IDX stock, and lists exactly what it returns (net totals, top accumulator/distributors, concentration). Explicitly disclaims a verdict/score/forecast and points to `broker_summary` as the source data, so an agent can tell it apart from predictive and raw-summary siblings.

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?

Names the companion skill (`bandar-check`) as holding what this tool cannot prove and says to read it before drawing a conclusion; names `brokers` as the tool for resolving bare broker codes. Also gives explicit date-usage rules (omit both or provide both) and describes when a half-specified range is rejected.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/INo-xious/stockbit-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server