Skip to main content
Glama
INo-xious

stockbit-mcp

by INo-xious
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

status

Read-only

Check server health and stored session states to diagnose issues and get the next command to run. Reports version, token expiry, trading mode, and market clock in WIB.

Instructions

Is this server working, and what do I run if it is not? Call this FIRST whenever anything looks wrong, and call it after logging in to confirm it took. Reports the version and Node, which of the three sessions are stored (NEVER the tokens themselves), how long the stored market-data token claims it has left, the trading mode and why, the IDX session clock in WIB, and a nextStep naming the single next command. It answers with no session at all — that is the state every new user is in, and the answer is the useful one. Each session also carries a health: ok / failing / expired / not-stored / unknown, derived from what actually happened the last time that credential was used. failing means present and unexpired but REJECTED by Stockbit — revoked, or superseded by another login. That is the case an expiry check cannot see, and it costs no requests. live: true is NOT free and is rarely what you want. It refreshes the market-data token, which ROTATES the refresh-token family and therefore ENDS the user’s Stockbit website session — the one the chart tools run on. Use health instead; only pass live: true if the user explicitly asks to prove the token with a real request. The market block reports the IDX clock in WIB with a UTC sibling on each field, and does not model public holidays; call market_session for that. server.update says whether a newer release of this server exists. It costs ONE request to the npm registry — not to Stockbit, carrying only the package name — cached for a day and made by this tool alone. isOutdated: true matters: npx caches a resolved tree under a version RANGE, so a user can run a build that is weeks old and nothing else will say so. latest and isOutdated are ABSENT when the check could not run, which means unknown, NOT up to date — read update.note. STOCKBIT_NO_UPDATE_CHECK=1 turns the request off.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
liveNoProve the market-data token with one real refresh. This ROTATES the token family and ends the user's Stockbit website session — ask them first. Default false; `health` answers the same question for free.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.2.2

TDQS

A4.7/5.0
Behavior5/5

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

The description goes far beyond the readOnly/destructive annotations by explaining the health state machine, that failing means present-but-rejected by Stockbit, that live:true rotates the token family and ends the user's website session, and that absent server.update fields mean unknown rather than current. No annotation contradiction: the annotations describe the default read-only path, and the description explicitly qualifies the live option.

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 densely packed. Each paragraph covers one distinct behavior or caveat, front-loads the primary call guidance, and uses structured markers like live:true, server.update, and STOCKBIT_NO_UPDATE_CHECK. Nothing reads as filler.

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?

Without an output schema, the description compensates by naming the returned blocks — sessions, health, market, server.update, nextStep — and explaining failure semantics, side effects, and environmental controls. An agent has enough to invoke status correctly and interpret the answer.

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 single parameter is already fully documented in the schema, including default value, side effects, and the ask-first caveat. The description reinforces the usage guidance but mostly repeats the schema's live/health trade-off, so it adds little new parameter-level meaning.

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 question defines the tool as a health/readiness diagnostic, and the second sentence lists exactly what it reports: version, Node, session storage, token lease, trading mode, IDX clock, and nextStep. It also distinguishes itself from siblings by naming market_session as the tool for public-holiday handling.

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 explicitly says to call this FIRST whenever anything looks wrong and after login to confirm it took. It also gives clear when-not guidance: prefer health over live:true, only pass live:true with explicit user request, and delegate public-holiday logic to market_session. This is ideal routing guidance.

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