On-chain stablecoin market cap and Bitcoin institutional holdings data.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 3.9/5 across 12 of 12 tools scored.
Each tool has a clearly distinct purpose with no ambiguity. The BTC tools focus on holdings data with different temporal granularities (current, daily, weekly) and segment breakdowns, while the stablecoin tools cover market cap, supply data, chain distribution, and health checks. There is no functional overlap between tools, making selection straightforward.
All tool names follow a consistent snake_case pattern with a clear prefix structure: 'orbuc_btc_' for Bitcoin-related tools and 'orbuc_stablecoin_' for stablecoin-related tools. The naming convention is uniform throughout, using descriptive nouns and adjectives to differentiate functions (e.g., 'health', 'current', 'daily', 'segments').
With 12 tools, the server is well-scoped for its dual-domain purpose covering BTC holdings and stablecoin data. The count is appropriate, providing comprehensive coverage without bloat, and each tool serves a distinct, necessary function in the data retrieval and monitoring workflow.
The tool set offers complete coverage for both BTC holdings and stablecoin data domains. For BTC, it includes health checks, current holdings, daily/weekly time series, and segment breakdowns. For stablecoins, it covers health, aggregate data, chain distribution, historical and latest coin-specific data, and market cap tracking, leaving no obvious gaps for typical agent workflows.
orbuc_btc_healthACheck health of the BTC holdings tracker.
Returns status, database date range, segment count, and record totals.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds concrete output behavior (status, database date range, segment count, record totals), enriching the agent's understanding of what to expect from the call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. The first sentence states the action and resource; the second lists the return fields. Everything earns its place, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema), the description covers the essential return components. It could be slightly more explicit about what 'status' entails or potential error conditions, but it is sufficiently complete for a health-check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already covers everything. Per the rubric, 0 params gets a baseline of 4; the description appropriately omits parameter details and instead focuses on output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Check' with the resource 'health of the BTC holdings tracker', distinguishing it from sibling holdings data tools. It also enumerates the returned fields (status, database date range, segment count, record totals), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly frames the tool as a health check for the BTC tracker, allowing an agent to infer when to use it. However, it does not explicitly mention alternatives or exclusions, such as comparing to orbuc_stablecoin_health, so it stops short of an explicit when-not-to-use guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
orbuc_btc_holdings_currentAGet the latest total BTC held by institutions, broken down by segment.
Segments: public_companies, etf_funds, governments, private_companies,
defi_other, exchanges_custodians.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint, making the safe read-only nature clear. The description adds the segment breakdown and names the segments, which is useful context, but it does not disclose the return format, units, or whether the data updates frequently. With annotations covering the safety profile, a 3 is appropriate; the description adds some but not rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the main action ('Get the latest total BTC...'), and the second sentence lists the segments compactly. No wasted words; every sentence earns its place. This is exemplary conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description covers the core content: what data is returned (total BTC by segment) and the exact segment categories. It does not specify units (e.g., BTC vs. USD) or a typical response shape, but given the simplicity of the tool and strong annotations, it is largely complete. Slight gap on units prevents a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty, so schema coverage is 100% by default. The description's list of segments adds meaning beyond the schema, even though no parameter explanations are needed. The baseline for zero parameters is 4, and the description meets it by providing useful domain context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'the latest total BTC held by institutions, broken down by segment' and lists the specific segments. This gives a specific verb and resource. However, it does not explicitly distinguish itself from the sibling tool 'orbuc_btc_holdings_segments', which could plausibly serve the same purpose, so it loses a point for sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied by the description: use this to get the latest total institutional BTC holdings segmented by category. However, there is no explicit guidance on when to choose this tool over siblings like 'orbuc_btc_holdings_daily' or 'orbuc_btc_holdings_segments', nor any mention of alternatives or exclusions. The context is clear but not explicit about alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
orbuc_btc_holdings_dailyAGet daily BTC holdings time series, optionally filtered by segment.
Args:
segment: public_companies, etf_funds, governments, private_companies,
defi_other, exchanges_custodians. Omit for aggregate totals.
start: Start date YYYY-MM-DD
end: End date YYYY-MM-DD
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ||
| start | No | ||
| segment | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds the behavioral nuance that omitting the segment parameter yields aggregate totals, but it does not disclose other traits such as response format, pagination, default date ranges, or potential errors. This is comparable to the get_calls example where annotations cover safety and the description adds a scoping constraint, justifying a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct: a one-line summary followed by a clear Args block. Every line provides necessary information without fluff. It is well-structured and front-loaded with the action, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity and good annotations, the description covers the essential usage: the data type, filtering, and date range. However, with no output schema, it does not describe the response structure (e.g., fields like date and amount) or what happens when start/end are omitted. This minor gap prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully explain parameters. It does: segment lists all possible values and states 'Omit for aggregate totals,' while start and end are given explicit date format 'YYYY-MM-DD'. This adds significant meaning beyond the raw schema, making it easy for an agent to know valid inputs and behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get daily BTC holdings time series, optionally filtered by segment.' The verb 'Get' plus the resource 'daily BTC holdings time series' is specific and distinguishes it from sibling tools like current, weekly, or segments. The mention of 'aggregate totals' when segment is omitted further clarifies scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: for daily holdings data, with optional filtering by a list of named segments. It implies that omitting segment returns aggregate totals. However, it does not explicitly mention alternative tools or when not to use it (e.g., for current holdings use orbuc_btc_holdings_current), so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
orbuc_btc_holdings_segmentsAGet current BTC holdings per segment.
Each segment includes btc_amount and source.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds 'current' and output fields (btc_amount, source), but no additional behavioral context such as pagination, rate limits, or data freshness beyond what annotations cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first front-loads the core purpose, the second adds essential output detail. No wasted words or redundant restating of the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description includes the key return fields. It remains slightly vague about what 'segment' means or the exact shape of the response, but for a simple read-only tool this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema fully covers parameter semantics. The baseline for 0 params is 4; the description does not need to compensate for any schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('current BTC holdings per segment'), clearly distinguishing it from siblings like orbuc_btc_holdings_current or daily/weekly by focusing on the segment breakdown rather than a single aggregate or time series.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided. The purpose 'per segment' implies a specific use case, but the description does not state when this tool should be preferred over the sibling holdings tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
orbuc_btc_holdings_weeklyAGet weekly aggregated BTC holdings, optionally filtered by segment.
Args:
segment: Segment name (optional)
| Name | Required | Description | Default |
|---|---|---|---|
| segment | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds no additional behavioral context beyond the parameter behavior (optional segment filtering). It does not contradict the annotations, but also does not enrich them with details like output format or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single sentence plus a compact Args list. Every word is functional, with no redundancy or filler. It is well-structured and front-loaded with the main action. No improvement is possible without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single optional parameter and no output schema, the description covers the core purpose and parameter semantics adequately. It does not mention return value format or define 'weekly' (e.g., calendar week vs. trailing 7 days), which would be helpful, but the simplicity of the tool keeps the missing context from being a major gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. The Args section does explain that segment is an optional segment name, adding some meaning beyond the schema's type definition. However, it does not clarify what a segment is, valid values, or the effect of filtering, leaving the parameter semantics only partially specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('weekly aggregated BTC holdings'), and an optional filter ('by segment'). This distinguishes it from sibling tools like daily or current holdings. The verb and resource are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving weekly aggregated data, but it does not explicitly mention when to choose this over the daily or current variants. No alternative tools are named, so the guidance is implied rather than stated. The context is clear from the name and sibling tools, but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
orbuc_stablecoin_aggregateAGet daily aggregate stablecoin data at different levels.
level='total': daily total market cap.
level='symbol': daily breakdown per stablecoin.
level='chain': daily breakdown per chain per symbol.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | total | |
| end_date | No | ||
| start_date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, covering safety behavior. The description adds the concrete behavioral meaning of the 'level' parameter, which goes beyond the annotations. It does not disclose date-handling behavior or return formats, but given the strong annotation baseline, this partial addition is valuable and non-contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, using a short lead sentence and three bullet-like lines for the level options. Every word earns its place, with no filler or repetition. The structure makes the options easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, and the description covers the core level parameter well. However, since there is no output schema, the description is also responsible for indicating what the returned data looks like, which it does not. Date parameters are also left undocumented, making the tool only partially complete despite its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate. It explains the 'level' parameter values clearly but completely omits any semantics for 'start_date' and 'end_date', including format, defaults, or behavior. This leaves two of three parameters undocumented, which is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb 'Get' and specific resource 'daily aggregate stablecoin data', enumerating the distinct level options ('total', 'symbol', 'chain'). This clearly differentiates it from sibling tools like orbuc_stablecoin_coin or orbuc_stablecoin_health, which focus on individual coins or health metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by defining what each level returns, implying this tool is for aggregate daily data rather than single-coin or health queries. However, it does not explicitly state when to avoid using it or name alternative tools for other use cases, so it falls short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
orbuc_stablecoin_chainsAGet stablecoin supply distribution across chains (Ethereum, Tron, Solana, etc.).
Args:
days: Number of days of history (optional)
| Name | Required | Description | Default |
|---|---|---|---|
| days | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover safety (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description's additional value is modest. It explains the 'days' parameter meaning but does not disclose output format, default behavior, or chain list. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the main behavior, and includes exactly one parameter definition. Every word earns its place with zero fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one simple optional parameter and no output schema, the description covers the purpose and parameter adequately. It could mention the default behavior when 'days' is omitted (e.g., all history), but this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description compensates by defining 'days' as 'Number of days of history (optional)', which provides meaning beyond the raw integer/null type. The format and range are not specified, but for a simple optional parameter this is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' with the resource 'stablecoin supply distribution' and a clear scope 'across chains (Ethereum, Tron, Solana, etc.)'. This clearly distinguishes it from sibling tools like orbuc_stablecoin_aggregate (overall aggregate) or orbuc_stablecoin_coin (single coin).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you need a per-chain breakdown of stablecoin supply, use this tool. However, it does not explicitly mention alternatives or provide when-not-to-use scenarios, so guidance is inferred rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
orbuc_stablecoin_coinAGet historical supply data for a specific stablecoin.
Args:
symbol: Stablecoin ticker, e.g. USDT, USDC, DAI (required)
days: Number of days of history
start_date: Start date YYYY-MM-DD
end_date: End date YYYY-MM-DD
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| symbol | No | ||
| end_date | No | ||
| start_date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the description does not need to restate safety. It adds the scope of 'historical supply data' but does not disclose additional behavioral details such as return format, data source, or date handling rules. The description is not misleading but adds limited transparency beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with a clear one-line purpose, followed by a concise parameter list. Every sentence adds value and there is no redundancy or fluff, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple and benefits from strong annotations, but the description lacks details about the output structure (e.g., what fields constitute 'supply data') and does not resolve the symbol-required inconsistency. The overall context is sufficient for a basic understanding, but gaps remain for an agent to invoke it with full confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates by explaining each argument, including examples for symbol and date format. However, it incorrectly marks symbol as required while the schema shows a default of '' and no required parameters. It also does not clarify the relationship between days and start_date/end_date, leaving some ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get historical supply data), the resource (a specific stablecoin), and differentiates from sibling tools like orbuc_stablecoin_coin_latest by emphasizing 'historical' and 'specific'. This makes the tool's purpose immediately obvious and distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for a single stablecoin's historical data rather than aggregate or latest data, but it does not explicitly mention alternatives or provide exclusion criteria. The context is inferable from the phrase 'specific stablecoin' and 'historical', but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
orbuc_stablecoin_coin_latestAGet the latest supply data for a specific stablecoin with chain breakdown.
Args:
symbol: Stablecoin ticker, e.g. USDT, USDC (required)
| Name | Required | Description | Default |
|---|---|---|---|
| symbol | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering safety. The description adds that it returns 'chain breakdown', which gives some output shape context, but does not disclose behaviors like whether all chains are guaranteed, pagination, or error cases. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two succinct sentences plus a compact Args block. The purpose is front-loaded, and every sentence adds value. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read-only tool, the description gives enough context: what data is returned (supply with chain breakdown) and the required parameter. Since there is no output schema, the chain breakdown mention helps the agent anticipate the response shape. Missing details like example output or explicit differentiation from other stablecoin tools, but these are not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the symbol parameter as 'Stablecoin ticker, e.g. USDT, USDC' and explicitly marks it required, adding meaning beyond the schema which only has a default empty string. However, the schema lists no required parameters, so the 'required' note conflicts with the schema definition, slightly reducing clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the latest supply data for a specific stablecoin with chain breakdown', which includes a specific verb (get), resource (latest supply data), and scope (specific stablecoin, chain breakdown). This distinguishes it from siblings like orbuc_stablecoin_latest (likely all stablecoins) and orbuc_stablecoin_aggregate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It only says 'for a specific stablecoin', which implies a per-coin scope but does not explicitly mention alternatives or exclusions. No 'when not to use' or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
orbuc_stablecoin_healthACheck health of the stablecoin market cap tracker.
Returns status, latest date, total market cap, and tracked coins/chains.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so there is no contradiction. The description adds response contents (status, latest date, total market cap, tracked coins/chains) but does not disclose edge cases or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence front-loads the purpose, and the second lists the return fields, making every word earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, rich annotations, and no output schema, the description adequately explains what the tool does and what it returns. The simplicity of the health endpoint makes this complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
This tool has zero parameters, so the schema fully covers parameter semantics. The description does not need to add extra parameter details, earning the baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Check health of the stablecoin market cap tracker,' using a specific verb and resource. It differentiates itself from sibling stablecoin data tools by focusing on tracker status and summarizing the returned fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies diagnostic use, but it does not explicitly say when to use this tool versus siblings like orbuc_stablecoin_latest or orbuc_btc_health. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
orbuc_stablecoin_latestAGet the latest full snapshot of all tracked stablecoins with per-issuer breakdown.
Returns each stablecoin's total_supply_usd, issuer, and per-chain deployment data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 behavioral context by stating it returns the latest full snapshot with per-issuer breakdown and specific fields (total_supply_usd, issuer, per-chain data), which goes beyond the structured annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and includes essential return details. Every word earns its place; there is no unnecessary filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-input, read-only snapshot tool, the description is complete enough: it specifies scope (all tracked stablecoins) and return content (supply, issuer, per-chain data). Without an output schema, the description appropriately summarizes the return shape, though the term 'per-chain deployment data' remains somewhat vague.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is empty, so the description has no parameter semantics to clarify. Per the baseline for zero parameters, a score of 4 is appropriate; the description still adds value by explaining what the no-param call will return.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and clearly identifies the resource: the latest full snapshot of all tracked stablecoins. It further specifies the per-issuer breakdown, which differentiates it from per-coin or aggregate siblings like orbuc_stablecoin_coin_latest or orbuc_stablecoin_aggregate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving the latest complete snapshot of all stablecoins, and lists return fields. However, it provides no explicit guidance about when to choose this tool over alternatives (e.g., for a single stablecoin, use orbuc_stablecoin_coin_latest), and no exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
orbuc_stablecoin_mcapBGet historical daily total stablecoin market cap across all tracked issuers.
Returns daily total_mcap_usd, daily_change_usd, and daily_change_pct.
Source: Orbuc.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| end_date | No | ||
| start_date | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds that it returns specific daily fields and notes the source, but does not disclose additional behavioral details like default date ranges or data update frequency. This adds some value beyond annotations but not rich context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short, front-loaded sentences. It states the purpose, lists returned fields, and notes the source. Every sentence earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and undocumented parameters, the description should compensate by explaining input semantics. It describes the output fields but omits how to use the three optional parameters or any context on selecting this tool among sibling stablecoin tools. The overall completeness is inadequate for effective invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not mention the parameters (days, start_date, end_date) at all. It fails to explain how to specify the date range or how the parameters interact, leaving the agent without guidance on constructing valid requests.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets historical daily total stablecoin market cap across all tracked issuers. It specifies the exact return fields (total_mcap_usd, daily_change_usd, daily_change_pct), distinguishing it from sibling tools like orbuc_stablecoin_latest or orbuc_stablecoin_aggregate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus alternatives. No mention of when to choose it over orbuc_stablecoin_aggregate or orbuc_stablecoin_latest. The description only states what it does, not its intended use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.