Skip to main content
Glama
Sign In

Blocksize Agentic Market Intelligence

by info.blocksize.mcp
OverviewDiscussionsAdmin

Instrument List

list_instruments
Read-onlyIdempotent

List the supported instruments for one Blocksize service. This is free, read-only catalog metadata; it does not fetch live prices, create accounts, or start x402 payment.

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum instruments to return. Use offset to traverse the stable catalog without requesting the entire upstream array.
offsetNoZero-based offset into the sorted instrument catalog.
serviceNoBlocksize service namespace to list: vwap for crypto VWAP pairs, bidask for shared bid/ask symbols including supported equities, fx for FX pairs, or metal for metals.vwap

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / limit
      Added value: +{
+  "default": 100,
+  "description": "Maximum instruments to return. Use offset to traverse the stable catalog without requesting the entire upstream array.",
+  "maximum": 500,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / offset
      Added value: +{
+  "default": 0,
+  "description": "Zero-based offset into the sorted instrument catalog.",
+  "minimum": 0,
+  "type": "integer"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / service / description
      Previous value: -"Blocksize service namespace to list: vwap for crypto VWAP pairs, bidask for shared bid/ask symbols, fx for FX pairs, or metal for metals."New value: +"Blocksize service namespace to list: vwap for crypto VWAP pairs, bidask for shared bid/ask symbols including supported equities, fx for FX pairs, or metal for metals."
  3. Changed2 schema fields changed
    • addedInput schema / properties / service / description
      Added value: +"Blocksize service namespace to list: vwap for crypto VWAP pairs, bidask for shared bid/ask symbols, fx for FX pairs, or metal for metals."
    • addedInput schema / properties / service / enum
      Added value: +[
+  "vwap",
+  "bidask",
+  "fx",
+  "metal"
+]
  4. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context beyond the annotations: the call is free and neither triggers account creation nor x402 payment, which is meaningful behavioral information for an agent weighing cost/side effects.

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?

Two tight sentences: the purpose is front-loaded and the negative-scoping sentence is compact and earns its place by ruling out costly side effects. No filler.

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 annotations covering the safety profile, a full parameter schema, and an output schema, the description only needs to frame purpose and side effects, which it does. The one gap is the absence of sibling routing (catalog alternatives vs. live-data tools), which slightly limits completeness.

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?

Schema description coverage is 100% and the service enum, limit, and offset are all fully documented in the schema itself, including the traversal guidance. The description contributes nothing about parameters, so the 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?

States a specific verb and resource ('List the supported instruments') scoped to 'one Blocksize service', which is unambiguous. It does not name a sibling it competes with (e.g. get_product_catalog, search_pairs), so an agent must infer differentiation, but the purpose itself is clear.

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?

The description gives negative scoping ('does not fetch live prices, create accounts, or start x402 payment'), which implicitly tells the agent this is catalog metadata rather than a data-fetch call. However, it never names the alternative tool an agent should use for live prices or for the other catalog-style calls, so routing is left to inference.

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

All Blocksize Agentic Market Intelligence toolsInspect
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