agent-erc8004-bridge
Server Details
The MCP-native bridge to ERC-8004 (on-chain agent identity/reputation/validation): resolve registrat
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- jdhart81/viridis-agent-fleet
- GitHub Stars
- 0
- Server Listing
- viridis-agent-fleet
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.4/5 across 9 of 9 tools scored. Lowest: 2.8/5.
Each tool has a clearly distinct purpose: identity binding, capability description, attestation export, feedback import, registration import, registration listing, agent resolution, scoring, and attestation verification. No overlapping functionality.
All tools follow a consistent verb_noun pattern using snake_case (e.g., import_feedback, resolve_agent). This predictable convention aids agent understanding and selection.
With 9 tools, the set is well-scoped for an ERC-8004 bridge. It covers registration, feedback, scoring, attestation, and resolution without being bloated or too sparse.
The tool set covers core workflows: registration, feedback import, scoring, attestation creation/verification. Minor gaps exist, such as no explicit delete or unbind operations, but these may be intentional design choices.
Available Tools
9 toolsbind_identityBInspect
Bind a fleet DID to an ERC-8004 identity. Produces an order-independent, content-addressed (unsigned) binding attestation.
| Name | Required | Description | Default |
|---|---|---|---|
| chain_id | Yes | ||
| token_id | Yes | ||
| fleet_did | Yes | ||
| proof_note | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially covers behavioral traits by noting the output is 'unsigned' and 'order-independent, content-addressed'. However, it omits details like side effects, idempotency, or error conditions.
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 concise at two sentences. The first sentence states the main action, and the second adds detail about the attestation. Could be slightly improved by front-loading the verb and resource more prominently.
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?
Despite having an output schema, the description is insufficient for the complexity (4 parameters, 3 required). It lacks explanation of return values, prerequisites, or behavioral details needed for correct invocation.
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 0%, yet the description provides no explanation of the parameters (fleet_did, chain_id, token_id, proof_note). It fails to add semantic meaning beyond the schema's field names.
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 specifies the action ('bind'), the resources ('fleet DID' and 'ERC-8004 identity'), and the output ('unsigned binding attestation'). It distinguishes this tool from siblings by the specific terminology and unique output.
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?
No guidance is provided on when to use this tool versus its siblings (e.g., verify_attestation, export_attestation). The description lacks context about prerequisites or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
describe_agentBInspect
Return the bridge's capabilities and input contract.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full responsibility. It does not disclose behavioral traits like side effects or safety, though being an introspection tool it is likely non-destructive.
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?
One concise sentence with no unnecessary words, front-loaded with action and object.
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 an output schema, the description is adequate. It could explicitly mention read-only behavior but is sufficient for a simple introspection 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?
No parameters exist and schema coverage is 100%, so description adds minimal extra value but is not penalized.
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 the bridge's capabilities and input contract, which is a specific verb+resource. The sibling tools are about identity, attestation, and registration, so this introspection tool is distinct.
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?
No guidance on when to use this tool versus siblings is provided. The description does not mention alternatives or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
export_attestationAInspect
Export the agent's current trust score as an UNSIGNED ERC-8004 Validation Registry-shaped payload, content-addressed and ready for YOUR OWN signer to anchor on-chain.
| Name | Required | Description | Default |
|---|---|---|---|
| chain_id | Yes | ||
| token_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states the output is unsigned and content-addressed, but it does not disclose side effects (e.g., whether the tool modifies state), access requirements, or error conditions. The description adds some behavioral context beyond the bare schema but remains incomplete.
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 sentence that efficiently conveys the purpose and key details. It front-loads the action and resource, then adds critical qualifiers (unsigned, content-addressed, ready for signer). No unnecessary 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?
Given the existence of an output schema (covering return format), the description provides enough high-level context for most agents to understand the tool's function. However, the lack of parameter descriptions is a gap, and the description could benefit from a brief note on prerequisites or the meaning of chain_id/token_id. Overall, it is nearly complete for its role.
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 0%, and the tool description provides no explanation of the two parameters (chain_id, token_id). The agent is left to guess their meaning and usage, which is critical for correct invocation. The description adds no value here.
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 exports the agent's current trust score as an unsigned ERC-8004 Validation Registry-shaped payload. It specifies the output format (content-addressed, ready for signing) and distinguishes this tool from siblings like verify_attestation or import_registration by emphasizing the unsigned nature and on-chain anchoring preparation.
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 when to use (when you need a payload for your own signer to anchor on-chain) but does not explicitly state when not to use or provide comparisons to sibling tools. Guidance on prerequisites or alternatives is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
import_feedbackAInspect
Import ERC-8004 Reputation Registry feedback records for an agent. Each item: {value: bool|0..1, at: ISO-8601, source?, weight?, feedback_id?}. Idempotent per feedback_id.
| Name | Required | Description | Default |
|---|---|---|---|
| chain_id | Yes | ||
| feedback | Yes | ||
| token_id | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses idempotency per feedback_id and item structure. No annotations provided, so description carries full burden; additional details like authentication or error handling are missing but not critical.
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 concise sentences: purpose, structure, idempotency. No redundancies or vague language.
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?
Covers purpose, parameter semantics, and key behavioral trait. Output schema exists, so return values are handled. Missing constraints like valid chain_ids or token_id format, but overall 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?
Parameter schema coverage is 0%, but description compensates by detailing feedback item structure (value, at, source?, weight?, feedback_id?). Provides meaning beyond bare 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 states verb 'Import', resource 'ERC-8004 Reputation Registry feedback records', and scope 'for an agent'. Distinguishes from sibling tools (e.g., import_registration). Includes item structure and idempotency.
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?
No explicit when-to-use or when-not-to-use compared to siblings. Implies usage for importing feedback but lacks guidance on prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
import_registrationAInspect
Import an ERC-8004 Identity Registry record (chain_id + ERC-721 token_id + agentURI + owner). Idempotent: re-import updates in place. Returns the canonical record with its deterministic bridge DID (did:viridis:erc8004::).
| Name | Required | Description | Default |
|---|---|---|---|
| owner | Yes | ||
| chain_id | Yes | ||
| metadata | No | ||
| token_id | Yes | ||
| agent_uri | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It adds idempotency and return value details (canonical record with DID). However, it does not disclose authentication needs, rate limits, or potential side effects beyond updating in place.
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 primary verb and resource. Every sentence adds value (idempotency, return format). No unnecessary 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?
With no output schema provided despite its existence, the description compensates by stating the return value format (canonical record with DID). It covers key aspects but lacks details on error handling and preconditions.
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 0%, and the description adds context for 4 of 5 parameters (chain_id, token_id, agent_uri, owner) by specifying their role. The optional 'metadata' parameter is not explained, leaving a 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 states the verb 'import' and the resource 'ERC-8004 Identity Registry record', listing key fields (chain_id, token_id, agentURI, owner). It clearly distinguishes from siblings like bind_identity or list_registrations.
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 mentions idempotency and that re-import updates in place, implying it can be used for both create and update. However, it does not explicitly state when to use this tool vs. alternatives or provide any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_registrationsAInspect
List all imported ERC-8004 registrations.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits but only states 'list all', implying no filtering; it omits details on pagination, rate limits, or side effects, which are critical for an agent invoking the 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, clear sentence with no extraneous information, making it highly efficient and front-loaded.
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 description is adequate for a zero-parameter tool with an output schema, it lacks usage guidance and behavioral details, leaving gaps in contextual 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?
No parameters exist, so the schema covers 100%; a baseline of 4 is appropriate as the description does not need to add parameter meaning.
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 lists all imported ERC-8004 registrations, specifying the verb 'list' and the resource 'imported ERC-8004 registrations', which distinguishes it from sibling tools like import_registration.
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?
No when-to-use or when-not-to-use guidance is provided; the description does not reference sibling tools or alternative scenarios, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_agentBInspect
Resolve an imported ERC-8004 registration by bridge DID or by (chain_id, token_id).
| Name | Required | Description | Default |
|---|---|---|---|
| chain_id | No | ||
| token_id | No | ||
| bridge_did | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should convey whether the tool is read-only or has side effects, possible errors, or prerequisites. It only states it 'resolves' but does not clarify what that entails (e.g., returns details, modifies state).
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, front-loaded sentence with no superfluous words. It efficiently conveys 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?
Given that an output schema exists but is not shown, and there are 8 sibling tools, the description lacks context such as what 'resolve' returns and how it differs from similar operations. It provides the identification methods but insufficient completeness.
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% description coverage, so the description compensates by explaining the two parameter groups (bridge_did vs chain_id+token_id). However, it does not specify the optionality or behavior when both groups are provided or omitted.
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 ('Resolve') and the resource ('imported ERC-8004 registration'), and specifies the two distinct identification methods (by bridge DID or by chain_id/token_id), which distinguishes it from sibling tools like import_registration.
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?
No guidance is provided on when to use this tool versus siblings like describe_agent or list_registrations, nor are there any conditions, prerequisites, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
score_agentBInspect
Decay-weighted trust score in [0,1] + tier over the agent's imported ERC-8004 feedback — recent behavior outweighs old; no feedback scores a neutral 0.5 prior (no blind trust, no unfair zero).
| Name | Required | Description | Default |
|---|---|---|---|
| chain_id | No | ||
| token_id | No | ||
| bridge_did | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
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 decay-weighting mechanism and neutral prior, but does not cover side effects, authentication needs, rate limits, or idempotency. Some behavioral context is given, but it's incomplete.
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 sentence that packs key information, but it is somewhat verbose and uses technical jargon ('ERC-8004 feedback'). It could be more concise while retaining clarity.
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 complexity (trust scoring) and the lack of parameter documentation or annotations, the description does not provide enough context for correct invocation. It explains the output well, but usage context and parameter roles are missing.
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% description coverage, and the description does not explain any of the parameters (chain_id, token_id, bridge_did). The user must infer their meaning from names alone, which is insufficient for a scoring tool.
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 computes a decay-weighted trust score from ERC-8004 feedback, with a neutral prior of 0.5 when no feedback exists. It uses specific verbs ('score') and distinguishes from sibling tools by focusing on trust scoring.
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 trust score based on imported feedback, but provides no explicit guidance on when to use this tool vs alternatives like describe_agent or export_attestation. No when-not or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verify_attestationCInspect
Recompute a payload's content hash and report whether it is intact.
| Name | Required | Description | Default |
|---|---|---|---|
| payload | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses that it recomputes a hash and checks intactness, but lacks details on potential side effects, security requirements, or behavior upon failure (e.g., error handling).
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?
Single sentence is concise and front-loads the core action. No redundant information, but leaves many questions unanswered for a tool with a nested object parameter.
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?
With an output schema present, return value details are not needed, but the single parameter is undocumented in both schema and description. For a tool that likely involves cryptographic verification, this is insufficient for an AI agent to use correctly.
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 has 0% parameter description coverage, and description adds no semantics beyond the word 'payload'. The type is an object with additionalProperties true, yet description gives no hints on expected structure or required fields.
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?
Description clearly states the tool's action ('Recompute a payload's content hash and report whether it is intact'), with a specific verb and resource, and differs from siblings like 'export_attestation' or 'import_feedback' which involve different operations.
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?
No guidance on when to use this tool versus alternatives (e.g., 'export_attestation'), prerequisites, or context. The description simply states the function without usage conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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.
Discussions
No comments yet. Be the first to start the discussion!
Your Connectors
Sign in to create a connector for this server.