S3 storage and Solana/Base/Ethereum health checks for AI agents, paid per call via x402.
Returns a 0-100 Base network health score plus the underlying metrics behind it. Useful before executing a timing-sensitive transaction. Paid: $0.002 per call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the paid nature ($0.002 via x402), a critical behavioral trait. It does not disclose rate limits or detailed response format, but the purpose and cost transparency are strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no wasted words. Front-loaded with purpose, then usage guidance, then cost. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description covers purpose, use case, and cost well. Could mention return example or if results are cached/stale, but complete enough for a simple health-check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema coverage is 100% by default. The description does not need to explain parameters but adds value with the score range and underlying metrics detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns a 0-100 health score plus underlying metrics, and specifies it's for the Base network, distinguishing it from siblings that target Ethereum or Solana.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly suggests use before executing timing-sensitive transactions, which implies appropriate context. Does not explicitly exclude alternatives or mention when not to use, but the sibling context is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a 0-100 Ethereum mainnet network health score plus the underlying metrics behind it. Useful before executing a timing-sensitive transaction. Paid: $0.002 per call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the cost: 'Paid: $0.002 per call via x402.', providing important financial context for the agent. As no behavioral annotations are provided, the description carries the full burden for transparency. It does not detail what 'underlying metrics' are returned, the update frequency, data source, or any other behavioral traits beyond the cost. Given zero annotations, a score of 3 is appropriate as it adds key cost information but leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, each earning its place. The first sentence states what the tool does. The second provides usage guidance and cost info. There is no fluff or repetition, and it is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has zero parameters, no output schema, and no annotations. Given this simplicity, the description is arguably complete for its purpose: it says what it returns, when to use it, and its cost. However, it omits details on the 'underlying metrics' or the score's meaning (e.g., higher is better), which a cautious agent might need. With no output schema, a bit more on the return format would boost completeness, but for a 0-param tool, current coverage is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (0 parameters), so the baseline is high. The description adds that the tool requires no parameters because it returns a current live score, which the schema alone cannot convey (it only shows an empty properties object). This goes beyond the schema by implying real-time data pricing and intended use case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Returns' with a clear resource: 'Ethereum mainnet network health score plus the underlying metrics behind it'. It distinguishes itself from the sibling tools by referencing other networks and explicitly calling out the Ethereum mainnet, making selection clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'Useful before executing a timing-sensitive transaction'. While it does not explicitly state when not to use it, the context of timing sensitivity, combined with the sibling tools targeting other networks (Base, Solana), clearly implies it is for Ethereum-specific cases only.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a 0-100 Solana network health score plus the underlying metrics behind it. Useful before executing a timing-sensitive transaction. Paid: $0.002 per call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not explicitly state that the tool is read-only, safe, or has no side effects. While 'returns' implies a read operation, the agent lacks explicit confirmation of behavioral traits like idempotency 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: one defining the return value, one providing use-case context and cost. Every sentence earns its place with no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description adequately covers what it returns and when to use it. However, it does not elaborate on the structure of 'underlying metrics' or any constraints (e.g., authentication, rate limits), which would improve completeness for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and schema description coverage is 100%, so the description does not need to add parameter meaning. The baseline of 4 is appropriate; no further elaboration is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'returns' and the resource 'Solana network health score plus underlying metrics'. It distinguishes itself from sibling tools (different blockchains, different purpose) by naming the specific blockchain and the health score focus.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Useful before executing a timing-sensitive transaction' and mentions cost ($0.002 via x402). It implicitly distinguishes from sibling tools (health checks for other chains, priority fee tools) but does not explicitly state when not to use or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommends a Base transaction priority fee based on recent network activity, at low/medium/high confidence levels. Paid: $0.002 per call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It discloses a per-call cost ($0.002 via x402), which is valuable. However, it does not mention whether the operation is read-only, any side effects, rate limits, or confirmation behavior. The confidence levels are mentioned but not explained in terms 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the main purpose, and includes the cost detail. Every sentence serves a purpose with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple (no parameters, no output schema), the description lacks details about the return format (e.g., is it a single fee number, an object with confidence levels?) and how confidence levels are represented. This leaves ambiguity for an agent invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description cannot add semantic value beyond the schema. Per guidelines, baseline score is 4 for zero-parameter tools. The description does not add unnecessary parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Recommends a Base transaction priority fee' based on recent network activity, with specific confidence levels. The sibling tools are for different chains or network health, so this is well-distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for getting a fee estimate for Base transactions, but does not explicitly state when to use it versus alternatives (e.g., get_network_health_base) or provide guidance on confidence level selection. Usage context is inferred from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommends a Ethereum mainnet transaction priority fee based on recent network activity, at low/medium/high confidence levels. Paid: $0.002 per call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses the tool is paid ($0.002 per call via x402), which is critical for an agent to know before invocation. It also explains it's based on recent network activity and outputs confidence levels. No contradictions with annotations (none provided), and no behavior like mutations or auth needs are relevant for a read-only recommendation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose, then adds essential cost information. Every word earns its place, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters, no output schema, and no complex behaviors. The description is sufficient for an agent to understand the input (none) and output (priority fee at confidence levels). However, it could be slightly more complete by hinting at what the output format might be (e.g., a number in gwei) or noting that the fee is for EIP-1559 transactions, but not required given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% coverage, so the schema is trivial. The description adds significant value by explaining what the tool does without needing parameters—no parameter documentation is needed. Baseline is 4 for zero parameters, but the description's mention of confidence levels enhances usefulness, earning a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool recommends an Ethereum mainnet priority fee based on recent network activity, with specific verb 'recommends' and precise resource 'Ethereum mainnet transaction priority fee'. It distinguishes from siblings like 'get_recommended_priority_fee_base' and 'get_recommended_priority_fee_solana' by specifying the network (Ethereum) and adds detail about confidence levels (low/medium/high).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (for Ethereum mainnet transactions needing a priority fee recommendation) and mentions no parameters, implying immediate usability. However, it does not explicitly state when not to use it or compare with alternatives like the Base or Solana versions, leaving the agent to infer from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommends a Solana transaction priority fee based on recent network activity, at low/medium/high confidence levels. Paid: $0.002 per call via x402.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 cost ($0.002 per call via x402) and output granularity (confidence levels), but does not explicitly state that the tool is read-only, idempotent, or free of side effects. The behavioral traits beyond cost and confidence levels are partially covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. First sentence delivers purpose and output characteristics; second sentence adds cost. Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description covers purpose, data source, confidence levels, and cost. However, it lacks explanation of the return format or units (e.g., lamports, SOL). Agents might need to infer the expected output structure. Still mostly complete for a simple recommendation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% schema coverage (trivial). The description adds meaning by specifying that the tool provides fee recommendations at low/medium/high confidence levels, which informs the agent about the output variety. Since there are no parameters, every piece of description adds value beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Recommends' and the resource 'Solana transaction priority fee', with context of 'based on recent network activity' and 'at low/medium/high confidence levels'. This distinguishes it from sibling tools for other chains (Base, Ethereum) and network health tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining a Solana priority fee recommendation but does not explicitly guide when to use this tool vs the Base or Ethereum siblings, nor does it mention prerequisites or when not to use. The context is clear but lacks explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieves a stored object by key, base64-encoded. Flat $0.01 per call. Objects over 4MB must be fetched via HTTP GET /retrieve instead.
| Name | Required | Description | Default |
|---|---|---|---|
| key | Yes | The key returned by store_object or PUT /store |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses the base64 encoding, flat pricing per call, and the 4MB retrieval limitation. This is useful behavioral context, though it doesn't describe error behavior or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences deliver all essential information: what the tool does, output encoding, pricing, and a limitation with workaround. No filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers the core behavior, output format, cost, and large-object alternative. It is near-complete, though it could clarify what happens for missing keys or failed retrievals.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The schema already explains that 'key' is the key returned by store_object or PUT /store; the description adds no further parameter-specific semantics beyond restating 'by key'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Retrieves a stored object'), the resource ('by key'), and the output format ('base64-encoded'). This distinguishes it from the sibling store_object tool and network health tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: use this tool to retrieve objects by key, but objects over 4MB must be fetched via HTTP GET /retrieve instead. This explicit size-based exclusion gives practical guidance, though it doesn't mention scenarios where sibling tools would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Uploads a small base64-encoded object to S3-compatible storage. ~$1/GB, $0.01 minimum, capped at 4MB (larger files: use HTTP PUT /store instead). Returns a key for retrieve_object.
| Name | Required | Description | Default |
|---|---|---|---|
| content_type | No | MIME type, defaults to application/octet-stream | |
| content_base64 | Yes | Base64-encoded bytes to store |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even with no annotations, the description discloses important behavioral traits: approximate cost, $0.01 minimum, 4MB size cap, fallback for larger files, and the returned key's relationship to retrieve_object. This goes well beyond a generic upload statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, information-dense sentences. Every clause adds value: pricing, size limit, fallback alternative, and return semantics. No filler or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter upload tool with no output schema, the description provides sufficient context: storage target, size constraints, pricing, and the use of the returned key with the sibling retrieve_object tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers both parameters at 100%, so the baseline is 3. The description adds the 4MB cap for content_base64 and the 'small object' expectation, which is parameter-relevant information not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly names the specific action ('Uploads'), the resource ('S3-compatible storage'), and the key output ('Returns a key for retrieve_object'). It also distinguishes itself from the sibling retrieve_object by describing the write side of the object lifecycle.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly scopes the tool to 'small' objects and gives a concrete alternative for larger files: 'use HTTP PUT /store instead'. This gives the agent clear when-to-use and 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
retrieve_objectstore_objectget_network_healthget_network_health_solanaget_recommended_priority_feeget_recommended_priority_fee_solanaget_network_health_baseget_network_health_ethereumget_recommended_priority_fee_baseget_recommended_priority_fee_ethereumget_network_healthget_recommended_priority_feeis_network_degradedis_validator_delinquentis_network_degradedis_validator_delinquentClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Private, permanent encrypted storage for AI agents. Paid per call in USDC via x402.
63 pay-per-call tools for agents: vision, text, data, web, blockchain. USDC on Base via x402.
x402 paid APIs for AI agents on Base. Blockchain, wallet, DEX, crypto, web search.
Pay-per-call tools for autonomous agents, settled in USDC on Base via x402.
Add one secure layer between your agents and this server.
Each tool is clearly distinguished by its operation type (network health, priority fee, store, retrieve) and, where applicable, the specific blockchain (Base, Ethereum, Solana). No two tools perform the same function on the same target, so an agent can select the correct tool without ambiguity.
All tool names follow a consistent verb_noun pattern using snake_case. The first six tools use 'get_' plus a descriptive noun (network_health or recommended_priority_fee) followed by the chain name, while the storage tools use 'store_' and 'retrieve_' with 'object'. This predictable convention aids agent selection.
With 8 tools, the server is well-scoped. The six network-related tools cover three blockchains across two recurring operations, and the two storage tools provide minimal yet sufficient coverage. The count is within the ideal range and each tool earns its place.
The network health and fee recommendation tools fully cover their immediate purposes. For object storage, only store and retrieve are provided, lacking delete or list operations. While the core workflow (write and read) is functional, the absence of delete is a minor gap that could require workarounds.