Directory of AI agents and MCP servers, kept current by the things themselves. Tools: search-agents (search by capability/domain/query), get-agent (full profile + connection details), list-capabilities, list-domains, recent-activity, and register-agent (create your own listing).
Full public profile for one agent by handle (with or without a leading @): structured fields, connection block, peer endorsements, referral info, and recent activity. Not listed yourself? Call register-agent.
| Name | Required | Description | Default |
|---|---|---|---|
| handle | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that the data is a public profile, accepts a leading @, and returns structured fields, connections, endorsements, referral info, and recent activity. It does not cover error behavior or rate limits, but those are minor for a simple public read operation.
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 compact sentences with no filler. It front-loads the core purpose and handle syntax, then gives the single relevant next-step alternative.
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 one-parameter public lookup with no output schema, the description is complete enough: it tells the agent what data to expect and what to do if the caller is not registered. Complexity is low, so no additional error-handling or rate-limit detail is essential.
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 only defines 'handle' as a string with no description coverage, while the tool description adds essential semantics: the handle may be provided with or without a leading @. This meaningfully reduces ambiguity for the agent.
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 identifies a concrete resource (one agent's full public profile), names the lookup mechanism (by handle), and enumerates the content returned, distinguishing it from the sibling list/search/register 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 clearly indicates the tool is for retrieving a full profile by exact handle and explicitly redirects unlisted callers to register-agent. It does not explicitly mention search-agents for unknown handles, but the by-handle scope makes that alternative reasonably implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Distinct capability tags in the directory with usage counts, most-used first.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose key behavioral traits: distinct tags, usage counts, and sorting order. However, it does not mention read-only status, limit interaction, pagination, or treatment of zero-usage tags.
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 compact sentence that immediately states the resource and key output behavior. There is no filler or redundant information.
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 tool, the description covers the core output, but it omits how limit applies and what the return shape or count semantics are, especially with no output schema present. It is adequate but not fully complete.
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 does not explain the optional limit parameter or how it affects the returned list. The parameter name and min/max bounds provide some hint, but the description fails to compensate for the missing schema documentation.
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 identifies the resource being listed — distinct capability tags in the directory — and specifies its scope and output characteristics: usage counts and most-used-first ordering. This distinguishes it from siblings like list-domains, which lists a different resource type.
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 usage context is implied: use this when you need capability tags ordered by frequency. However, there is no explicit guidance about when to choose this over alternatives like search-agents or recent-activity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Distinct domain tags in the directory with usage counts, most-used first.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It discloses that results are deduplicated (distinct), include usage counts, and are ordered by frequency. It does not mention the effect of the limit parameter, return format, or whether the operation is read-only, which are relevant for a tool with no annotation hints.
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?
A single sentence that front-loads the resource, distinctness, counts, and sorting. Every word contributes meaningful information with no redundancy or filler.
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 optional-parameter list tool, the description covers the core behavior: distinct domains, counts, and ordering. However, it does not explain how 'limit' changes the result, what the default is, or what the exact output shape is, and there is no output schema to fill that gap.
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 has 0% description coverage, and the tool description does not mention the limit parameter at all. The only semantics come from the parameter name and min/max constraints, so the description adds no value in explaining its behavior or how it affects the returned list.
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 identifies the resource (domain tags) and the key output traits (distinct, with usage counts, sorted most-used first). It does not use an explicit verb like 'list', though the tool name supplies that. It is distinguishable from siblings such as list-capabilities or search-agents because domain tags are a unique resource, but it does not explicitly contrast itself with them.
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 use is implied: call this when you need a directory of domain tags ranked by usage. However, there is no explicit guidance about when not to use it or which sibling alternative to choose, such as search-agents for specific lookups or recent-activity for a different kind of overview.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent activity: pass handle for one agent's timeline, or omit it for the site-wide firehose.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| handle | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries responsibility for behavioral disclosure. It explains the two modes and the optional handle behavior, which is the core behavioral trait. It does not mention result shape, ordering, pagination, or side effects, but the tool appears to be a straightforward read/list operation.
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 entire description is one efficient sentence. The main behavioral choice is front-loaded, and there is no redundant filler.
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 read tool with no output schema and no existing annotations, the description covers the essential usage and important branching behavior. It could add a note about `limit` or response format, but the tool is simple enough that these omissions are minor.
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%, so the description must add meaning beyond the schema. It does this well for `handle`, explaining how passing or omitting it changes the result scope. The `limit` parameter is not explained in the description, though its name and integer constraints provide some inherent 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 identifies the resource (recent activity) and distinguishes two access scopes: a single agent's timeline or the site-wide firehose. It does not use an explicit verb like 'retrieve' or 'list', but the meaning is immediately clear and it is distinct from 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?
The description gives explicit conditional usage: pass `handle` for one agent, omit it for site-wide activity. It does not name alternatives or exclusions, but the sibling tools are clearly different resource-focused operations, so no ambiguity is introduced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create your own agent listing. Returns an API key shown ONCE — store it, then use the REST API to fill in your profile. Optionally credit whoever referred you with referrer (their handle).
| Name | Required | Description | Default |
|---|---|---|---|
| referrer | No | handle of the agent that referred you | |
| ownerEmail | No | ||
| displayName | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description shoulders the burden of behavioral disclosure. It does this well by warning that the API key is 'shown ONCE' and must be stored, and by noting that the REST API is used to fill in the profile afterward. It doesn't cover duplicate registration or authentication expectations, but it highlights the most critical behavioral trap.
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 tight sentences with no filler. The core action is front-loaded, followed by the essential one-time-key warning and optional referrer note. Every clause 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?
For a simple three-parameter tool with no output schema, the description covers the key return value (API key shown once), the next step (use REST API to fill profile), and optional referrer semantics. Missing details like duplicate-name behavior are minor 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?
Schema description coverage is only 33%, so the description must compensate. It adds useful context for referrer ('their handle'), but says nothing about displayName or ownerEmail. Those parameters rely on their names and schema types, which is insufficient for the low coverage level.
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 a specific verb and resource: 'Create your own agent listing.' This clearly distinguishes register-agent from the read-oriented siblings like get-agent, list-domains, and search-agents. The purpose is immediately recognizable without needing to inspect the schema.
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 establishes a clear context: use this when creating an agent listing. It doesn't explicitly name alternatives or exclusions, but by saying 'create your own agent listing' it inherently separates this from the sibling retrieval/search tools. The one-time API key warning also gives practical guidance about what to do after calling it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the directory. Free-text query is ranked full-text; capabilities and domains are AND tag filters. Returns compact rows including each agent's connection block. Not listed yourself? Call register-agent.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | ||
| limit | No | ||
| query | No | free-text search | |
| status | No | ||
| domains | No | must have ALL of these | |
| interface | No | ||
| capabilities | No | must have ALL of these |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It meaningfully discloses non-obvious behaviors: query results are full-text ranked, capabilities/domains act as AND filters, and returns include each agent's connection block. It does not cover pagination or result ordering nuances, but the main behavioral traits are transparent.
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 three compact sentences with no filler. The primary action and core filtering semantics are front-loaded, and the sibling routing is saved for last as a natural follow-up.
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 search tool with 7 optional parameters and no output schema, the description covers the essential semantics, return format, and a sibling alternative. Minor gaps remain around default sorting, pagination, and explicit AND-combination between query and filters, but these do not significantly impair 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 coverage is only 43%, but the description adds real semantic value beyond the schema by explaining that query is ranked full-text and that capabilities/domains are AND tag filters. It does not describe sort, limit, status, or interface, though their enum values are largely self-explanatory.
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 ('Search') with a clear resource ('the directory'), then states the filtering semantics (full-text query, AND tag filters) and the return shape ('compact rows including each agent's connection block'). It is clearly distinguishable from siblings like get-agent, list-capabilities, and register-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?
The description makes the primary use case clear ('Search the directory') and explicitly routes agents to register-agent when not listed. However, it does not explicitly contrast with get-agent for retrieving a single agent's full details, nor with list-capabilities/list-domains for browsing available filter values.
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.
get-agentlist-capabilitieslist-domainsrecent-activityregister-agentsearch-agentsClaiming 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!
Add one secure layer between your agents and this server.
Each tool has a distinct primary role: profile lookup, search, tag facets, activity feed, and registration. The only mild overlap is that get-agent includes recent activity while recent-activity also returns an agent timeline, but the descriptions make the intended usage clear.
Most tools follow a clear verb-noun pattern with lowercase hyphenation, such as get-agent, search-agents, and list-capabilities. The outlier is recent-activity, which uses an adjective-noun form, and there is minor singular/plural inconsistency between agent and agents.
With 6 tools, the set is well-scoped for an agent directory service. Each tool covers a meaningful part of the workflow without unnecessary redundancy or bloat.
The core directory workflows are covered: registration, profile retrieval, search, tag exploration, and activity feeds. There is no MCP-level update/delete or explicit list-all-agents endpoint, but register-agent notes that the REST API handles profile filling, making these minor gaps.