Authenticated hosted Streamable HTTP MCP server for crypto data routing through PubFi capability and gateway tools.
Average 4.1/5 across 4 of 4 tools scored.
Each tool has a clear, separate job: list catalog entries, fetch one capability contract, execute a route, or verify a Substrate runtime upgrade. Even the list/get pair is a standard distinction and there is no meaningful overlap with the execution or verification tools.
All names follow the same dotted hierarchical pattern: pubfi.<resource>.<action>. They consistently end with a verb (get, list, execute, verify) and use lowercase snake_case throughout, making the tool family predictable and navigable.
Four tools is a well-scoped, minimal surface for this server: discovery, contract inspection, route execution, and upgrade verification. Each tool earns its place and there is no filler or redundant coverage.
The stated domain is covered cleanly: list and get handle capability inspection, execute covers the runtime interaction path, and verify covers the specialized Substrate upgrade audit workflow. There are no obvious dead ends or operations that require a missing companion tool.
pubfi.capabilities.getAReturn the full typed request, response, metering, and readiness contract for one exact capability id from the installed Registry generation.
| Name | Required | Description | Default |
|---|---|---|---|
| capability_id | Yes | Exact capability id returned by pubfi.capabilities.list. |
| Name | Required | Description |
|---|---|---|
| manifest | Yes | |
| capability | Yes | |
| generation | Yes | |
| compiled_at | Yes | |
| observed_at | Yes | |
| schema_version | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds useful behavioral context: exact-id match only, and the contract comes from the installed Registry generation. It does not mention error behavior for unknown ids, but that is a minor gap given the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one tight sentence that front-loads the primary return value and then scopes it to a single capability id and the installed Registry generation. There is no repetition of schema constraints or annotation hints.
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 single-parameter, read-only, idempotent tool with an output schema, the description covers what it returns, the exact-match scope, and the data source. No essential context is missing for an agent to decide whether and how to invoke it.
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%: capability_id is fully described with format, length constraints, and the source of valid values. The tool description adds no new meaning beyond 'exact capability id', so the baseline 3 is appropriate.
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 names a specific verb and resource: it returns the full typed contract for one exact capability id. With 'one exact capability id' it clearly distinguishes this getter from the sibling list tool, while the other siblings are obviously outside scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended usage is implied: call this when you have a specific capability id and need its full contract. However, it does not explicitly tell an agent when not to use it, such as 'use pubfi.capabilities.list to discover ids first' or 'use pubfi.route.execute to invoke a capability instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pubfi.capabilities.listAEnumerate the complete installed Registry v2 catalog as deterministic compact pages. The server does not rank, infer intent, or choose a capability.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum compact capability summaries to return. | |
| cursor | No | Opaque generation-bound cursor returned by the preceding page. | |
| method | No | ||
| provider_key | No | Optional exact public provider key. This is a static filter, not semantic search. |
| Name | Required | Description |
|---|---|---|
| filters | Yes | |
| manifest | Yes | |
| generation | Yes | |
| compiled_at | Yes | |
| next_cursor | No | |
| observed_at | Yes | |
| capabilities | Yes | |
| schema_version | Yes | |
| total_capability_count | Yes | |
| matching_capability_count | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Read-only, idempotent, and non-destructive behavior are already covered by annotations, so the description adds value by disclosing deterministic paging and the lack of server-side ranking or intent inference. This clarifies the tool's behavioral contract beyond what the annotations express.
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 tight, purposeful sentences with no filler. The first sentence states the primary operation immediately, and the second clarifies important behavioral boundaries 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 the annotations, output schema, and mostly self-documenting schema parameters, the description covers the core usage context well. A small gap remains around the method parameter's semantics, but overall an agent has enough context to call the tool and interpret the paginated read-only result.
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 75%, and the schema already explains limit, cursor, and provider_key fields, including that provider_key is an exact static filter rather than semantic search. The description contributes little new parameter-level meaning; the method parameter still lacks an explicit description, and the tool description does not fill that gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Enumerate') and resource ('the complete installed Registry v2 catalog'), and immediately distinguishes this from the sibling 'get' tool by emphasizing a complete, paged listing rather than a single fetch. It also signals clearly that this is not a discovery/search endpoint, making the tool's role unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates this tool is for complete, deterministic enumeration and explicitly says the server does not rank, infer intent, or choose a capability, which tells an agent not to use it for semantic or ranked selection. However, it does not explicitly name alternative tools or state a direct when-not-to-use comparison with siblings like pubfi.capabilities.get or pubfi.route.execute.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pubfi.route.executeAExecute one exact GET or POST path through the authenticated PubFi account lane and the same Registry v2 matcher and typed executor as the HTTP gateway. Append :free only when the capability catalog publishes that exact account-scoped free variant.
| Name | Required | Description | Default |
|---|---|---|---|
| body | No | Exact optional ASCII request-body bytes. For JSON routes, supply one compact serialized JSON document rather than a nested MCP argument value. | |
| query | No | Exact ASCII raw query string without a leading question mark. | |
| method | Yes | ||
| raw_path | Yes | Exact original URI path consumed by the Registry matcher. Segments use canonical unreserved ASCII only; percent escapes, dot segments, query, fragment, and backslash are forbidden. | |
| request_id | No | ||
| idempotency_key | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and idempotentHint=false. The description adds useful context about the authenticated account lane, the Registry v2 matcher, and the typed executor, plus the ':free' variant condition. However, it does not elaborate on destructive effects, failure behavior, or rate limits, so it provides only modest added transparency.
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, front-loaded with the core purpose, no filler or repetition. Every clause adds information about the execution lane, matcher, executor, or free-variant condition.
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 destructive, 6-parameter tool with two undocumented parameters, the description is too sparse. It does not mention side effects, idempotency expectations, how to discover the free variant via sibling tools, or when not to use this tool. The output schema helps with return values but does not fill these invocation-semantics gaps.
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 only 50%; request_id and idempotency_key have no schema descriptions. The tool description adds no parameter-level meaning beyond 'exact GET or POST path' and the ':free' append rule, leaving those two parameters unexplained and failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and resource: 'Execute one exact GET or POST path through the authenticated PubFi account lane.' It clearly distinguishes this from the sibling capability-list/get tools by focusing on route execution rather than capability discovery.
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?
It provides clear context about when this tool is appropriate—when an exact path must be executed through the same matcher/executor as the HTTP gateway—and adds a conditional rule: append ':free' only when the capability catalog publishes that variant. 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.
pubfi.substrate.runtime_upgrade.verifyAVerify one reviewed Substrate System.apply_authorized_upgrade extrinsic through the authenticated account lane. Supply the expected Blake2b-256 hash of the FRAME System AuthorizedUpgrade code payload, not the active :code hash at the apply block. The server streams and discards provider runtime code, persists only a compact proof, and returns independent comparison evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| network | Yes | ||
| request_id | No | ||
| extrinsic_hash | No | Canonical lowercase 0x-prefixed 32-byte hash. | |
| extrinsic_index | No | ||
| idempotency_key | No | ||
| expected_authorized_code_hash | Yes | Canonical lowercase 0x-prefixed 32-byte hash. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| route | Yes | |
| matches | Yes | |
| provider | Yes | |
| upstream | Yes | |
| meter_key | Yes | |
| generation | Yes | |
| extrinsic_hash | Yes | Canonical lowercase 0x-prefixed 32-byte hash. |
| reserved_units | Yes | |
| credits_charged | Yes | |
| extrinsic_index | Yes | |
| upstream_status | Yes | |
| execution_status | Yes | |
| extrinsic_success | Yes | |
| computed_code_hash | Yes | Canonical lowercase 0x-prefixed 32-byte hash. |
| runtime_code_bytes | Yes | |
| execution_authority | Yes | |
| upstream_latency_ms | Yes | |
| provider_response_bytes | Yes | |
| provider_response_sha256 | Yes | |
| expected_authorized_code_hash | Yes | Canonical lowercase 0x-prefixed 32-byte hash. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable side-effect and pipeline details beyond the annotations: the server streams and discards provider runtime code, persists only a compact proof, and returns independent comparison evidence. These details are consistent with destructiveHint=true and profit from readOnlyHint being false.
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 compact, front-loaded, and contains no filler. Every sentence carries information: the main action, the key hash distinction, side effects, and the output nature are all included 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?
For an operation with both idempotent and destructive hints, this is complete enough: it identifies what is supplied, what happens during processing, what is retained, and what is returned. The output schema and annotations cover the remaining mechanical details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics for expected_authorized_authorized_code_hash and warns against confusing it with the active code hash. However, schema description coverage is only about 33% and parameters such as network, idempotency_key, request_id, and extrinsic identity/differentiation are not semantically explained.
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 names a concrete verb ('Verify') and a specific resource: one reviewed Substrate System.apply_authorized_upgrade extrinsic through the authenticated account lane. This clearly separates it from the unrelated capability-listing and route-execution sibling 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?
It gives practical context for when to call the tool: on a reviewed extrinsic through the authenticated lane. It also provides a key execution rule — supply the expected authorized-code payload hash, not the active :code hash — which prevents a common misuse, even though it does not name alternate tools explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming 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 or an account that owns the GitHub organization, then choose Claim with GitHub.
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
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!
