Registers an MCP server, skill or plugin (human session free; agent without session = 402 $0.10).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | MCP endpoint, SKILL.md URL or the plugin's repository. | |
| body | No | Long description, optional. | |
| kind | Yes | What is being registered. | |
| name | No | Display name; without it, taken from the source. | |
| tagline | No | One line saying what it is for. | |
| category | No | Category so the listing shows up under the right filter. | |
| session_token | No |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Input schema / properties / body / descriptionAdded value: +"Long description, optional."Input schema / properties / category / descriptionAdded value: +"Category so the listing shows up under the right filter."Input schema / properties / kind / descriptionAdded value: +"What is being registered."Input schema / properties / kind / enumAdded value: +[
+ "mcp",
+ "skill",
+ "plugin"
+]Input schema / properties / name / descriptionAdded value: +"Display name; without it, taken from the source."Input schema / properties / tagline / descriptionAdded value: +"One line saying what it is for."Input schema / properties / url / descriptionAdded value: +"MCP endpoint, SKILL.md URL or the plugin's repository."Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It does add important behavioral context: human sessions are free, and an agent without a session gets a 402 error and a $0.10 charge. However, it does not disclose what happens on success, whether the operation is idempotent, or what side effects registration produces.
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 front-loads the action and resource types, then appends the essential billing/error detail in parentheses. There is no filler or redundancy.
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 high schema coverage, the description is thin for a 7-parameter creation tool with no output schema and no annotations. It omits what the response looks like, whether registration is immediate or moderated, how duplicate URLs are handled, and what permissions or prerequisites are needed.
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 86%, so the baseline is 3. The description adds value by explaining the session_token parameter's cost and error behavior ('human session free; agent without session = 402 $0.10'), which is not present in the schema. This is meaningful extra semantic context.
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 ('Registers') and names the exact resource types ('MCP server, skill or plugin'), making the purpose clear. It also distinguishes itself from sibling tools like get_listing, like_listing, and create_guest by the registration action and resource scope.
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 the tool should be used when registering an MCP server, skill, or plugin, but it does not explicitly discuss when not to use it or which sibling alternative might be preferred. The billing note hints at session-related requirements but does not provide explicit usage context versus alternatives.
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.
Most tools have clearly distinct purposes, but list_listings and list_mcp_servers overlap since both return listings, with the latter being a filtered subset. This minor ambiguity could cause occasional misselection.
The majority of tools follow verb_noun snake_case (create_listing, get_listing, like_listing), but several are bare nouns (billing, contact, health) or compound nouns (api_index), breaking the consistent pattern and reducing predictability.
12 tools is well-scoped for a registry server covering listings, comments, likes, billing, and health. Each tool has a clear purpose and the count feels neither thin nor bloated.
The listing lifecycle is incomplete: create, get, like, and list exist, but there is no update or delete for listings. Additionally, only list_comments is available—no create, edit, or delete for comments—creating notable workflow gaps.