RegistryTools

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.1
Disambiguation3/5
Most tools have distinct purposes, but search_tools and search_hot_tools overlap significantly. An agent could easily choose the wrong one, especially since search_hot_tools only searches a subset of tools.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (get_, search_, list_, register_, unregister_). The two search tools are clearly named with a descriptive modifier, maintaining predictable structure.
Tool Count5/5
With 6 tools, the server is well-scoped for a tool registry. Each tool covers a core registry operation without unnecessary bloat or missing essentials.
Completeness3/5
The registry covers basic CRUD (register, get, unregister) and search/list capabilities, but there is no update tool and no way to list all tools without filtering by category. This leaves notable gaps for managing and exploring the full registry.
Average 3.5/5 across 6 of 6 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on January 11, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. However, it only restates the tool's purpose ('add new tool metadata') without explaining side effects, uniqueness constraints, overwrite behavior, or requiring special permissions. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, focused sentences with no filler or repetition. It achieves maximum clarity with minimal words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description omits critical context for a write operation: validation behavior, error conditions, idempotency, or consequences of registering duplicate tool names. This incompleteness could lead to misuse or uncertainty for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are documented in the schema. The description adds no extra semantic detail, but the baseline of 3 is appropriate since the schema handles parameter explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verbs ('添加', '注册') and a clear resource ('工具注册表'), making the tool's function immediately obvious. It distinguishes itself from sibling tools like unregister_tool and search_tools by focusing on the act of registration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 alternatives, nor are any prerequisites or exclusions mentioned. The description simply states the action without context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does not state whether the operation is read-only, describe the return structure, or explain how search_method affects behavior—significant gaps for a search tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the action and a brief elaboration. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a straightforward search operation with an output schema and fully described parameters, but the description lacks behavioral context such as safety profile, return details, and search_method implications. It is minimally complete but leaves gaps that annotations would normally fill.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters have descriptive schema entries covering 100% of the schema, so the baseline is 3. The description only mentions the query string and adds no additional meaning beyond what the schema already provides for limit or search_method.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches registered MCP tools using a query string, giving a specific verb (search) and resource (registered MCP tools). It distinguishes from siblings like search_hot_tools by emphasizing 'registered tools' but does not explicitly name alternatives or exclusion criteria.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus siblings such as search_hot_tools or list_tools_by_category. It only states what the tool does without context or exclusions, leaving the agent to infer appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only states the purpose. It does not disclose behavior for edge cases like invalid categories, the effect of the limit parameter, or the structure of the returned tool list.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, but the second sentence is largely redundant with the first. It is front-loaded and contains no fluff, though it could be condensed further.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, but the description misses key context such as the special 'all' category value and how the limit parameter interacts. Since the schema covers these details, the description is minimally sufficient but not rich enough for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides complete descriptions for both parameters (100% coverage). The tool description adds no extra semantic value beyond the schema, so it relies entirely on the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists tools by category, using a specific verb and resource. It distinguishes from sibling tools like search_tools by focusing on category-based listing. The second sentence adds specificity about 'all tools under the specified category'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for listing tools by category but provides no explicit guidance on when to choose this over search_tools or get_tool_definition. The schema hints at using 'all' for all categories, but the description itself does not offer alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It states that it returns 'complete metadata including input and output Schema', which implies a read-only operation and clarifies the return content. However, it does not disclose behavior for nonexistent tool names, error cases, or any side effects. The disclosure is adequate for a simple getter but remains minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two lines, the first stating the primary purpose and the second detailing the return value. It is front-loaded and contains no filler words, earning a perfect conciseness score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with a single parameter, a true output schema, and no annotations, the description adequately conveys the tool's purpose and return value. It does not cover edge cases or error handling, but given the simplicity of the operation and the presence of an output schema, it is sufficiently complete without requiring additional explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single parameter 'tool_name' with a description '工具名称'. The description adds no additional semantic meaning beyond referencing the 'specified tool' in the first sentence. With 100% schema description coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action and target: '获取指定工具的完整定义' (get the complete definition of the specified tool). This is a specific verb+resource pairing, and it distinguishes from sibling tools like search_tools (which search) and list_tools_by_category (which list) by focusing on retrieving a single tool's full definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention, for example, that this is for fetching a specific tool's metadata while search_tools is for discovering tools. No exclusions or alternative suggestions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The description clearly states a destructive removal action, but it does not disclose side effects, reversibility, or any prerequisites. For a simple removal this is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and gets to the point. The second sentence provides the actual meaning. The first line '注销工具' is slightly redundant with the tool name but acts as a heading. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no nested objects) and the presence of an output schema, the description sufficiently covers the core action. It does not address error cases or expected output, but for a basic unregister operation this is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (only param tool_name is described). The description adds little beyond the schema, just referring to '指定的工具' (the specified tool). It does not elaborate on what valid tool_names are or where to find them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool removes a specified tool from the tool registry. The verb '移除' (remove) and resource '工具注册表' (tool registry) are clear and distinguish it from siblings like register_tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this when you need to remove a tool from the registry. However, there is no explicit mention of when not to use it or alternatives (e.g., if you only need to view definitions, use get_tool_definition). No exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It clearly states the key behavior of skipping cold tools and defines hot/warm tools. It does not mention side effects, but for a search tool, read-only behavior is implied. The added context about frequency categories goes beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a brief, well-structured paragraph. It first states the purpose, then explains the scope and definitions, with no redundant sentences or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a search tool with an output schema: it clearly defines the filtering scope and motivation. It could be slightly more explicit about the relationship to the sibling 'search_tools', but the 'only' phrasing already communicates that it is a subset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% because all three parameters have descriptions. The tool description does not add any additional parameter-level meaning, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'quick search hot tools' and explicitly defines that it only searches hot and warm tools while skipping cold tools. This clearly distinguishes it from the sibling 'search_tools' tool by specifying the scope and performance motivation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that this tool is for performance optimization by skipping cold tools, which implies it should be used when you only need hot/warm tools. However, it does not explicitly name the alternative 'search_tools' for full searches, so there is clear context but no explicit exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![RegistryTools MCP server](https://glama.ai/mcp/servers/GeerMrc/RegistryTools/badges/card.svg)](https://glama.ai/mcp/servers/GeerMrc/RegistryTools)

Score Badge

Copy to your README.md:

[![RegistryTools MCP server](https://glama.ai/mcp/servers/GeerMrc/RegistryTools/badges/score.svg)](https://glama.ai/mcp/servers/GeerMrc/RegistryTools)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/GeerMrc/RegistryTools'

If you have feedback or need assistance with the MCP directory API, please join our Discord server