Skip to main content
Glama
INo-xious

stockbit-mcp

by INo-xious

broker_activity

Read-only

Enter a broker code to list the stocks that broker traded, with net value, volume, and frequency. Reverse lookup of broker_summary to trace what else a broker was distributing across the market.

Instructions

Which STOCKS one broker traded, and how much of each. This is the reverse lookup of broker_summary: that tool fixes a stock and lists brokers, this one fixes a broker and lists stocks. Chain them to answer what neither answers alone — take the biggest net seller of a stock from broker_summary, then ask here what else that broker was distributing. broker_code is the two-letter code (YP, CC, XL); use the brokers tool to find one by name. An unknown or malformed code is rejected before any request goes out. FILTERS: market_types and investor_types each take a LIST, and each value is sent as its own repeated parameter. Passing several boards means the union of those boards. Omit a filter and it is not sent at all, in which case the server picks the default and this tool cannot tell you which one it picked — pass period if the window matters to your answer. REGULER is the ordinary order book and what bandarmology normally means; ALL folds in negotiated block trades and can be several times larger. request in the result echoes exactly what was sent, so the window and filters behind the rows are always visible. PENDING VERIFICATION: this route has not been observed live. Only the traded symbol is projected, with readFrom.symbol naming the key it came from; the value, volume and frequency figures are left inside the raw row under their own names rather than renamed on a guess, because a net figure read out of the wrong key would point confidently the wrong way. Read them from row. rowsFrom: null with count: 0 means the response carried no array — an empty result or an unrecognised shape, distinguished by dataKeys — and NOT a broker who traded nothing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo1-based page. Omitted means the server default.
limitNoRows per page. Omitted means the server default.
periodNoWindow to aggregate over, e.g. LAST_1_DAY, LAST_7_DAYS, YEAR_TO_DATE. Omitted means the server's own default, which this tool cannot report.
sort_byNoSort key, without the SORT_BY_ prefix. Known values: TOTAL_VALUE, NET_VALUE, SELL_VALUE, TOTAL_VOLUME, TOTAL_FREQUENCY, CODE, NAME, GROUP. The list was read from Stockbit's own bundle and is partial, so any uppercase token is accepted.
broker_codeYesBroker code, 2-4 uppercase letters or digits, e.g. YP
market_typesNoBoards to include, as a list. Each value is sent as its own repeated parameter.
investor_typesNoInvestor classes to include, as a list. Also sent as repeated parameters.
Behavior5/5

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

Even with readOnlyHint and openWorldHint already in annotations, the description adds substantial behavioral detail: invalid codes are rejected before the request is sent, omitted filters are not sent and defaults cannot be reported, REGULER vs ALL semantics, the request echo in results, and the meaning of rowsFrom null with count 0. This goes well beyond annotation-level transparency.

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 it is densely informative and front-loaded with the core purpose before moving into filters and result interpretation. Each paragraph addresses a distinct concern — lookup direction, broker code resolution, filter behavior, result echo, and verification status — and every sentence earns its place given the tool's complexity and lack of an output schema.

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 tool with 7 parameters, no output schema, and meaningful edge cases, the description covers the full calling context: how to choose it, how to fill filters, what the server defaults mean, how to interpret the response, and even the verification status of the route. Nothing essential seems missing.

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?

Although schema coverage is 100%, the description materially enriches several parameters: broker_code format and lookup path, list semantics and union behavior for market_types and investor_types, the default-window caveat for period, and the repeated-parameter behavior. This is exactly the kind of meaning the schema alone does not convey.

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 description opens with a precise statement: 'Which STOCKS one broker traded, and how much of each.' It then contrasts with broker_summary, explicitly distinguishing the reverse lookup direction, so an agent can immediately recognize what this tool does and how it differs from 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?

The description names the alternative broker_summary, explains the exact condition that selects one over the other, and gives a concrete chaining example. It also tells the agent to use the brokers tool to resolve broker codes by name, which is practical guidance for correct invocation.

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