Skip to main content
Glama
INo-xious

stockbit-mcp

by INo-xious
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

orderbook

Read-only

Retrieve the full bid-ask depth ladder for an IDX ticker, showing per-board orderbook levels and identifying foreign flow timing to prevent cross-session data mix-ups.

Instructions

Full order-book depth ladder for a symbol. UNITS, AND THEY ARE MIXED IN ONE RESPONSE. volume here is SHARES (e.g. 3,545,526,000) while technicals' volumeLots for the same symbol and session is LOTS (35,488,071). They reconcile at exactly 100 shares per lot — the IDX lot size — and neither figure is wrong. Worse, this same payload labels its total_bid_offer depth figures lot while carrying volume in shares a few keys away. Two units under similar names in one response is a silent-wrong-answer generator: check which one you are holding before comparing anything, and never compare volume here against volumeLots there without the ×100. market_data[] carries the per-board split (All Market / Regular / Nego / Cash). It is also also presented by price_market, with optional board filtering and an explicit orderbook source. FOREIGN FLOW HAS NO DATE ON THIS PAYLOAD. fbuy/fsell/fnet arrive with nothing saying which session they are from, and foreign flow publishes at roughly 18:00 WIB, so before that release they are the PREVIOUS session's. price_bands surfaces this as an explicitly null dataAsOf with a note; market_movers carries the date for real as foreign.sessionDate.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
symbolYesIDX ticker

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior5/5

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

The description adds critical behavioral warnings beyond the annotations: mixed share/lot units in one payload, foreign flow values lacking a session date, the 18:00 WIB publication caveat, and the per-board market_data split. This is exactly the kind of context that prevents silent wrong answers.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is overly long and disorganized, with all-caps warnings and a typo ("also also"). While the opening sentence is sharp, the rest reads as a dense block of caveats that could have been structured more concisely for an agent to parse quickly.

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?

Despite having no output schema, the description covers the key return fields, unit hazards, board split, and the foreign-flow date trap. An agent has enough information to invoke the tool correctly and interpret the response safely.

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?

The input schema already documents the only parameter, symbol, with "IDX ticker". The description repeats that this is for a symbol and mentions symbol in warnings, but adds no new syntax or semantic detail beyond the schema, so baseline 3 applies.

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?

The first sentence, "Full order-book depth ladder for a symbol," clearly identifies the resource and content being returned. It lacks an explicit verb and does not differentiate itself from siblings like quote or price_chart, but the core purpose is unmistakable.

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

Usage Guidelines2/5

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

No explicit guidance is given for when to use this tool versus alternatives. The references to technicals, price_bands, and market_movers are warnings about unit and date discrepancies, not instructions for choosing among tools.

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

Deploy Server

Other Tools