Known Limitations

Hive is a managed crypto data surface for agents, not an unlimited mirror of every upstream provider. These limits are intentional: they keep tool discovery compact, responses usable inside MCP clients, and stateful writes scoped to the right user or B2B subject.

Start with runtime discovery

Static docs explain the product shape. Runtime discovery is the authority for what a key can call right now:

• Use MCP tools/list, hive://tools, and hive://providers inside MCP clients.
• Use GET /api/v1/tools for REST catalog discovery.
• Use get_api_endpoint_schema or the REST catalog schema before sending production requests.
• Check meta.runtime_status, meta.fetched_at, _truncated, _pagination, and provider error payloads before acting on a result.

Do not assume a static page, old prompt, or cached agent memory has the current schema.

Provider and plan boundaries

Hive normalizes providers, but upstream products still have their own data availability, plan gates, rate limits, and deprecations.

Response-size guardrails

Hive response handling is designed for agent transports. The source runtime uses a 25,000-token response budget, estimated at roughly 100,000 characters, and adds truncation metadata when a result is too large.

When a response is truncated, look for:

• _truncated: true
• _pagination with the next page, offset, cursor, or suggested page size
• _dropped_fields for supplementary historical/chart fields removed to keep the answer usable
• meta.truncated or runtime status metadata on REST execution

Fix truncated calls by narrowing the request:

{
  "tool": "get_yield_pools",
  "args": {
    "chain": "ethereum",
    "limit": 25,
    "offset": 50,
    "minTvl": 10000000
  }
}

Not every tool supports the same pagination shape. Inspect the live schema before assuming limit, offset, cursor, page, or per_page.

Request/response boundaries

Hive MCP and REST tools are request/response interfaces. They do not replace every provider-native product surface.

• Hive does not expose provider webhooks or push streams through the standard MCP/REST execution path.
• Hive stateful monitoring can save monitors, run scheduled checks, list alerts, and generate reports when that workflow fits the use case.
• Latency-sensitive trading infrastructure should call the execution venue or low-level RPC provider directly and use Hive for context, risk, research, and monitoring.
• Hive data tools do not sign transactions or execute trades.

Stateful and B2B boundaries

Stateful tools store monitors, alerts, memory, reports, and subject audit events under the authenticated Hive owner plus a subject boundary.

• Direct users use the default subject self.
• B2B partners should keep one Hive API key on a trusted backend and send signed subject headers for each downstream customer.
• Never put HIVE_API_KEY or HIVE_SUBJECT_SIGNING_SECRET in browser code.
• Before B2B stateful writes, call /api/v1/b2b/readiness or checkHiveB2BReadiness() and require b2b_adapter_ready: true.

See B2B Partner Adapter and Stateful Monitoring for implementation details.

Related

• Live Catalog
• Response Formats
• Error Codes
• Rate Limits
• Data Sources