BytNode

Get System Info

get_system_info

Read-only

Your plan (families, history depth, rate, quota; null = unlimited), always returned and free; on demand the served pairs, data freshness and catalogs. include: symbols (spot-only pairs have no futures data), freshness (freshness_fields: per field). catalogs: macro_series, macro_intraday_series, symbol_capabilities (the series of get_macro_data; symbol_capabilities needs symbol). Each part or catalog: one request.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_system_info"
  }
}

Input Schema

Name	Required	Description
`symbol`	No	Pair of symbol_capabilities.
`include`	No	Parts to add.
`catalogs`	No	Catalogs to add.
`category`	No	Filter of macro_series.
`freshness_fields`	No	Fields whose freshness you want.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Beyond readOnlyHint/destructiveHint, the description discloses meaningful behavior: plan data is always included at no quota cost, `null` means unlimited, extra parts are on demand, and each part or catalog consumes exactly one request. That request-counting rule is exactly the kind of quota behavior an agent needs and annotations do not provide; it stops short of describing response shape.

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?

It is short and front-loads the always-returned plan info, but the compression is aggressive – semicolons and bracketed clauses make it read like notes, and terms like "families" and "rate" are used without unpacking. Every phrase is load-bearing, but the parsing cost is high.

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

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, yet the description only sketches the return contents (plan fields, served pairs, freshness, catalogs) without describing structure or how freshness/catalog payloads are shaped. For a zero-required-parameter metadata tool with five optional inputs, it is close to adequate but leaves the response format underspecified.

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?

With 100% schema coverage the baseline is 3, and the description genuinely adds meaning: spot-only pairs have no futures data for `symbol`, freshness_fields is per-field, and symbol_capabilities requires `symbol`. These cross-parameter dependencies are not evident from the schema alone.

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 description states a specific resource – the caller's plan metadata plus optional served pairs, freshness, and catalogs – which is concrete enough to distinguish from siblings like get_macro_data, and it explicitly maps symbol_capabilities to the `series` of get_macro_data. It is dense and jargon-heavy ("families", "served pairs"), slightly obscuring the purpose, but it is not tautological.

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

Usage Guidelines3/5

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

It conveys a cost model – plan info is "always returned and free" while the other parts are "on demand" and each costs one request – which is implicit guidance for calling it cheaply. However, there is no explicit when-to-use vs when-to-use-another-tool guidance or exclusion, leaving the agent to infer the routing.

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

All BytNode tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?