list-domains
Distinct domain tags in the directory with usage counts, most-used first.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Distinct domain tags in the directory with usage counts, most-used first.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
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 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.
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.