MCP Registry Navigator

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool performs a distinct operation: search, fetch, compare, validate, generate config, and checklist. There is no overlap or ambiguity between them.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern (search_servers, get_server, compare_servers, validate_server_json, generate_install_config, prepare_publish_checklist), making them predictable and easy to parse.
Tool Count5/5
With 6 tools, the set is well-scoped for a registry navigator and pre-publish helper. Each tool covers a necessary step in browsing, validating, and preparing server configurations without excess.
Completeness4/5
The tool surface covers search, retrieval, comparison, validation, config generation, and publication readiness. A direct publish tool is missing, but that may be intentionally outside the 'navigator' scope, so the gap is minor.
Average 3.4/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
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, so the description is not burdened with conveying safety or completeness. The phrase 'latest' adds a slight behavioral nuance (implying freshness), but it does not describe how the limit parameter interacts with results, whether results are ordered, or any pagination behavior. It neither contradicts nor meaningfully expands on the annotations.
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 a single, compact sentence with no redundant words. It front-loads the core action and target. While it is short, it does not waste space; however, the brevity comes at the cost of necessary detail, making it less effective than a longer but more informative description.
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 (which covers return fields), the description lacks essential context for correct invocation. It does not clarify how results are limited (despite the 'limit' parameter), how the query matching works, or when to prefer this tool over get_server. The description is minimal and does not help an agent make an informed decision among the listed siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a description for 'query' ('Substring to search in server names') but no description for 'limit'. Since schema description coverage is 50%, the tool description should compensate for the missing parameter semantics, but it does not mention either parameter at all. An agent would have to infer the meaning of 'limit' from its constraints alone, which is insufficient.
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 a verb ('search') and a resource ('latest public MCP Registry server metadata'). It distinguishes the tool from siblings like get_server (which retrieves a single server) by focusing on searching, but does not explicitly clarify what 'metadata' includes or how search results are ordered. It is clear enough for a basic understanding, but leaves some ambiguity about the extent of the search.
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 such as get_server, compare_servers, or validate_server_json. It does not mention any exclusions or conditions that would help an agent decide between them. The absence of usage context is a significant gap given the sibling tools.
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?
The annotation readOnlyHint=true already covers the non-mutating nature. The description adds the fact that it returns a checklist, but no further behavioral details (e.g., what happens with invalid input). It is consistent with annotations and provides minimal added context, so a 3 is appropriate.
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?
A single, focused sentence that states the purpose without any fluff. Every word adds value, and the sentence is front-loaded with the action and target.
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?
The description omits critical usage context, such as when to call this tool versus validate_server_json or other siblings. It does not mention what constitutes 'publication readiness' or how the output might be used. Although an output schema exists, the description itself leaves the agent without enough context to decide when to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the only parameter 'server_json' has no schema description or enum. The description merely says 'for a server.json file' but does not explain the expected format, structure, or any constraints. It does not compensate for the lack of schema documentation.
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 states a clear verb ('Return') and resource ('publication readiness checklist') for a specific target ('server.json file'). It is unambiguous, but it does not explicitly differentiate from siblings like validate_server_json or generate_install_config, so it loses one point.
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 given on when to use this tool versus its siblings. The description does not mention alternatives, exclusions, or prerequisites, leaving the agent to infer appropriateness.
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?
Annotations declare readOnlyHint=true and openWorldHint=false, which the description does not contradict. The description adds minimal behavioral context beyond the annotation (e.g., that it produces a snippet for one server), but does not disclose limitations, side effects, or dependencies. With annotations covering the safety profile, a score of 3 is appropriate.
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 single, front-loaded sentence with no wasted words. It delivers the core purpose immediately and is efficiently structured.
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 (so return values are not needed in the description), the input parameter is completely underspecified. With no guidance on server_json structure and no usage context, the tool is not fully described for an agent to call it correctly. The description is too sparse for a tool with an unstructured object parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about the server_json parameter. The schema only indicates an object with additionalProperties, so an agent has no idea what fields or structure to provide. The description does nothing to clarify parameter meaning.
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 a clear action ('generate'), a specific output ('MCP client configuration snippet'), and a scope ('for one server'). It is distinct from sibling tools like search_servers or validate_server_json, which focus on retrieval or validation, not generation.
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 prerequisites, typical scenarios, or when to prefer another tool such as prepare_publish_checklist. Usage context is entirely absent.
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?
Annotations already declare readOnlyHint=true, so the description is consistent with that. The phrase 'metadata record' adds a small nuance that it returns metadata, not the actual server, but it does not disclose any additional behavior such as error handling, version resolution, or pagination. Given annotations cover the safety profile, the description adds minimal extra value.
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?
A single sentence with no filler. The purpose is front-loaded and every word contributes. It is appropriately minimal without sacrificing clarity.
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 simple fetch-with-optional-version tool, the description, combined with schema and output schema, is complete. The absence of explicit error-handling context is acceptable given this is a read-only operation with openWorldHint and the output schema defines the return structure. A minor gap is the lack of mention of 'version' behavior, but that is documented in the schema.
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%—both 'name' and 'version' are documented in the input schema. The description adds no additional parameter semantics beyond what the schema already provides, so the baseline score 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 action ('Fetch') and the resource ('one MCP Registry server metadata record'). It distinguishes from siblings like search_servers (which presumably returns multiple) and compare_servers (which compares), making the tool's specific role obvious even without examining the schema.
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 explicit guidance on when to use this tool versus alternatives. It does not mention that search_servers might be better for finding servers or that this tool is for retrieving a known server by name. The agent must infer usage context from the schema and sibling names, but the description itself offers no direction.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and open-world behavior; the description does not contradict these. It adds the specific aspects compared (package types, transports, summaries), but offers no detail on output shape, behavior with unknown names, or duplicate inputs. With annotations lowering the bar, this is adequate but not rich.
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?
An eleven-word single sentence with zero waste. The verb and resource are front-loaded, and every word contributes meaning. Appropriately sized for the tool's simplicity.
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 tool is low-complexity (one parameter, no nested objects), an output schema exists so return values need no explanation, and annotations cover the safety/open-world profile. The description identifies the comparison dimensions and domain. The only minor gap is not explicitly framing it as a multi-server side-by-side comparison distinct from get_server, but nothing critical for correct invocation is missing.
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 0%, so the schema gives only 'names: array of strings, min 2, max 5'. The description adds crucial domain context that 'names' refers to MCP server names, which the bare schema omits. However, it does not specify whether names must be exact identifiers, case sensitivity, or ordering semantics — leaving moderate ambiguity for the sole parameter.
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 names a specific verb ('Compare') with a defined resource ('MCP servers') and the precise comparison dimensions (package types, transports, summaries). This clearly distinguishes it from siblings — search_servers, get_server, validate_server_json, generate_install_config, prepare_publish_checklist — none of which perform a comparison.
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 verb 'compare' implies usage for comparing multiple servers side-by-side, and the minItems=2 constraint reinforces that. However, the description offers no explicit when-to-use/when-not-to-use guidance and names no alternatives, such as directing single-server lookups to get_server. Usage context is inferred, not stated.
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?
Annotations already declare readOnlyHint:true, so the description adds the specific 'validate' behavior but does not go beyond the annotation's safety profile. It reinforces that this is a read-only operation but adds no new behavioral details.
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 single, tightly worded sentence with no filler words. The verb 'Validate' is front-loaded, and the scope is immediately clear.
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 simple single-parameter tool and the presence of an output schema (which handles return details), the description covers the essential purpose and the non-publishing aspect. No additional information is strictly needed for an agent to call it correctly.
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 0%, so the description must compensate. It clarifies that the server_json parameter refers to 'server.json metadata', adding meaning beyond the generic 'Server Json' in the schema. However, it does not explain the object vs. string distinction or expected format beyond that.
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 specific verb 'Validate', the resource 'MCP Registry server.json metadata', and adds the scope 'without publishing it'. This distinguishes it from a publish action and clearly separates it from sibling tools like search_servers or prepare_publish_checklist.
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 phrase 'without publishing it' provides clear context that this tool is for pre-publish validation, implying when it should be used. However, it does not explicitly name alternatives or exclusions, though the context makes usage obvious.
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:

[![mcp-from-scratch MCP server](https://glama.ai/mcp/servers/djibrilIbnSaid/mcp-from-scratch/badges/card.svg)](https://glama.ai/mcp/servers/djibrilIbnSaid/mcp-from-scratch)

Score Badge

Copy to your README.md:

[![mcp-from-scratch MCP server](https://glama.ai/mcp/servers/djibrilIbnSaid/mcp-from-scratch/badges/score.svg)](https://glama.ai/mcp/servers/djibrilIbnSaid/mcp-from-scratch)

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/djibrilIbnSaid/mcp-from-scratch'

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