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 4/5 across 12 of 12 tools scored. Lowest: 3.3/5.
Tools like orbuc_btc_holdings_current and orbuc_btc_holdings_segments both provide current holdings data, one as aggregate with breakdown and the other as per-segment, which could cause confusion. Similarly, orbuc_stablecoin_aggregate at level='total' overlaps with orbuc_stablecoin_mcap. Most tools are distinct, but these overlapping pairs reduce clarity.
All tools follow a consistent pattern: orbuc_<domain>_<concept>, using 'btc_' and 'stablecoin_' domains. Within each domain, names are systematic, such as orbuc_btc_holdings_current/daily/weekly. Minor inconsistency exists between orbuc_stablecoin_coin_latest and orbuc_stablecoin_latest, but the overall pattern is predictable.
With 12 tools covering two related data domains (BTC holdings and stablecoins), the count is well-scoped. Each tool serves a specific retrieval purpose, and the inclusion of health checks for both domains is appropriate. The number fits comfortably within the ideal 3-15 range.
The server provides comprehensive coverage for a read-only data querying service: current snapshots, historical time series, and segment/chain breakdowns for both BTC holdings and stablecoins. A minor gap is the lack of a tool to dynamically list available segments or symbols, though descriptions provide this information statically.
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 cover safety with readOnlyHint=true and destructiveHint=false. The description adds on top by listing the returned elements (status, database date range, segment count, record totals), providing useful insight into the output. It does not contradict annotations and provides additional 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 purpose ('Check health') and followed by a concise list of outputs. Every word earns its place; there is no fluff 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 simple 0-parameter health check with no output schema, the description covers the purpose and enumerates the key output components. It could be more specific about the nature of 'status' or the response shape, but it is adequately complete for this tool's 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?
The tool has zero parameters, so there is nothing to explain. Schema coverage is trivially 100%, and the baseline for 0-parameter tools is 4. The description adds no parameter-specific details, but none are needed.
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 BTC holdings tracker' which is a specific verb+resource combination. It distinguishes from sibling tools like orbuc_btc_holdings_* and orbuc_stablecoin_health by explicitly naming the BTC tracker, making its 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 implies the tool is for health checks and returns diagnostic information, but it does not explicitly state when to use it or provide alternatives. The context is clear from the name and description, yet there is no explicit when-to-use vs when-not-to-use guidance.
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=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds the segment breakdown detail but does not disclose return format, units, or update cadence. No contradiction with annotations, but little added 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?
Two sentences: one clear statement of purpose and a compact list of segments. No filler, front-loaded, and every word earns 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 zero-parameter signature and rich annotations, the description is largely adequate. It states the data source and breakdown dimension, but with no output schema, it would be improved by specifying the exact return shape (e.g., total plus per-segment fields) or units.
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 takes zero parameters, so there is no parameter schema to enrich. The segment list in the description provides useful output context but does not document parameters. Baseline 4 is appropriate for a no-parameter tool.
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: latest total BTC held by institutions, broken down by segment. It also lists the exact segment values, giving precise scope. However, it does not explicitly differentiate itself from the similarly named sibling orbuc_btc_holdings_segments or note that daily/weekly variants exist.
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 a current-snapshot use case with 'latest' and lists segments, but it provides no explicit when-to-use guidance or alternatives. It does not mention that historical data is available via orbuc_btc_holdings_daily or weekly variants. This is usable but relies on the agent to infer context.
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, idempotentHint, and non-destructive behavior. The description adds behavioral context about the segment omission yielding aggregate totals and the date range parameters, but does not discuss potential pagination, data coverage, or response format, so it adds value without fully covering all behaviors.
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 concise, with one sentence and a structured Args block. Every line adds useful information, and the format is easy to parse. No redundancy with annotations or schema.
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 no output schema, the description hints that the tool returns a 'time series' but does not specify the exact response structure, units, or potential pagination. However, for a relatively simple read-only tool with all parameters well-documented, this is mostly sufficient. Sibling tool names provide additional context.
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 zero description coverage, and the description fully compensates by detailing each parameter: segment lists all valid enum-like values, start/end specify the YYYY-MM-DD format, and the behavior of omitting segment is explained. This goes well beyond the bare schema.
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 daily BTC holdings time series, optionally filtered by segment', providing a specific verb, resource, and optional parameter. The term 'daily' distinguishes it from sibling tools like weekly or current. The list of segment values further clarifies the 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 gives clear context for using the segment filter and explains that omitting it returns aggregate totals. However, it does not explicitly mention when to use this over alternative tools (e.g., holdings_weekly or holdings_current), so no explicit exclusions or alternatives are provided.
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=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the tool's safety profile is well established. The description adds value by specifying the response content ('Each segment includes btc_amount and source') and the 'current' temporal scope, which are behavioral traits beyond the annotations. However, it doesn't elaborate on potential side effects, authentication requirements, or data freshness, though the annotations reduce the burden.
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 and front-loaded: 'Get current BTC holdings per segment.' It then briefly explains the return content without any fluff. Both sentences are essential and directly informative, achieving maximum efficiency with zero wasted words.
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 tool with no parameters and no output schema, the description provides adequate context: it states the purpose and describes the response shape (each segment has btc_amount and source). It could add minor details like the data type of btc_amount or whether the response is an array, but given the tool's simplicity and the strong annotations, the existing description is nearly complete. The openWorldHint could imply evolving data, but that is annotated.
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 parameters, the input schema is empty and there is nothing to document. The 100% schema coverage trivially means no parameter info is needed. The description does not attempt to explain any parameters because none exist. As per the baseline for 0-param tools, this is a solid score, and the description's mention of output fields does not relate to parameter semantics.
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 function: 'Get current BTC holdings per segment.' This uses a specific verb (Get) and identifies the resource (BTC holdings per segment), differentiating it from sibling tools like daily or weekly holdings by focusing on segment-level data. It also specifies the output fields (btc_amount and source), making the purpose unmistakable.
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 context through the word 'current' and 'per segment,' but it does not explicitly state when to use this tool versus alternatives like daily or weekly holdings. No exclusions or alternative tool names are mentioned. The context signals show sibling tools, but the description itself offers no guidance on selection, leaving the agent to infer from the name and description.
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, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds that the output is aggregated weekly and can be filtered by segment. However, it doesn't add further behavioral traits like return format or limitations. This meets the baseline with annotations present.
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 clear parts: a purpose sentence and a simple Args list. Every word adds necessary information, and the main verb+resource appears early. No redundant text or 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?
For a simple read-only tool with one optional parameter and no output schema, the description provides the essential information: what data (weekly BTC holdings), when to use (weekly aggregation), and the filter option. The only gap is a definition of 'segment', but that is likely domain-specific and possibly covered by sibling tools like 'holdings_segments'.
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 schema for 'segment' has no description (0% coverage). The description's Args section says 'Segment name (optional)', which mirrors the schema. It clarifies the parameter is optional and used for filtering, but doesn't define what a segment is nor the expected value format. The description only partially compensates for missing schema descriptions.
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 starts with 'Get weekly aggregated BTC holdings', which is a specific verb + resource + time aggregation. This clearly distinguishes it from siblings like daily, current, and segments. The optional 'filtered by segment' further refines the purpose.
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 phrase 'weekly aggregated' clearly signals when to use this tool (for weekly data), and 'optionally filtered by segment' gives a usage condition. It doesn't explicitly name alternatives, but sibling names like 'daily' and 'current' are context clues. 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_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=true and destructiveHint=false, so the safety profile is fully covered. The description adds the 'daily' aggregation aspect and level meanings, but it does not disclose any additional behavioral traits such as date range handling, response shape, or limitations. This aligns with the annotations without contradiction, but the description adds no extra safety-relevant 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 concise and structurally clear. A one-sentence summary is followed by three bullet points, each defining a level with a short phrase. No unnecessary words 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 tool with three optional parameters and no output schema, the description covers the level dimension well but omits date parameter semantics. It also does not describe the return structure, which might be acceptable given the tool's simplicity, but the missing date guidance creates a gap in completeness.
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 level parameter is well documented with its three allowed values (total, symbol, chain), which goes beyond the schema's bare string type. However, start_date and end_date are not described at all; their format, default behavior, or interaction with the level is left entirely to the schema's property names and defaults. Since schema coverage is 0%, the description only partially compensates.
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 starts with a specific verb ('Get') and clearly identifies the resource ('daily aggregate stablecoin data') and its varying granularity. The three bullet points explicitly define the level parameter values, making the tool's purpose unmistakable and differentiating it from sibling tools like orbuc_stablecoin_coin or orbuc_stablecoin_latest.
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 aggregate daily metrics at different granularities, but it does not explicitly name alternatives or state when not to use this tool. The context from sibling tool names suggests a broader family, yet no direct comparison is made.
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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which convey a safe read operation. The description adds no additional behavioral context such as return format, pagination, or historical data boundaries. Since annotations cover the safety profile, the low bar is met, but no extra value is added.
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 appropriately sized: one clear purpose sentence and one parameter explanation. Every word earns its place, with no redundancy. The 'Args' block is clean and 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 (one optional param, no output schema), the description provides the core purpose and parameter meaning. However, it omits any description of the return value (e.g., time series vs. current snapshot) and lacks usage exclusions or alternatives, leaving gaps for an agent deciding how to interpret results.
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 compensate. It explains 'days' as 'Number of days of history (optional)', which adds meaningful semantic context beyond the schema's bare integer/null definition. This is sufficient for the single parameter, though it doesn't describe default behavior or accepted range.
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 function with a specific verb ('Get') and resource ('stablecoin supply distribution across chains'), explicitly listing example chains (Ethereum, Tron, Solana). This distinguishes it from sibling tools like orbuc_stablecoin_aggregate and orbuc_stablecoin_coin, which are likely per-coin or aggregate distributions.
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 want cross-chain stablecoin supply distribution) but does not explicitly mention alternatives or when not to use this tool. It lacks direct guidance about selecting this tool over siblings, though the chain-specific wording provides some context.
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=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false. The description adds no additional behavioral context such as rate limits, authentication, or edge cases, but it is consistent with annotations and reveals the return intent is historical supply data.
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 concise: one sentence for purpose plus a clean Args list. Every line contributes useful information without redundancy or 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?
Annotations and parameter details cover much of the context, but there is no output schema, and the description does not mention return format or default behavior when only symbol is provided. It is adequate but has clear gaps versus the tool's complexity.
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 all four parameters with examples and formats, which is essential since the schema provides no descriptions. However, it labels symbol as 'required' while the schema has a default and no required list, causing minor 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 'Get historical supply data for a specific stablecoin' with a specific verb and resource, distinguishing it from siblings like orbuc_stablecoin_coin_latest (latest data) and orbuc_stablecoin_aggregate (aggregate data).
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 use for per-coin historical supply data but provides no explicit guidance on when to choose this over sibling tools or any exclusion criteria. It gives context but no direct alternatives.
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 and idempotentHint, so the safety profile is clear. The description adds that the result includes supply data with chain breakdown, which is meaningful domain context beyond the annotations, though it does not detail response shape or edge cases.
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 tightly written: one main sentence followed by a concise Args block. No wasted words, and the key 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?
For a simple one-parameter read-only tool with good annotations, this description is largely complete. It conveys the purpose and the main parameter, though it could briefly mention output format or distinguish itself more explicitly from sibling tools.
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 no descriptions in the input schema, the description compensates by providing a clear meaning for 'symbol' with concrete examples (USDT, USDC). However, it states the parameter is 'required' while the schema marks it optional with a default, making the guidance partially misleading.
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 specific verb ('Get'), resource ('latest supply data'), and scope ('specific stablecoin with chain breakdown'). This clearly distinguishes it from sibling tools like aggregate or health, 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 phrase 'for a specific stablecoin with chain breakdown' implies the intended use case, but it lacks explicit guidance on when to choose this over alternatives such as orbuc_stablecoin_latest or orbuc_stablecoin_coin. No when-not-to-use or alternative tool names are given.
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, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds behavioral context by listing the response contents (status, latest date, total market cap, tracked coins/chains), giving the agent clear expectations. It does not contradict annotations and provides value beyond them, though it could be more thorough about edge cases or status semantics.
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: the first states the purpose, the second lists the return values. It is concise, front-loaded, and every sentence earns its place. No unnecessary words 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 simple zero-parameter health check with rich annotations and no output schema, the description sufficiently covers purpose and return values. The list of outputs helps the agent understand what to expect without requiring an output schema. The description is complete given the tool's simplicity and the annotation coverage.
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 takes zero parameters, so the input schema fully covers parameter semantics. The baseline for 0 params is 4, and the description appropriately adds no parameter details since none exist. This is a standard, acceptable score.
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 identifies the tool as a health check for the stablecoin market cap tracker, with a specific verb ('Check') and resource. It lists return values, distinguishing it from sibling data-retrieval tools like orbuc_stablecoin_mcap or orbuc_btc_health. This is a specific, non-tautological purpose.
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 verifying tracker health but does not explicitly state when to use it vs alternatives or provide exclusions. Sibling tools exist for specific data queries, but no direct comparison is made. The purpose is clear enough to infer the intended use, but explicit guidance is missing.
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=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds behavioral context by listing return contents (total_supply_usd, issuer, per-chain deployment data) and characterizing the data as a 'latest' snapshot, which is useful beyond the 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 long, front-loaded with the primary action and scope, and directly followed by return field details. Every sentence adds value with no redundancy or 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, the description carries the burden of explaining return values, which it does by listing the fields. It clearly distinguishes from siblings and covers the essential behavior. However, it could be slightly more explicit about what 'per-chain deployment data' entails, but it is adequate for a simple snapshot 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 input schema is trivially 100% covered. Per the baseline for 0 params, a score of 4 is appropriate; the description does not need to add parameter semantics that do not exist.
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 starts with 'Get the latest full snapshot of all tracked stablecoins' which clearly states the action (get snapshot) and the resource (all tracked stablecoins). It distinguishes from siblings like orbuc_stablecoin_coin (specific coin) and orbuc_stablecoin_aggregate (likely aggregated data) by emphasizing 'full snapshot' and 'per-issuer breakdown'.
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 when to use this tool (when you need the latest full snapshot of all stablecoins), but it does not explicitly mention alternatives or when not to use it. Given multiple sibling tools, explicit exclusions or references to alternatives would improve clarity.
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 meaningful context by specifying that this is daily historical data, covers all tracked issuers, and lists the exact return fields (total_mcap_usd, daily_change_usd, daily_change_pct). It also credits the source (Orbuc), providing provenance. No contradiction with annotations is present.
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 sentences: the first states purpose, the second lists return fields, and the third gives the source. Every sentence earns its place with no fluff or repetition. It is appropriately front-loaded with the core action.
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?
While the description clarifies the output fields, it omits essential parameter semantics. Given there is no output schema and parameter descriptions are absent, an agent cannot confidently invoke the tool with appropriate dates or day counts. The tool has three optional nullable parameters, and the description does not explain their meaning or default behavior.
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 schema has 0% description coverage for its three parameters (days, end_date, start_date), and the tool description provides no explanation of what these parameters do, their format, or how they interact. An agent has no way to know how to construct a valid query, such as date format or whether 'days' overrides the date range.
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 first sentence clearly states the verb (Get) and resource (historical daily total stablecoin market cap across all tracked issuers), which distinguishes it from sibling tools that target specific coins (orbuc_stablecoin_coin) or latest values (orbuc_stablecoin_latest). The scope 'across all tracked issuers' is explicit.
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 guidance is provided about when to use this tool versus alternatives. The phrase 'across all tracked issuers' implies it is for aggregate totals, but no explicit comparison or exclusion is given for sibling tools like orbuc_stablecoin_aggregate or orbuc_stablecoin_latest.
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!
