flare-mcp

Server Quality Checklist

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

Latest release: v0.4.0
Disambiguation4/5
Tools like 'fassets_system_state' and 'get_fassets_status' have overlapping purposes (both query FAssets system state), though descriptions distinguish them. Similarly, 'fdc_get_attestation_proof' and 'get_fdc_proof_status' could be confused. Overall, most tools are clearly distinct.
Naming Consistency3/5
Naming conventions are mixed: some use 'fassets_', 'fdc_', 'get_' prefixes inconsistently. While snake_case is consistent, the lack of a uniform verb_noun structure (e.g., 'fassets_agent_status' vs 'get_fassets_status') creates some inconsistency.
Tool Count5/5
15 tools is well-scoped for a domain-specific server covering FAssets, FDC, FTSO, and related Flare functionality. Each tool serves a distinct purpose without being excessive.
Completeness4/5
The tool set covers key areas like FAssets status, FDC proofs, FTSO feeds, and balances. Minor gaps exist (e.g., lack of FAssets mint/redeem operations, no governance tools), but the surface is reasonable for an informational/query-focused server.
Average 3.5/5 across 15 of 15 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 16 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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 exist, so the description must convey behavioral traits. It only states the source (Flare Data Availability layer) but omits side effects, rate limits, data freshness, or any caveats about the 'recent historical' time window.
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 concise sentence without wasted words. It is front-loaded with the key action. Slight improvement would be adding structure to pack more information without increasing length.
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 3 parameters, no output schema, and no annotations, the description is incomplete. It does not explain FTSO results, the response format, or how parameters affect the query, leaving significant gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
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 hints that feed_id accepts name or bytes21 id, but does not explain the meaning of rounds (number of entries), network (mainnet/coston2), or what the output contains. This is insufficient for agent understanding.
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 retrieves recent historical FTSO results for a specific feed, differentiating it from siblings like get_ftso_feed (current feed) and get_ftso_feeds_all (list feeds). It mentions querying by name or bytes21 id, adding specificity.
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 versus alternatives, no prerequisites, no limitations on data recency or availability, making it hard for an agent to decide usage context.
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?
No annotations are provided, so the description must fully inform behavior. It discloses the tool is a deterministic resolution and existence check, but omits details like read-only nature, required permissions, side effects, or what the response contains. For a read-like operation, a readOnlyHint would be expected. The description is insufficient.
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 with no wasted words. It is front-loaded with the verb 'Resolve'. However, it could be split into two sentences for clarity, and the technical reference 'via the MasterAccountController' may be unnecessary overhead. Still, it is efficient.
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 tool has two parameters and no output schema. The description only states the tool 'reports whether the Smart Account exists,' leaving the agent uncertain about the return format (e.g., boolean, address, full object). The lack of detail on resolution output and how to interpret results significantly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no explanation for the two required parameters. The schema provides types and patterns, but the description does not clarify what 'xrpl_address' or 'network' represent in the tool's context. The agent must infer meaning from names alone.
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 resolves a Flare address from an XRPL account and reports on-chain existence. The verb 'resolve' and specific resource 'Smart Account' make the purpose distinct. The mention of 'MasterAccountController' adds technical precision. It differentiates from sibling tools like 'get_flr_balance' or 'fassets_system_state'.
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 on when to use this tool versus alternatives. The description does not specify prerequisites, typical use cases, or scenarios where it should be avoided. The agent receives no help in deciding between this and sibling 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?
No annotations provided, so description must disclose behavioral traits. It implies read-only scanning but does not state idempotency, safety, permissions, rate limits, or error behavior. Minimal disclosure beyond listing outputs.
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?
Single sentence of 30 words, efficient and front-loaded with the main action. No wasted words, but could be more structured for readability.
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?
Description covers main outputs (FCC deployment status, FDC/Relay contracts, full registry) but lacks return format or structure. Without output schema, more detail on what 'reports' looks like would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and description provides no extra meaning for the 'network' parameter beyond repeating the default value. Does not explain enum options or when to choose each network.
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?
Verb 'scan' and 'reports' clearly indicate read operation. Specifies resource (FlareContractRegistry) and contract types (PMW, TEE, compute extensions, FDC/Relay). Distinguishes from sibling tools like fassets_* or fdc_* which handle other Flare subsystems.
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 explicit guidance on when to use this tool vs alternatives. Does not mention prerequisites or exclusion criteria. The reference to 'post-STP.13' provides context but not usage boundaries.
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?
No annotations are provided, so the description must carry behavioral disclosure. It only states what data is returned but does not confirm read-only nature, authentication needs, rate limits, or any side effects. As a state query, it is likely read-only, but this is not explicit.
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 that packs multiple key data fields without redundancy. However, it is slightly dense and could benefit from slight restructuring for readability. Still, no filler words.
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 no output schema, the description covers many return fields but does not specify data types or structure. Enums parameters are simple. For a state query tool, this is adequate but not fully complete—e.g., it omits any notes on performance or consistency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% (no parameter descriptions in schema). The tool description does not add any meaning beyond the enum values—it does not explain what 'asset' or 'network' represent or how they affect the output. The description lists output fields but not parameter semantics.
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 explicitly states it provides 'Global FAssets system state for an asset' and enumerates specific data fields (total minted, agent count, lot size, minting cap/pause, collateral, redemption queue). This clearly differentiates it from sibling tools like fassets_agent_status which focuses on individual agents.
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 explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites, limitations, or scenarios where this tool is preferred. Sibling tools like get_fassets_status exist but no comparison is provided.
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 provides useful behavioral details: it outputs collateral ratios, minting capacity, minted/reserved amounts, and liquidation status, sorted by risk. It does not disclose side effects (presumably read-only) but adds significant context beyond the schema.
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 dense sentence with no wasted words, front-loading the action and key output details. Every word adds value.
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 no output schema, no annotations, and three parameters, the description is incomplete. It omits parameter semantics and return structure details, leaving significant gaps for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description fails to explain any of the three parameters (asset, network, max_agents). The agent must infer their meaning from names and enums, which is insufficient.
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 lists FAssets agents with specific fields (collateral ratios, minting capacity, etc.) and sorting (by vault collateral ratio, riskiest first), distinguishing it from sibling tools like fassets_liquidation_scanner or fassets_system_state.
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 explicit guidance on when to use this tool versus alternatives such as fassets_liquidation_scanner or get_fassets_status. The description implies it's for listing agents but doesn't specify exclusions or prerequisites.
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 correctly identifies it as a read operation. It does not disclose potential errors, response format, or other behavioral traits like rate limits.
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?
Single, front-loaded sentence with no wasted words. Highly concise.
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 omits the output format, which is crucial since there is no output schema. It also inaccurately restricts network options, making it incomplete for the full range of supported networks.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description mentions both parameters ('EVM address', 'Flare mainnet or Coston2 testnet'), adding context beyond the schema. However, it doesn't fully clarify the network options.
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 it retrieves native FLR and wrapped WFLR balances for an EVM address. However, it only mentions two networks (Flare mainnet, Coston2 testnet) while the schema supports four (including songbird and coston), causing a mismatch.
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 for balance queries but provides no guidance on when not to use or alternatives among sibling tools. Context is clear but not explicit.
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. The description mentions premium/x402 payment but does not disclose behavioral traits like data freshness, rate limits, side effects, or authentication requirements beyond the payment condition.
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 efficiently written in two sentences, conveying the core purpose and the free condition. The placement of 'PREMIUM (x402)' slightly disrupts flow but is minor.
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's complexity (scanner, premium, multiple parameters) and lack of output schema, the description omits details on return format, ordering, pagination, and risk interpretation. It covers core metrics but not full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25% (only x402_payment has a description). The description does not elaborate on asset, network, or max_agents parameters, leaving ambiguity despite the enums for asset and network.
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 it scans liquidation risk for FAssets agents, ranks them, and lists specific per-agent metrics. It distinguishes itself from siblings like fassets_agent_status by focusing on liquidation risk and live prices.
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 mentions when it is free (x402 not enabled) but does not provide explicit guidance on when to use this tool versus alternatives or when not to use it.
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?
Discloses the local Merkle proof verification and trustlessness regarding the DA response. Without annotations, this provides good behavioral context, though it omits potential errors or permissions.
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?
Single sentence that front-loads the action and includes key details (verification, trustless). Could be split for readability but is acceptably concise.
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?
Covers the core purpose and verification aspect adequately, but lacks parameter descriptions and any indication of return value or error states. Output schema is absent, so description should compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no explanation of the three parameters (network, voting_round_id, abi_encoded_request) despite 0% schema coverage. The agent must rely entirely on the schema for parameter meaning.
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 retrieves and locally verifies an FDC attestation proof from the Data Availability layer, distinguishing it from siblings like fdc_request_attestation (which likely only requests) and fdc_bulk_proof_bundle (bulk).
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 for retrieving and verifying a single proof for a finalized round, but does not explicitly compare to alternatives or provide 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates a read operation ('Get'), which is clear. However, it does not disclose potential side effects or error behaviors, nor does it mention any authentication or rate limits. For a simple getter, this is minimally adequate but lacks depth.
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 20 words, front-loaded with the action and key result. Every word earns its place, with no redundancy or filler.
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 moderate complexity (two parameters, no output schema), the description states what is returned (Merkle root and finalization status) but not the format. It omits constraints like the positive integer requirement for voting_round_id. It is partially complete but leaves gaps that could confuse an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning no parameter descriptions in schema. The description adds no additional meaning to the parameters 'voting_round_id' and 'network'. It mentions 'voting round' but does not specify that the ID must be a positive integer, nor does it explain the network enum. The description fails to compensate for the lack of schema documentation.
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 verb 'Get', the resource 'FDC (protocol id 200) Merkle root and finalization status for a voting round', and the source 'Flare Relay contract'. It distinguishes from sibling tools like 'fdc_get_attestation_proof' by focusing on proof status rather than requesting or proving attestations.
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 context for use is implied: when needing Merkle root and finalization status for a voting round. However, there is no explicit guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. Given the sibling tool names, an agent could infer usage, but the description does not provide explicit direction.
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?
No annotations are provided, so the description carries the full burden. It only states a basic read operation without disclosing potential behaviors like caching, rate limits, or error handling. For a read tool, additional transparency would be beneficial.
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 with no unnecessary words. It is highly concise and front-loaded with the key action and resource.
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), the description covers the essential: what it does and the required input. Missing details about output structure, but acceptable for a straightforward read operation.
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 description mentions 'on the given network', adding context to the network parameter beyond the enum values. However, with 0% schema description coverage, it does not fully compensate by explaining format or behavior for invalid inputs.
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 verb 'Get', the resource 'latest FTSO price for all known feeds', and the network parameter. It effectively distinguishes from sibling tools like get_ftso_feed which retrieves a single feed.
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 use for fetching all feeds, but does not explicitly state when to use this tool versus alternatives like get_ftso_feed or get_ftso_history. No direct guidance on context or exclusions.
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 provided, the description carries full burden for behavioral disclosure. It only describes the return data and parameter, but omits traits like idempotency, rate limits, or error behavior. For a simple read tool, this is minimal.
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, well-structured sentence with no extraneous words. Every part adds value: verb, resource, output fields, and context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one enum parameter and no output schema, the description fully covers what the tool does and what it returns. No additional information is needed for correct 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 single parameter 'network' has no schema description (0% coverage). The description adds value by clarifying that the network parameter specifies which network to query, and implies the list is scoped to that network. This compensates for the missing schema descriptions.
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 action ('Get'), the resource ('list of active FTSO data providers'), and the returned fields (name, address, vote power, fee, reward rate). It also specifies the context ('for the given network'), making it distinct from sibling tools like get_ftso_feed or get_ftso_feeds_all.
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 versus alternatives (e.g., get_ftso_feed, get_ftso_feeds_all). It does not mention exclusions or context-specific scenarios, leaving the agent without decision 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?
Discloses the data source (on-chain AssetManager with a fallback to flaremetrics.io), adding context beyond the simple 'get status' phrasing. However, with no annotations, the description should also indicate read-only nature and potential error scenarios, which are absent.
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?
Single sentence that front-loads the purpose, lists the return fields, specifies supported assets and networks, and mentions the data source. No redundant 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?
Covers what the tool does and the key output fields (total minted, active agent count). Missing return format details and error handling info, but the tool is simple and the output is implicitly understood from the description. No output schema exists to compensate.
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 schema has 0% parameter descriptions, but the description clarifies the enum values ('FXRP, FBTC or FDOGE' and 'mainnet, coston2'), explaining what the asset and network parameters represent. This compensates for the missing schema descriptions.
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?
Clearly states the tool retrieves FAssets status (total minted, active agent count) for specific assets (FXRP, FBTC, FDOGE) on a given network. Distinguishes from sibling tools like fassets_agent_status or fassets_system_state by focusing on aggregate asset-level metrics.
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?
Provides no guidance on when to use this tool versus sibling tools like fassets_agent_status or fassets_liquidation_scanner. The description does not specify prerequisites, preferred use cases, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses batch retrieval, local Merkle verification, and payment conditions. However, it does not mention error behavior or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with no fluff, front-loading key information about batch retrieval, verification, and payment.
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?
No output schema; the description lacks return format details and prerequisites (e.g., need to have requested proofs via sibling tools). Adequate for core behavior but incomplete for full context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 33%, and the description partially compensates by mentioning batch size limit (up to 20) and payment condition, but does not describe 'network' or the request item structure beyond what the schema provides.
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 does batch retrieval of up to 20 FDC attestation proofs with local Merkle verification, distinguishing it from the sibling 'fdc_get_attestation_proof' which likely retrieves single proofs.
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 batch usage via the sibling's name, but does not explicitly state when to use this tool over alternatives or provide exclusions. It mentions the payment model but no when-not guidance.
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?
No annotations are provided, so the description carries full burden. It discloses the preparation via Flare-hosted verifier, fee query, and conditional submission. It also mentions return values (tx hash, voting round id) or prepared request. Missing details on error handling or rate limits, but core behavior is clear.
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?
Three sentences, front-loaded with the main action, no redundant information. Highly efficient.
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?
Despite clear purpose and behavior, the description lacks essential details about the request_body parameter, which is a nested object with no schema explanation. Without this, the tool cannot be used correctly. Output schema is absent, adding to the incompleteness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description must compensate. It lists the three attestation types but provides no guidance on the required request_body format or how to structure the nested object. This is a significant gap for correct usage.
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 action ('Submit an FDC attestation request') and specifies the three attestation types (Payment, AddressValidity, EVMTransaction). It distinguishes from sibling tools like fdc_get_attestation_proof by focusing on submission.
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 explains two modes based on whether FLARE_PRIVATE_KEY is set, which guides when to expect automatic submission vs. external submission. However, it does not explicitly state when not to use this tool or compare with siblings.
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?
Given no annotations, the description partially bears the transparency burden. It reveals the return type (latest value, decimals, timestamp) and input flexibility (name or raw id), but lacks information on authorization, rate limits, error handling, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that immediately conveys the core purpose and key details. No extraneous words, front-loaded with the primary action and resource.
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 description covers the essential inputs and output shape, but for a tool with no output schema and no annotations, it omits important context such as response structure details (e.g., exact keys), error conditions, and case sensitivity of feed names. It is adequate for simple use but leaves gaps for robust agent interaction.
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?
Schema description coverage is 0%, so the description must compensate. It adds that feed_id can be a feed name (e.g., 'FLR/USD') or a bytes21 id, which is meaningful beyond the schema's type-only definition. Network is not elaborated beyond the schema's enum, but overall the description adds significant parameter 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 it retrieves the latest FTSO price feed, specifying the returned fields (value, decimals, timestamp) and the two identification methods (name or bytes21 id). This distinctly separates it from siblings like get_ftso_feeds_all or get_ftso_history.
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 when a single feed's latest data is needed, but does not explicitly state when to use this tool versus alternatives, or when not to use it.
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:

[![flario MCP server](https://glama.ai/mcp/servers/dziuba0x/flario/badges/card.svg)](https://glama.ai/mcp/servers/dziuba0x/flario)

Score Badge

Copy to your README.md:

[![flario MCP server](https://glama.ai/mcp/servers/dziuba0x/flario/badges/score.svg)](https://glama.ai/mcp/servers/dziuba0x/flario)

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/dziuba0x/flario'

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