USDD Analytics MCP

Official

by decentralized-usd

Overview Schema Related Servers Score Discussions

JavaScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation3/5
Most tools target distinct metrics, but get_public_protocol_overview and get_public_protocol_overview_info are nearly identical in name and purpose, and get_earn_apy vs get_public_dsr_apy both concern APY with unclear differences. The descriptions help somewhat, but the boundaries are not clear.
Naming Consistency5/5
All tool names follow a consistent get_<object> pattern using snake_case. There are no mixed conventions or alternate verb styles, making the naming predictable.
Tool Count5/5
The 14 tools cover a reasonable breadth of USDD analytics without feeling bloated or sparse. Each tool addresses a specific data need, and the count fits the typical well-scoped range.
Completeness4/5
The set covers core analytics: supply, APY, collateral, overview, and vault details. Minor gaps exist, such as no per-ilk collateral history (explicitly noted) and no price data, but the primary workflows are supported.
Average 3.7/5 across 14 of 14 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 55 commits in the last 12 weeks
- Last stable release on June 4, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only mentions 'Public REST', implying a read-only public endpoint, but fails to disclose pagination, response format, or whether this is a snapshot or a dynamic configuration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise fragment, but it is not a complete sentence and omits a verb. It wastes no words but leaves out essential context that a full sentence could provide.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of many closely named sibling tools and no output schema, the description is incomplete. It does not explain what constitutes a 'configuration list' or how this tool differs from get_collateral_history, get_latest_collateral, or get_public_protocol_overview.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema fully covers the parameter surface. The description adds no parameter info, but with zero params the baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource as a list of vault collateral configurations, but it lacks a clear verb and does not distinguish this from sibling tools like get_latest_collateral or get_chain_collateral_history. The phrase 'vault collateral configuration list' is essentially a restatement of the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any exclusions, alternatives, or context, leaving the agent to guess how it differs from other getter tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but only states that it is a 'public REST protocol overview' with 24h daily-change fields. It does not disclose return format, pagination, or any access requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a concise 7-word phrase that is front-loaded with the key identifier. It is appropriately sized for a zero-parameter tool, though it reads as a fragment rather than a full sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple zero-parameter signature, the description conveys the basic nature, but the proximity of a sibling tool with the same root name means more context is needed to disambiguate. The mention of '24h daily-change fields' partially addresses this.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, and the schema coverage is effectively 100%, so the baseline is 4. The description adds no parameter-specific detail but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Public REST protocol overview with 24h daily-change fields' clearly identifies the resource as a protocol overview and adds a differentiating scope (24h daily-change fields) relative to sibling get_public_protocol_overview. However, the verb is implicit and the term 'info' is not fully clarified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 vs the nearly identically named sibling get_public_protocol_overview. It does not state alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It does convey that the output is a single number and that the data is 'raw', which provides some insight. However, it does not mention whether the value is live, cached, or subject to updates, nor does it clarify any potential rounding or formatting behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single succinct phrase that wastes no words and immediately conveys the core purpose. It is appropriately terse for a tool with no parameters and a simple output. Every word in the phrase contributes meaningful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse for the context of a tool family with overlapping names (get_usdd_supply, get_total_supply, get_susdd_supply). It does not explain what makes 'circulating supply' distinct from these alternatives, nor does it provide any context about the data source or usage scenario. This incompleteness could lead an agent to select the wrong tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty. The description correctly omits parameter details, and no additional semantic explanation is needed. The baseline score of 4 applies for no-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as 'USDD circulating supply' and implies a retrieval operation despite missing an explicit verb. It distinguishes from total supply concepts through the word 'circulating', though it doesn't explicitly reference sibling tools. The phrase 'single number' adds clarity about the expected output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus closely related siblings like get_usdd_supply or get_total_supply. The description does not explain the distinction between circulating and total supply or state any prerequisites. An agent would have to infer the appropriate context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it offers only the phrase 'Public REST' hinting at public access. It does not explicitly state that the tool is read-only, safe, or non-mutating, nor does it disclose response format, pagination, or potential rate limits. The behavioral profile is largely implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence and very concise. It front-loads the key resource and data categories. Minor issue: 'Public REST' is slightly awkward and not grammatically refined, but the sentence earns its place by specifying the data scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter tool, the description covers the essential data categories, but it lacks detail on historical depth, response structure, or how it differs from get_earn_apy. Since there is no output schema and no annotations, the description is the sole source of context and remains incomplete for fully guiding an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already provides complete coverage (100%) and there is nothing to clarify. The description adds context about the kinds of data returned (current, average, per-chain history), which is useful, aligning with the baseline of 4 for no-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (DSR APY) and the action (get current, average, and history). It distinguishes itself from siblings like get_earn_apy by specifying DSR APY rather than generic earn APY, making the purpose 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of scenarios that favor this tool or comparisons with sibling tools like get_earn_apy, leaving the agent without clear selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey the tool's safety profile. It states 'Public REST', which implies read-only behavior and no authentication, and 'detail overview' suggests a non-mutating operation. However, it does not explicitly state that no side effects occur, nor does it describe rate limits or response format, leaving some behavioral ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential information without redundancy. Every word contributes meaning, and the structure is immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of parameters and output schema, the description adequately covers the tool's purpose and expected return content. It lists the three main data components (allocations, earnings, vault info), which is sufficient for a simple read-only endpoint. However, it could be more complete by explicitly stating that it returns a snapshot of the current state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% with an empty object. According to the rubric, the baseline for 0 params is 4. The description adds no parameter details (none needed) but does provide context about the response content (allocations, earnings, vault info), which enriches the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (Smart Allocator) and the nature of the operation (detail overview), while also listing the key data areas (allocations, earnings, vault info). This distinguishes it from sibling tools that focus on other metrics like APY or supply. However, it lacks a strong verb like 'retrieves' or 'returns', relying on the tool name for the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 description merely states it is 'Public REST' without explaining the use case or any exclusions. There is no mention of when another tool would be preferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey the read-only, non-destructive nature of the tool. The word 'overview' and the listed data fields implicitly indicate a read operation, but it does not explicitly state 'read-only' or disclose any potential latency, caching, or data freshness. For a simple getter, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence that is front-loaded with the resource and lists the key fields. There is no redundancy or filler, and it is appropriately sized for a simple overview tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema, so the description need not explain returns in detail. The listed fields provide some clarity, but the sibling tool get_public_protocol_overview_info suggests a potential distinction between overview and info that is not addressed. The description is minimally complete but leaves some ambiguity about the exact response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing to document. The baseline for a parameterless tool is 4, and the description does not need to add parameter details. It correctly implies no inputs are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource as 'Public REST protocol overview' and enumerates the contained fields (total supply, TVL, Earn TVL, APY). This distinguishes it from siblings like get_earn_apy or get_total_supply, which target individual fields. However, it lacks an explicit verb (e.g., 'retrieves') and does not clarify the distinction from the similarly named get_public_protocol_overview_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the word 'overview' and the combined fields, suggesting it is meant for a high-level summary. No explicit 'use this when' or alternatives are mentioned. Sibling tools like get_earn_apy or get_total_supply are not referenced, so guidance is minimal but not entirely absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the output type (single number) but does not mention whether this is a read-only operation, any rate limits, data freshness, or how the 'raw' value is derived. For a simple getter, this is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences) and front-loads the essential function. However, the second sentence ('Call this MCP tool...') is somewhat redundant with the first, adding little new information. Still, it remains compact and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description provides the basic purpose and return type. However, it does not explain what 'raw' means in contrast to other supply metrics (e.g., circulating supply) or when to prefer it over sibling tools, which is relevant context given the many similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers parameter semantics (there are none). The description does not need to elaborate on parameters, and its mention of 'single number' hints at the return type, which is sufficient in this context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns 'Raw USDD total supply (single number)', specifying both the resource and output format. This distinguishes it from siblings like get_circulating_supply and get_usdd_supply, which likely return different supply metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Call this MCP tool for current raw supply stats' gives a direct use case, but it lacks any explicit comparison to alternatives or exclusions. It does not mention when not to use this tool or why it is preferred over similar supply tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It explains the scope (per chain) and temporal granularity (daily), which is useful, but it doesn't describe return format, units, or any behavioral caveats. Still, for a zero-parameter read-only getter, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is just two sentences, efficient and front-loaded. It immediately states the core output and then adds a clarifying scope distinction, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool without an output schema, the description sufficiently explains what is returned (daily total collateral per chain) and clarifies its scope. It could mention time range or units, but it is largely complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and an empty input schema, so the baseline is 4. The description doesn't need to add parameter details, and no parameter-related ambiguity exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns a daily time series of total collateral value per chain, and explicitly distinguishes it from per-ilk vault history. However, it doesn't explicitly differentiate from the sibling tool get_chain_collateral_history, which could be a close alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use for protocol-wide, chain-level collateral history and explicitly states what it is not (per-ilk vault history), giving some context. But it doesn't mention when to use this tool over siblings or provide explicit alternatives, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses that the tool is 'Public REST' (no auth likely) and indicates the data is keyed by chain and interval. However, it does not describe the response format, pagination, or any rate limits, leaving some behavioral aspects implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the core purpose, and contains no redundant information. Every clause adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter schema with enums and the absence of an output schema, the description adequately explains the tool's purpose and keying. It could be slightly more explicit about the returned data shape, but the tool name and 'historical series' clarify the general return type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by mapping the interval enum values to chart periods ('7D/1M/6M/1Y') and stating that the tool is 'keyed by chain and interval'. This goes beyond the bare enum names in the schema, though it doesn't elaborate on each parameter individually.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as providing per-chain historical series for chart periods (7D/1M/6M/1Y) and explicitly distinguishes it from ilk-based tools by stating 'not by ilk'. It lacks an explicit verb but the resource and scope are specific, making the purpose understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it is for per-chain historical chart data, and the phrase 'not by ilk' provides a negative usage guideline (avoid if you need ilk-specific data). It does not explicitly name alternatives like get_collateral_history, but the distinction is evident from sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It states 'Public REST', indicating a read-only operation with no authentication, and 'snapshot' further confirms a non-destructive read. The explicit chain constraint also clarifies valid inputs, though it does not detail response structure or potential limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of nine words, front-loaded with the core function ('Public REST per-chain collateral snapshot') and then specifying constraints. There is no redundancy or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, read-only), the description adequately covers the purpose and constraints. It does not describe the response format, but for a straightforward snapshot tool with clear input validation, this is a minor gap. The description is sufficiently complete for an agent to select and call the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'chain' is fully enumerated in the schema (tron, eth, bsc), so the description's restatement adds little additional semantic value. It does reinforce the per-chain context, but the schema already specifies the allowed values, leaving the description to simply repeat them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a per-chain collateral snapshot, explicitly listing valid chains (tron, eth, bsc). This distinguishes it from sibling tools like get_collateral_history by emphasizing 'snapshot' versus historical data, 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through 'per-chain snapshot' but does not explicitly state when to use it instead of sibling history tools or alternative collateral tools. There is no direct 'use this for current collateral' guidance, only an implied contrast with historical data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It specifies that the tool returns APY per chain, which adds behavioral scope, but it does not disclose the return format, whether values are percentages or decimals, or any side effects. For a simple read operation this is minimally adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the resource and purpose. There is zero filler or redundancy, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description covers purpose and usage well. However, it does not hint at the return structure or units, which would be useful for interpreting the result. Still, it is sufficiently complete for tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds context about the chains covered (TRON, ETH, BSC), which helps the agent understand the tool's fixed scope, but there are no parameters to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: returns USDD Savings APY for TRON, ETH, and BSC. It uses a specific verb-resource pairing and distinguishes itself from sibling tools focused on supply or collateral metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent when to call it: 'Call this MCP tool when comparing Earn rates across chains.' It does not mention alternatives or exclusions, but the context is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It reveals that the data is daily and per-chain, which is helpful, but it does not specify the output format, any pagination or limits, or how the supply is aggregated (e.g., combined USDD and sUSDD in one series vs. separate series). This is modest disclosure for a read-only data tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose and followed by an alternative tool reference. Every sentence contributes value with no redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a simple no-parameter tool, covering what data it returns, the frequency, and the grouping. However, it could be more complete by mentioning the distinction from the single-supply sibling tools (get_usdd_supply, get_susdd_supply) to clarify whether this is the only historical option.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts no parameters, and the input schema is empty. The description does not need to explain parameter semantics; it names the two assets (USDD and sUSDD) and the per-chain breakdown, which adds context beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a daily time series of USDD and sUSDD supply per chain, using a specific verb ('time series') and resources. It also distinguishes from the sibling get_collateral_history by explicitly directing users there for collateral value history, 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance to use get_collateral_history instead when the need is collateral value history, which serves as a clear alternative. However, it does not differentiate from sibling tools like get_usdd_supply or get_susdd_supply, which may represent current supply values rather than historical series, leaving some ambiguity about when to choose this tool over those.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It states that the supply is per-chain and excludes sUSDD, which adds context beyond the tool name. However, it does not mention output format, data source, or any limitations, leaving some ambiguity about what exactly will be returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and scope, and contains no unnecessary information. Every word contributes to understanding the tool's purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description sufficiently conveys what the tool does and when to use it. While it might benefit from clarifying which chains are included or the exact return structure, the essentials are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema trivially covers 100% of parameter documentation. Per rubric, a baseline of 4 applies when no parameters exist, and the description adds no parameter semantics because none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'USDD supply broken down by chain, excluding sUSDD.' It uses a specific verb and resource, and distinguishes from sibling tools like get_susdd_supply by explicitly excluding sUSDD and highlighting per-chain distribution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Call this MCP tool for per-chain USDD distribution.' It also excludes sUSDD, implying a boundary against using it for sUSDD data. However, it does not explicitly name alternative sibling tools, so it misses the 'when not to use' guidance at the highest level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the disclosure burden. It explains that the output is a chain-level breakdown of sUSDD total supply, which is the core behavior. It doesn't mention return format or potential caveats, but for a zero-parameter getter this is sufficient and adds the chain dimension beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, both useful. The first states the core function; the second provides a use case (Earn participation analytics). 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.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read tool with no output schema, the description adequately explains what it does and when to use it. It could mention response format, but the chain breakdown is self-explanatory. The description is complete enough for an agent to select and invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score is 4. The description adds no parameter details because none are needed; the schema already covers 100% of parameters (none).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns sUSDD total supply broken down by chain, which is a specific resource and scope. This distinguishes it from siblings like get_usdd_supply (likely USDD) and get_total_supply (generic) by narrowing to sUSDD and adding the chain breakdown.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use this tool for analytics on Earn participation per chain, providing a concrete use case. It does not name alternatives or state when not to use it, but the context is clear enough to guide selection among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![usdd-skills MCP server](https://glama.ai/mcp/servers/decentralized-usd/usdd-skills/badges/card.svg)](https://glama.ai/mcp/servers/decentralized-usd/usdd-skills)

Score Badge

Copy to your README.md:

[![usdd-skills MCP server](https://glama.ai/mcp/servers/decentralized-usd/usdd-skills/badges/score.svg)](https://glama.ai/mcp/servers/decentralized-usd/usdd-skills)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/decentralized-usd/usdd-skills'

If you have feedback or need assistance with the MCP directory API, please join our Discord server