agent-identity-registry
Server Details
Verifiable agent DIDs + capability discovery — the passport & directory of the A2A economy.
- Status
- Unhealthy
- Last Tested
- Transport
- Streamable HTTP
- URL
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 6 of 6 tools scored. Lowest: 2.8/5.
Each tool has a distinct purpose: self-description, discovery, listing, registration, resolution, and revocation. There is no ambiguity between them.
All tool names follow a consistent verb_object snake_case pattern (e.g., describe_agent, register_agent), making them predictable and easy to understand.
Six tools are well-scoped for an identity registry: registration, resolution, discovery, revocation, listing, and self-description. No tool is superfluous, and the count is appropriate for the domain.
The tools cover the full lifecycle: register (create/update), resolve (read), revoke (delete), plus discovery and listing. The idempotent register and retained records for revoked identities show thoughtful design. No obvious gaps.
Available Tools
6 toolsdescribe_agentCInspect
Fleet-standard self-description.
| 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 are present, and the description is too brief to disclose any behavioral traits such as side effects, authorization needs, or rate limits. The agent receives no safety or behavior context.
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 very short (3 words) but includes unnecessary jargon ('Fleet-standard') which may confuse. It front-loads the purpose but could be clearer.
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, the description doesn't need to detail return values. However, it does not clarify the scope or format of the self-description, leaving some ambiguity.
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 with 100% coverage, so the description does not need to explain parameters. However, it adds no extra value beyond 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?
The description 'Fleet-standard self-description' indicates it describes the agent itself, but 'Fleet-standard' is jargon and not universally clear. It is not a tautology but lacks specificity about what is described.
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 resolve_agent or discover_agents. The agent must infer based on the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
discover_agentsAInspect
Find ACTIVE agents matching ALL requested capabilities (AND semantics), deterministically ordered by match count then reputation.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| capabilities | Yes |
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 carries full burden. It discloses key behaviors: only active agents, AND-semantics for capabilities, and deterministic ordering by match count then reputation. It does not mention rate limits or auth requirements, but for a read-only query tool this is adequate.
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 that conveys all essential information without waste. Every phrase earns its place.
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 presence of an output schema, return values are covered. However, the description could be more complete by explaining the 'limit' parameter and clarifying pagination. Overall, it is adequate for a simple query tool but has a notable gap in parameter documentation.
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 coverage is 0%, so description should explain parameters. It implicitly explains 'capabilities' via 'matching ALL requested capabilities' but does not mention 'limit' at all, leaving its purpose and default unclear.
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 'Find' and the resource 'ACTIVE agents', specifies the AND semantics for capabilities, and the deterministic ordering. It distinguishes from sibling tools like describe_agent or resolve_agent which focus on single agents or registration details.
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 discovering agents by capabilities, which differentiates it from siblings. However, it does not explicitly state when not to use it or mention alternatives like resolve_agent for direct lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_registrationsAInspect
List registrations, optionally filtered by status (ACTIVE|REVOKED).
| Name | Required | Description | Default |
|---|---|---|---|
| status | 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; description only states basic functionality without disclosing behavior details like pagination, defaults, or performance.
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, front-loaded, 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?
Adequate for a simple tool with one param and output schema present; lacks mention of output format but not required.
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?
Adds value beyond schema by specifying allowed status values (ACTIVE|REVOKED) and defaults; compensates for 0% schema coverage.
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 it lists registrations with optional status filter, distinguishing it from sibling tools like register_agent and revoke_agent.
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 guidance on when to use this tool vs alternatives among siblings; context signals provided but not leveraged.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
register_agentAInspect
Register (or idempotently update) an agent identity. Returns a deterministic content-addressed DID. capabilities is a non-empty list of lowercase capability tags other agents can discover you by.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| pubkey | No | ||
| pricing | No | ||
| agent_id | Yes | ||
| endpoint | No | ||
| capabilities | Yes | ||
| reputation_hint | 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 discloses idempotency and deterministic DID output, which are key behavioral traits. However, it omits details on authorization, rate limits, or side effects beyond registration.
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 extremely concise—two sentences—with no wasted words. It front-loads the core action and return value, then adds a critical constraint on capabilities.
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 an output schema (not shown), the description fails to explain the purpose of most input parameters, making it incomplete for an agent to use correctly without additional context. The tool has moderate complexity (7 params, required fields) and the description does not compensate for the lack of schema descriptions.
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?
Out of 7 parameters with 0% schema description coverage, the description only adds meaning for 'capabilities' (non-empty, lowercase). Parameters like agent_id, endpoint, pubkey, pricing, reputation_hint, and name are left unexplained, leaving the agent with insufficient guidance.
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 registers or idempotently updates an agent identity, and returns a content-addressed DID. It also distinguishes from sibling tools like revoke_agent or discover_agents by focusing on creation/update.
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 it is used for both new and existing agents via the 'idempotently update' phrasing. It provides a constraint on capabilities (non-empty lowercase list) but lacks explicit when-not-to-use guidance relative to siblings.
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 identity by agent_id or DID to its full public registration.
| Name | Required | Description | Default |
|---|---|---|---|
| did | No | ||
| agent_id | 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 provided, so the description must disclose behavior. It implies a read-only lookup but does not explicitly state whether it has side effects, requires authentication, or has rate limits. The phrase 'full public registration' hints at public data but lacks certainty.
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, no filler, front-loaded with the core action. Every word contributes.
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?
Output schema exists (not shown) which likely covers return structure. However, the description does not specify whether both parameters are optional or if at least one must be provided. No mention of agent existence requirements.
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 only reiterates the parameter names: 'by agent_id or DID'. It does not explain which parameter is required, if both can be used, or any constraints (e.g., format of DID).
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 'resolve' and the resource 'identity by agent_id or DID' and the outcome 'full public registration'. It distinguishes from sibling tools like register_agent or revoke_agent which have different purposes.
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 like describe_agent or discover_agents. No mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
revoke_agentBInspect
Revoke an identity: it disappears from discovery (terminal) but its record is retained for auditability.
| Name | Required | Description | Default |
|---|---|---|---|
| did | No | ||
| agent_id | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that the identity disappears from discovery and is retained for auditability, implying irreversibility and non-destructive behavior. However, lacks details on permissions or side effects. With no annotations, this is partial 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?
Single sentence is efficient and front-loaded. Could benefit from a slight structure (e.g., separating purpose from behavior) but not verbose.
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 two undocumented parameters and a revocation action, the description is insufficient. Does not explain parameter usage, return values (though output schema exists), or how the tool fits with siblings.
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 coverage is 0% and description adds no meaning to the two parameters (did, agent_id). No guidance on which to use or how they interact.
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 'Revoke an identity' with a specific verb and resource. It distinguishes from sibling tools like register_agent (create) and describe_agent (read) by explaining the effect: disappears from discovery but retained for auditability.
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 vs alternatives (e.g., when to revoke vs delete). Does not mention prerequisites or when not to use.
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!