Skip to main content
Glama
INo-xious

stockbit-mcp

by INo-xious
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

orderbook

Read-only

View the complete order-book depth for any IDX ticker, showing bid/ask levels, market-board splits, and foreign flow to gauge supply and demand.

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 the answer for anything price_market looks like it should do — that route cannot be called. 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

A4/5.0
Behavior5/5

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

The description goes far beyond annotations by disclosing mixed units in one response, the shares-vs-lots reconciliation, stale foreign flow before 18:00 WIB, and the dead price_market route. These are exactly the behavioral traps an agent needs to know and that annotations cannot capture.

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

Conciseness3/5

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

The first sentence is crisp and front-loaded, but the rest is a dense, sprawling warning block with capitalized emphasis and repeated caveats. The content is relevant, but it would benefit from structured bullets or headings; it is not concise despite being informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/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 covers the most dangerous interpretation hazards: units, foreign-flow dating, per-board market_data, and the unavailable price_market route. It does not enumerate the actual order-book fields such as bid/ask levels, but the opening phrase plus warnings provide enough to call and parse the tool cautiously.

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 schema has one parameter, symbol, described as 'IDX ticker', so schema coverage is 100%. The description adds no additional meaning to the parameter itself, so the baseline of 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 opening sentence identifies a specific resource: the full order-book depth ladder for a symbol. It is clear that this is not a quote or summary endpoint, though it does not explicitly contrast itself with sibling tools in the core statement.

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 actionable routing guidance: it says market_data[] is the answer for what price_market should do and that price_market cannot be called. It also points to market_movers as carrying a real foreign-flow date, which helps an agent choose where to look. It stops short of framing explicit when-to-use/not-use rules for orderbook itself.

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