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 |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
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.
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.