flare-mcp

by dziuba0x

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Hybrid

Server Quality Checklist

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

Latest release: v1.5.0
Disambiguation3/5
Most tools serve clearly distinct purposes, but there is real overlap: get_fassets_status is largely superseded by fassets_system_state, get_flr_balance is a subset of get_flr_stake_info, and get_ftso_feed versus get_ftso_anchor_feed are easy to confuse without reading descriptions. The detailed descriptions help, but the boundaries are not always crisp.
Naming Consistency3/5
The set is consistently snake_case, but the naming pattern is mixed: some tools start with get_, others use domain prefixes like fdc_/ fassets_/ evidence_, and songbird_fcc_registry does not follow a verb pattern at all. Word order also varies, such as fdc_web2json_request versus fdc_request_attestation.
Tool Count3/5
24 tools is at the heavy end of the acceptable range, and the server covers several protocol families rather than one focused workflow. Each family has useful tools, but the broad scope and near-redundant status/balance tools make the set feel slightly bloated.
Completeness4/5
Core workflows are well covered: reading state, requesting and retrieving FDC proofs, verifying proofs against the on-chain Relay root, and bundling evidence for downstream verification. Minor gaps exist, such as no dedicated generic verifier for Payment or AddressValidity attestations, but agents can work around them.
Average 3.8/5 across 24 of 24 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 21 commits in the last 12 weeks
- Last stable release on September 1, 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 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it does well by disclosing that the tool quotes a fee, submits on-chain only under specific conditions, and otherwise returns a prepared request. It could add more on side effects or failure modes, but the conditional submission behavior is clearly communicated.
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 with no filler: the first states the purpose, the second explains the preparation and fee quote, and the third covers the conditional submission behavior. Information is front-loaded and each sentence earns its place.
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 8 parameters, no output schema, and no annotations, yet the description does not explain the response format beyond 'returns the prepared request,' nor does it cover most request parameters or connect the tool to the broader FDC attestation/proof lifecycle. An agent would need significant additional context to invoke this correctly in all cases.
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 only 25%, so the description must compensate, but it only names three of eight parameter categories: URL, jq filter, and ABI signature. It leaves network, body, headers, http_method, and query_params unexplained, and does not clarify how the jq filter and ABI signature interact.
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 the tool prepares an FDC Web2Json attestation request (URL + jq filter + ABI signature) through a Flare-hosted verifier, which is a specific verb and resource. It does not explicitly name sibling tools or contrast itself with them, but the Web2Json scope and 'request' vs. 'verify' distinction make it reasonably distinguishable.
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 when to use the tool: when turning any public web API into a verifiable fact. It also gives useful conditional behavior around FLARE_PRIVATE_KEY and submission permission, but it does not state when not to use it or mention alternatives such as the generic fdc_request_attestation or fdc_verify_web2json.
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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full behavioral disclosure burden. It only says 'get the list of active providers' and does not disclose pagination behavior, ordering, limit effects, reward epoch semantics, or return format details. The word 'active' adds some filtering context, but most behavioral information is left 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 a single front-loaded sentence with no filler. It efficiently conveys the resource, scope, and output fields, making it concise while still adding useful information given the absence of an output schema.
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 captures the core purpose and output fields, which is enough for an agent to attempt a call. However, with no annotations and no output schema, it should also clarify limit behavior, reward epoch selection, and any pagination or ordering expectations. These gaps make it minimally viable but not complete.
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 only 33%, and the description adds minimal parameter meaning beyond confirming the network context. It does not explain the limit parameter semantics, the maximum/default behavior, or reward_epoch_id beyond what the schema already states. With low coverage, the description needed to compensate but largely did not.
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 uses a specific verb, 'Get', and identifies the exact resource: 'active FTSO data providers'. It also lists the returned fields (name, address, vote power, fee, reward rate), making the tool's purpose unmistakable and clearly distinct from sibling feed/history tools.
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 gives clear context by requiring a network and targeting provider data rather than feed data. However, it does not explicitly state when to prefer this tool over siblings like get_ftso_feeds_all or get_ftso_history, and it provides no exclusions or alternative routing.
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It does well by revealing that the data comes from the public Flare DA layer, that no external indexer is required, and that each point is optionally Merkle-verified against the on-chain Relay root. These are meaningful behavioral traits not visible in the schema. It stops short of stating response formatting or recency bounds, but for a read-only getter this is solid transparency.
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 tight sentences with no filler. The main action and key differentiator are front-loaded, and the optional Merkle verification detail is placed in the second sentence. Every sentence earns its place.
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 tells the agent what the tool returns, where it gets data, and how verification works, so it is invocable with the provided schema. However, there is no output schema and no description of what each history point contains, how far back 'recent' goes, or how rounds maps to returned records. Given the FTSO domain complexity and the number of sibling tools, the description is usable but not fully complete.
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%, so the description must compensate. It partially does: 'by name or bytes21 id' clarifies feed_id, and 'optionally Merkle-verified' clarifies verify. However, rounds is not explained beyond its name and schema defaults, and network is left entirely to the enum. The description adds value but leaves a real semantic gap around the rounds parameter.
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 a specific action and resource: 'Get recent FTSO Scaling anchor-feed history for a feed (by name or bytes21 id).' It also names the data source and key capability, so an agent knows what the tool returns and where the data comes from. It does not explicitly differentiate itself from sibling tools such as get_ftso_anchor_feed or get_ftso_feed, but the word 'history' and the reference to the public DA layer distinguish it enough for a 4.
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 phrase 'no external indexer needed' and 'from the public Flare Data Availability layer' gives useful context about when this direct DA-layer route is appropriate. However, there are no explicit when-to-use or when-not-to-use instructions, and no sibling tool is named as an alternative. Usage guidance is implied rather than stated, so it earns a 3.
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 transparency burden. It adds useful behavioral context by stating the source registry and that the agent parameter accepts either an agent vault address or an owner management address, but it does not disclose lookup behavior, error cases, or whether the operation is strictly read-only.
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 sentences carry a dense, useful payload: the tool's purpose, the specific returned fields, the registry, and the accepted input address types. There is no filler or repetition of schema information, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the relatively simple parameter set and lack of an output schema, the description is mostly complete: it names the returned fields and clarifies the agent parameter. It falls slightly short of full completeness by not describing how asset and network affect the lookup or what happens when an address is not found, but these are moderate gaps rather than fatal ones.
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?
With 0% schema description coverage, the description must compensate for parameter meaning. It adds real semantics for 'agent' by specifying the two accepted address types, but it does not explain the role of 'asset' or 'network' beyond what the enum values already imply. This is partial compensation, not full coverage.
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 opens with a specific resource ('FAssets agent') and a clear noun ('details'), then enumerates the exact fields returned (name, description, icon/logo URL, terms-of-use URL, whitelist status). It names the source registry, AgentOwnerRegistry, and clarifies what address inputs are accepted, making it easy to distinguish from siblings such as fassets_agent_status 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: use this when you need human-facing agent registration details rather than operational status or system state. However, it does not explicitly state when to prefer this tool over alternatives or mention exclusions, leaving some routing guidance to inference.
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It reveals the key behavior: the tool returns a price plus a Merkle proof, verifies the proof locally against the Relay root, and defaults to the latest finalized round. It does not cover error cases or response formatting, but for a read-style fetch this is reasonably transparent.
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 compact and front-loaded with the core purpose and key differentiating detail. Each sentence adds useful information, with no filler, though the protocol-specific jargon may make it slightly dense for an unfamiliar agent.
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 tool with no output schema and no annotations, the description gives a strong summary of the returned artifact and trust model, but leaves gaps around parameter formats and the exact response shape. It is adequate for a caller who already understands the FTSO Scaling domain, but not fully self-sufficient for a generic 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 description coverage is 0%, so the description needed to compensate. It only indirectly explains voting_round_id via 'Defaults to the latest finalized round.' The meanings and accepted formats of feed_id and network are left entirely to inference, which is a significant gap given three parameters and no 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 states a specific verb and resource ('Get ... FTSO Scaling anchor feed') and immediately distinguishes it from ordinary feeds by highlighting the proof-carrying Merkle proof verified against the on-chain Relay root. This makes it clearly distinct from siblings like get_ftso_feed and 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear use case: when an agent or smart contract needs a trust-minimized feed and should not trust the DA API. It also notes the default to the latest finalized round, which helps callers decide when to pass voting_round_id. It does not explicitly name alternatives, but the framing is sufficient.
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. It transparently lists the data categories returned and the network scope, and implies a read-only aggregation behavior. It does not mention caching, freshness, or failure modes, but for a pure getter the output inventory is fairly transparent.
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 opens with the core value proposition and then enumerates the included data elements. There is no filler, redundancy, or unnecessary detail.
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 read-only getter with only two schema-constrained parameters, the description provides a strong high-level inventory of returned categories. However, with no output schema and no annotations, it omits response shape, units, and potential error behavior, leaving some ambiguity for an agent consuming the result.
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%, so the description must help interpret parameters. It maps 'address' to the portfolio subject and 'network' to all four networks, but does not explain address format or network value syntax. The schema's regex and enum already provide those constraints, so the description adds only minimal semantic value.
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 a specific aggregate getter for an address's Flare portfolio and enumerates the exact contents: native FLR, WFLR, FTSO vote power, delegation, claimable rewards by source, and FlareDrops. It also notes coverage of all four networks, which distinguishes it from simpler siblings like get_flr_balance or get_ftso_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 'One-call Flare portfolio' phrasing implies this tool is the consolidated option when multiple stake-related data points are needed at once. However, it does not explicitly state when to prefer this over alternatives such as get_flr_balance, nor does it mention 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?
With no annotations provided, the description carries full behavioral disclosure. It explains that the tool rebuilds leaves, folds proofs, compares against on-chain Relay.merkleRoots, re-binds Web2Json facts, and 'trusts nothing in the bundle, including its own hash.' It does not mention return values or failure behavior, but it gives a detailed account of what the tool actually does.
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?
Four concise sentences, each adding real value: the core operation, the verification mechanics, the trust model, and the usage context. It is front-loaded with the action and avoids filler.
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 complex verification tool with no output schema and no annotations, the description is notably complete: it explains the verification algorithm, the on-chain comparison, the trust model, and when to call it. The main gap is not describing what the tool returns or how failure is signaled, but the call itself is well specified.
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 100%, so the schema already documents both parameters. The description adds some contextual meaning, such as the bundle coming from evidence_bundle and the re-binding behavior, but it mostly restates what the schema already says.
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 states a highly specific verb and resource: 'Verify an evidence bundle from scratch' and explains the verification pipeline. It clearly differentiates itself from the sibling evidence_bundle by calling itself 'the receiving end,' so an agent can distinguish producer from verifier.
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 explicit usage context: 'This is the receiving end: run it on a bundle someone hands you.' This clearly indicates when to use the tool versus evidence_bundle, though it does not explicitly exclude alternatives like fdc_verify_web2json or fdc_verify_settlement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the behavioral disclosure burden. It explicitly states phase 1 is 'free, no chain write', that verification is done locally via Merkle proof, that it 'binds it to the payment', and that it 'Never submits on-chain itself.' These are strong, non-obvious behavioral guarantees.
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 dense but each sentence earns its place: purpose, phase-1 behavior, phase-2 verification, and the on-chain neutrality guarantee. It could be more scannable with separate sentences for each mode, but it is not padded or repetitive.
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 nine-parameter, two-phase tool with no output schema and no annotations, the description covers the core protocol and safety model well. It still omits the tool's return value, how an agent should obtain abi_encoded_request, and the precise role of required_confirmations and network, leaving some non-obvious invocation details underspecified.
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%, so the description must compensate. It adds real meaning for amount ('>= amount'), asset and payee (ERC-20 Transfer check), and voting_round_id/abi_encoded_request (finalized proof inputs). However, network, required_confirmations, and payer are not explained, leaving partial gaps that the schema alone does not fill.
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 opens with a specific action and resource: 'Prove an x402 settlement via Flare's enshrined FDC' and contrasts it with 'not the facilitator's word.' It lays out the two operation modes clearly, so the tool's purpose is unambiguous even among similar-sounding FDC siblings.
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 concrete usage context: 'Given a settlement tx hash' triggers the phase-1 attestation request, while a 'finalized voting_round_id + abi_encoded_request' triggers local verification. It does not explicitly name sibling alternatives or state when not to use the tool, but the conditional guidance is clear.
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?
Since no annotations are provided, the description carries the full behavioral burden and largely succeeds: it states that verification happens locally, what is checked, and the consequence of omitting expect_source. It stops short of describing return values or error behavior, but the core operational behavior is transparent.
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 three sentences with no filler. Purpose, method, and the security-relevant caveat are front-loaded, and every sentence contributes distinct 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?
For a complex verification tool with no output schema, the description covers what verification means, how the proof is checked, and why expect_source matters for safe use. It leaves some gaps around return values and edge cases, and the schema marks expect_source optional even though the description presents it as security-critical, but overall an agent can invoke this correctly.
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 only 25%, so the description must compensate. It does add real meaning for expect_source by explaining host/path/protocol/method binding and for abi_encoded_request by mentioning ABI decoding. However, voting_round_id and network are left to inference from their names and types, so parameter semantics are only partially enriched.
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 opens with a specific verb and object: 'Verify a Web2Json attestation AND bind it to the source you expected.' It then breaks verification into concrete steps—local Merkle check against the on-chain Relay root, URL component matching, and ABI payload decoding—so the tool's purpose is unambiguous and distinct from proof-request siblings.
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 on when the tool is safe and when it is not: without expect_source, the proof is verified but not bound, leaving an attack vector. It does not explicitly name an alternative tool for other attestation types, but the verifier-vs-request context is clear enough to avoid the obvious siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full behavioral burden, and it delivers: it discloses a validation pipeline ('folds each Merkle proof against the on-chain Relay root BEFORE including it') and a failure mode ('refuses any fact that fails'). It also clarifies that only finalized attestations are accepted, giving the agent a concrete expectation of behavior.
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, each earning its place: the packaging purpose, the validation behavior, and the intended usage scenario. There is no filler, no repetition of schema details, and the key facts are front-loaded.
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 has complex, nested input and no output schema, yet the description never states the returned bundle's form or how to pass it to a verifier such as evidence_verify. It also leaves the boundary with fdc_bulk_proof_bundle implicit, so an agent is left to infer when one is preferred over the other.
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 about 80%, so the baseline is 3; the schema already documents most parameters. The description adds useful context by linking network/voting_round_id to Relay-root validation and confirming Web2Json attestations are supported, but it does not clarify whether at least one evidence source is required or explain the optional claim parameter beyond the 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 uses a specific verb and resource: 'Package several proof-carrying facts into one portable bundle.' It also names the exact input sources (FTSO Scaling anchor feeds and finalized FDC attestations, including Web2Json) and the Relay-root validation, which separates it clearly from sibling read/verify tools.
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?
There is an explicit use case: 'Use when an agent needs to hand a downstream consumer, an auditor, or another agent the evidence its decision rested on.' It does not, however, state when not to use it or explicitly compare with fdc_bulk_proof_bundle for FDC-only scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description alone must disclose behavior, and it does so thoroughly. It reveals that the tool reads on-chain data, enumerates facets and selectors, maps them to capabilities, and warns that names are signature-matched because no ABI exists while selectors/addresses/wiring are read exactly.
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 longer than average but each sentence earns its place: one sets the rollout context, one details the inspection logic, one provides the ABI caveat. The second sentence is dense but not fluff.
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?
There is no output schema, so the description needs to communicate what the agent should expect back. It names the reported dimensions: capabilities, facets, selectors, addresses, wiring, and whether governance is live or the shell is empty. It does not specify the exact response shape or behavior when no diamond is found, but for an exploratory chain-reading tool this is a strong level of completeness.
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?
Both parameters have full schema descriptions, so the baseline is 3. The tool description adds rollout context, such as 'network by network' and 'all four,' but does not meaningfully expand on parameter semantics beyond the 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 names a specific resource and action: monitoring Flare 2.0 confidential compute deployment status across networks. It explains exactly what the tool does beyond the name, and the behavior is unmistakably distinct from siblings like fdc_proof_status or songbird_fcc_registry.
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 gives clear usage context: use this while the rollout is still happening, network by network, to see whether a deployment is live or an empty shell. It does not explicitly name alternatives or exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It explains the deterministic on-chain resolution, whether a Smart Account is deployed, reverse ownership lookup, and the Smart Account existence check. It does not cover error behavior or what happens when neither or both address parameters are provided, but the core behavior is well disclosed.
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 and immediately front-loads the tool's core purpose. Every clause adds useful information: the controller used, the forward resolution behavior, and the reverse resolution behavior. There is no redundant or filler language.
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 explains the conceptual output well even though no output schema exists. However, it never states that exactly one of xrpl_address or flare_address must be supplied, and the schema marks only network as required, making both addresses appear optional. This is a notable gap for correct invocation, and there is no mention of expected return structure beyond the conceptual resolved values.
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 covers 67% of parameters with patterns for xrpl_address and flare_address, but the description enriches these by defining exactly what each address resolves to: XRPL goes to deterministic Flare address plus deployment status, Flare goes to Smart Account status plus owner. It does not describe the required network parameter beyond the schema enum, but the directional semantics add real meaning beyond the raw property names.
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 opens with a specific verb and resource: 'Resolve between XRPL accounts and Flare Smart Accounts via the on-chain MasterAccountController.' It clearly defines two directional behaviors and distinguishes this tool from the FTSO, fassets, and FDC sibling tools, none of which handle account resolution.
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 explicit usage direction: use forward resolution when you have an XRPL account (r...) and reverse resolution when you have a Flare address (0x...). It does not name alternatives or state when not to use the tool, but the sibling set makes the intended use clear and the directional guidance is actionable.
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

flare-mcp MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![flare-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/dziuba0x/flario/badges/card.svg)](https://glama.ai/mcp/servers/dziuba0x/flario)

Score Badge

Copy to your README.md:

[![flare-mcp MCP server – quality and maintenance score on Glama](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