@zeromodern/mcp-server-0mod

Official

by zeromodern

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Server Quality Checklist

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

Latest release: v1.3.0
Disambiguation4/5
Most tools target distinct tasks (scraping, redaction, compression, sentiment, embeddings), and descriptions clarify their purposes. The only near-overlap is between embed_text and embed_multilingual, but their language/vector-size differences make them distinguishable.
Naming Consistency2/5
Tool names mix verb-noun patterns (embed_text, summarize_text), noun-compounds (dex_price_summary, x_sentiment), and adjective-noun/cryptic forms (stealth_dom, rag_shrink, airgap_scrub). No consistent naming convention is used across the set.
Tool Count4/5
With 11 tools, the count is within a reasonable range and not excessive. However, the tools span diverse domains (web/data, cleaning, AI analysis), giving the set a somewhat scattershot feel rather than a focused toolkit.
Completeness2/5
There is no clear domain or lifecycle model; the tools are a random assortment of utilities. Obvious operations are missing (e.g., search, translation, storage) that would make workflows coherent, and the breadth of unrelated features prevents a sense of complete coverage.
Average 3.5/5 across 11 of 11 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- Last stable release on August 7, 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It mentions the output dimension (768) and the model, but does not explain the return format, input size limits, batch handling, or any side effects. This lack of detail leaves the agent uncertain about the tool's runtime behavior.
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, efficient sentence that front-loads the main verb 'Generates' and immediately conveys the purpose, model, and dimensions. Every word earns its place; there is no filler or repetition. This is exemplary conciseness.
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?
Given the tool has one parameter, no annotations, and no output schema, the description should provide more context about return values and constraints. It only states the embedding dimension and use case, but omits practical details like output format (e.g., list of floats), maximum input length, and batching limitations. An agent would need to infer or experiment to use this tool reliably.
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?
The schema description coverage is 0%, so the description must compensate for explaining parameters. The description does not mention 'text' at all, nor does it clarify accepted input types (string vs array) beyond what the schema already states. It adds no semantic value for the parameter, failing to help the agent understand how to construct inputs effectively.
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's function: generating 768-dimensional dense vector embeddings for RAG and semantic search. It names a specific model (BAAI BGE-Base), adding specificity. However, it does not explicitly distinguish itself from the sibling tool 'embed_multilingual', which likely also generates embeddings, so it falls short of a 5.
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 mentions 'RAG & semantic search' as use cases, but does not explain when to choose embed_text over embed_multilingual or other sibling tools. There is no statement of exclusions or preferred scenarios, leaving the agent without clear selection criteria.
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 provided, the description carries the full burden for disclosing behavior. It mentions the AI model, implying an external API call with potential latency/cost, but it does not disclose limitations, output format flexibility, or side effects. Notably, it claims 'structured bullet points' while the schema's 'format' parameter allows 'paragraph', creating an inconsistency in behavioral expectations.
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 filler words. It efficiently conveys the core purpose and a distinctive aspect (AI model). This is an optimal length for a tool 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?
The one-sentence description is insufficient for a tool with no annotations and no output schema. It lacks usage context, behavioral caveats, and details about output variations (e.g., paragraph vs. bullets). Given the tool's moderate complexity (3 parameters), more context is needed to safely invoke it.
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 description coverage is 100%, so the parameters 'text', 'format', and 'maxLength' are already well-described. The description adds no extra semantic meaning beyond 'structured bullet points', which does not clarify how 'format' or 'maxLength' affect output. Baseline 3 applies because the schema does the heavy lifting.
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 summarizes text and specifies the output style ('Executive TL;DR', 'structured bullet points') and the underlying model ('Workers AI Llama 3.1'). This distinguishes it from sibling tools like x_sentiment or dex_price_summary, which are also potentially summarizers but with different purposes.
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, nor does it mention any exclusions or prerequisites. Sibling tool names are available, but the description does not reference them or set usage boundaries. It only states what it does, leaving the agent to infer when to use it.
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 the full burden. It mentions the model (Workers AI Llama 3.1) but does not disclose whether the tool is read-only, authentication needs, rate limits, or what the output looks like. For an analysis tool, this is a significant gap.
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, focused sentence that front-loads the core action and resource. Every word contributes to the purpose, making it highly concise with no wasted information.
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?
Given no output schema and no annotations, the description is incomplete. It omits the return format (e.g., sentiment label, score, or narrative) and does not provide behavioral context like error handling or timeouts. An agent would be uncertain about what the tool returns after invocation.
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 covers 100% of parameters with a clear description ('Topic, ticker, or text sample to analyze'). The description adds context ('market & social') and 'tokens' but does not materially change the meaning beyond the schema, so the baseline score of 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 clearly states the action ('Analyze') and the resource ('market & social sentiment for topics/tokens'), distinguishing it from sibling tools like summarize_text or embed_text. The mention of 'Workers AI Llama 3.1' adds specificity without confusion.
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 through the purpose (sentiment analysis), but the description does not explicitly state when to use this tool over alternatives or provide exclusions. Sibling tools are mostly unrelated, so no direct comparison is offered.
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 must carry the full burden of disclosing behavior. It does not mention whether the operation is read-only, what the output format is, whether there are side effects, or any rate limits or auth requirements. The phrase 'using Workers AI' hints at external dependency but lacks detail.
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 efficiently communicates the action and target.
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 description adequately explains the purpose and input, but it lacks information about the return value or output behavior, especially since there is no output schema. It also provides no usage guidance. Given the simplicity of the tool, this is adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a description for the 'text' parameter, and the tool description adds value by enumerating specific PII types (SSN, phone, email, ZIP) that are redacted, clarifying the scope beyond the generic 'sensitive PII' in the schema.
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 redacts specific PII types (SSN, phone, email, ZIP) using Workers AI. The verb 'redact' and the resource are specific, and it is distinct from sibling tools that perform unrelated tasks like summarization or embedding.
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. There is no mention of use cases, prerequisites, exclusions, or scenarios where this tool is preferred over sibling tools, leaving the agent without decision support.
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 word 'Query' implies a read-only operation, and the description mentions the data source and result types. However, it does not disclose potential rate limits, response format, error conditions, or whether the operation is safe beyond the implied read-only nature.
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 that efficiently communicates the tool's core purpose without any wasted words. It is appropriately concise for the tool's simplicity.
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?
For a simple one-parameter tool with no output schema, the description conveys the purpose and general result types (availability and WHOIS status). However, it does not specify the exact return structure or handle edge cases like invalid domains, leaving gaps that a richer description could 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?
The input schema already provides complete coverage for the 'domain' parameter with an example. The description adds no additional parameter semantics beyond what the schema already states, 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 uses the specific verb 'Query' with the resource 'global RDAP registry' and clearly states two outcomes: domain availability and WHOIS status. This makes the tool's function unambiguous and distinguishes it from the unrelated sibling tools.
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, nor does it mention exclusions or prerequisites. The intended usage is implied only by the tool's name and description, but no explicit context is given.
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 of explaining behavioral traits. It states the stripping action but does not disclose whether the transformation is lossy, what the output format is (e.g., returns cleaned code string), or any limitations (e.g., sourcemap syntax dependence). This is minimal and leaves the agent guessing about the result.
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, concise sentence that is front-loaded with the verb and lists the specific items stripped. Every word earns its place; there is no fluff or repetition.
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 simple with two parameters and no output schema. The description explains the core functionality sufficiently, but does not explicitly state what is returned (e.g., the cleaned code string). Since no output schema is provided, this small omission keeps it from being a 5.
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%, with descriptions for both parameters ('Code content to clean', 'Programming language'). The tool description adds no additional meaning beyond repeating the stripping action. Baseline 3 is appropriate as the schema does the heavy lifting.
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 specific verb ('Strip') and resource ('comments, docstrings, whitespace, and sourcemaps from code files'), clearly distinguishing it from sibling tools like image_ocr_shrink or summarize_text. It leaves no ambiguity about what the tool does.
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 usage for cleaning code files, but provides no explicit when-to-use guidance or alternatives. It doesn't mention cases to avoid (e.g., when preserving comments is needed), so the agent must infer from the sibling list and schema.
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 provided, the description carries the full burden of behavioral disclosure. It only mentions 'bypassing simple IP blocks' but does not explain what this bypass entails, potential failures, request modifications, or what the response contains (e.g., raw HTML). This is a significant gap for a specialized 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 a single sentence, front-loaded with the action and key differentiator. 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.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a specialized behavior (bypassing IP blocks) but no output schema or annotations. The description does not explain the return format, limitations, or edge cases, leaving the agent without enough information to fully trust the tool's invocation.
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 covers 100% of parameters, with 'url' described as 'Target URL to fetch'. The description does not add any parameter semantics beyond the schema, so the baseline score of 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 clearly states a specific action ('Fetch web pages') with a distinct qualifier ('from Cloudflare edge bypassing simple IP blocks'). This distinguishes it from all sibling tools, which focus on scrubbing, denoising, sentiment, or embedding.
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?
Provides clear context for when to use the tool: when fetching pages protected by Cloudflare with simple IP blocks. However, it does not explicitly mention alternatives or when not to use it, though no sibling tool performs a similar fetch function.
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; description implies a read-only operation via 'Fetch' but does not disclose auth, rate limits, or error behavior. Adds output scope 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?
Single, well-structured sentence; front-loaded with verb; no redundant wording.
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?
Suitable for a simple one-param tool; lists key output fields. Lacks explicit response shape but adequate for basic use.
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 covers 100% with clear description ('Token symbol or contract address'); description adds no extra parameter nuance.
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?
Clear verb 'Fetch' plus specific resources ('real-time DEX price, 24h volume, liquidity, and top pair stats') and scope ('across chains'). Distinguishes from unrelated siblings.
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?
No explicit when-to-use guidance or alternatives. The purpose is evident, but no contextual trigger scenarios or exclusions are provided.
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 full burden. It does disclose the output dimensionality (1024) and model (BAAI BGE-Large), which is useful. However, it omits other behavioral traits such as output format, handling of arrays, any rate limits, or normalization behavior. The disclosure is partial.
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, concise sentence that is front-loaded with the action. It contains no redundant words or filler, making it highly efficient and easy to process.
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 simple with one parameter and no output schema. The description covers the core purpose, dimensionality, and model, which is largely sufficient for selection. It could mention the return type explicitly, but that is reasonably implied by 'embeddings'. Overall, it is adequately complete for its complexity.
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 has 0% description coverage, so the description must compensate. It adds meaning to the 'text' parameter by specifying it is multilingual and long text, which provides some semantic context. However, it does not explain that the parameter can be a single string or an array, nor does it give format details beyond the schema's type information.
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 function: generating 1024-dimensional dense vector embeddings for multilingual and long text using the BAAI BGE-Large model. This specifies the verb, resource, and key differentiators from siblings like embed_text, making the purpose explicit and distinct.
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 usage for multilingual and long text, giving some context on when to use it. However, it does not explicitly state when not to use this tool or reference alternatives (e.g., embed_text for simpler cases). The guidance is implied rather than clearly 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?
With no annotations, the description carries the full burden for behavioral disclosure. It states the transformation but does not mention limitations, side effects, or whether the compression is lossy.
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?
One concise sentence that efficiently communicates the tool's purpose without any wasted 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?
For a simple one-parameter tool with no output schema, the description adequately conveys the main function, though it could be more explicit about the output format and potential constraints.
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 single parameter 'html' is fully documented in the schema with 100% coverage. The tool description adds little beyond restating the input format.
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?
Describes a specific transformation (raw HTML to clean markdown & headings) with a clear purpose (RAG context windows). This clearly distinguishes it from siblings like image_ocr_shrink or summarize_text.
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?
Implies usage for RAG context windows but does not explicitly state when to use this tool instead of alternatives like code_denoise or summarize_text, nor when not to use it.
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?
Without annotations, the description carries full burden. It adds context by mentioning 'clean' text and 'table markdown', and names the AI model. However, it does not disclose limitations (e.g., image size, URL requirements beyond schema), privacy, or exact processing behavior.
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?
One sentence, front-loaded with the action ('Extract'), and contains no filler. Every word adds value: 'clean' indicates quality, 'text and table markdown' specifies output formats, and the model name provides implementation context.
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 and no output schema, the description adequately covers purpose, output, and technology. It does not explain edge cases (e.g., supported image types, size limits), but for this simplicity, it is sufficiently complete.
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 single parameter imageUrl is fully described in the schema as 'Public image URL to parse', providing complete coverage. The description adds no additional parameter-specific detail, so baseline 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 explicitly states the tool extracts clean text and table markdown from images, using a specific verb and resource. This clearly distinguishes it from sibling tools like stealth_dom or airgap_scrub, which serve different purposes.
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 clearly implies when to use the tool (when you need text or markdown tables from images) and names the underlying model. It does not explicitly state alternatives or exclusions, but the use case is obvious given the tool name and description.
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-server-0mod MCP server](https://glama.ai/mcp/servers/zeromodern/mcp-server-0mod/badges/card.svg)](https://glama.ai/mcp/servers/zeromodern/mcp-server-0mod)

Score Badge

Copy to your README.md:

[![mcp-server-0mod MCP server](https://glama.ai/mcp/servers/zeromodern/mcp-server-0mod/badges/score.svg)](https://glama.ai/mcp/servers/zeromodern/mcp-server-0mod)

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/zeromodern/mcp-server-0mod'

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