DS4AI MCP

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Each tool names a distinct artifact or audit focus (head, JSON-LD, sitemap, robots, images, cache, palette, contrast). The only mild overlap is audit_surface versus audit_findability/audit_delivery, but the descriptions clearly differentiate a broad holistic audit from in-depth single-axis audits.
Naming Consistency5/5
Tool names consistently follow a verb_noun pattern: generate_* for output serializers, audit_* for auditors, plus solve_palette and check_contrast. There is no mixed casing or vague verb style, making the naming pattern predictable and readable.
Tool Count5/5
11 tools is well within the ideal scope for a web-correctness toolkit. Each generator and auditor addresses a distinct deliverable or audit pass, and none feels redundant or out of place.
Completeness4/5
The set covers core generation (head, structured data, sitemap, robots, images, cache) and auditing (surface, findability, delivery) plus color accessibility. The main gap is that index/noindex control is mentioned as living in the head, but no tool directly emits that meta robots directive.
Average 3.9/5 across 10 of 11 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under Apache 2.0.
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?
No annotations are provided, and the description does not disclose any behavioral aspects such as side effects, read-only nature, or rate limits. It simply says 'Audit' without clarifying whether it modifies anything or is purely observational.
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 with no redundant or filler content. It efficiently lists the key audit areas without unnecessary elaboration.
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 provides specific details about what the audit covers, which is sufficient for a simple one-input tool. However, it does not mention what the output looks like or any edge cases, but given the absence of an output schema, the provided scope is mostly adequate.
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 a single 'html' parameter with 100% coverage, and the description mentions 'page HTML string', which adds minimal clarity. Since coverage is high, the baseline is 3, and the description does not significantly exceed that baseline.
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 audits an HTML string for delivery performance, listing specific checks (unsized images, lazy-loaded first image, render-blocking head scripts, inline @font-face without font-display). It distinguishes from sibling audit tools by focusing on delivery-specific issues.
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 does not provide any guidance on when to use this tool versus other audit tools (e.g., audit_surface or audit_findability). There is no explicit scenario or condition suggesting when delivery auditing is appropriate.
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 must disclose behavior. It states the tool computes the ratio and checks thresholds, which is the core action. However, it does not specify the return format (e.g., does it return a boolean, the ratio, or a pass/fail object?) or any error handling for invalid hex inputs. This is a gap given the lack of annotations.
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, well-structured sentence that front-loads the purpose with the verb 'Check' and efficiently includes the key thresholds. It is concise with no unnecessary words, earning a perfect score.
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 simple (two parameters, no output schema), but the description does not fully explain what the tool returns. Since there is no output schema, the description should clarify the return value, which it only implies by saying 'whether it clears'—it doesn't explicitly state the output format or any additional information like the ratio itself. Some context is provided (WCAG 2.1, AA thresholds), but completeness suffers from missing return details.
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 that the parameters are hex colors and mentions the AA thresholds, which provides context beyond the parameter names. However, it does not detail the exact format (e.g., with or without '#') or clarify which parameter is foreground vs. background beyond the names themselves. This is some added meaning but not comprehensive.
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 checks WCAG 2.1 contrast ratio between two hex colors and evaluates against AA thresholds. The verb 'Check' and specific resource (contrast ratio) make the purpose unambiguous, and it is distinct from sibling tools like generate_sitemap or solve_palette.
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 (e.g., having hex colors), when not to use it, or mention any related tools. This leaves the agent to infer usage context from the tool name alone.
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 burden of disclosing behavior. It describes the output content (revalidating HTML, caching assets as immutable), giving some transparency about what the generated config will do. However, it does not mention whether the tool writes files, returns a string, or has side effects on the target host. This is a partial disclosure but not comprehensive.
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, dense sentence that conveys the core purpose and key behavior without any redundant words. It is appropriately front-loaded and earns every word, making it highly concise and well-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?
Given the lack of annotations, no output schema, and an undocumented nested 'options' parameter, the description is insufficiently complete. It does not explain what the tool returns, how to use options, or any edge cases. For a tool generating configuration, the user needs to know the output format and how to customize behavior via options, both of which are absent.
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 schema description coverage is 0%, so the description must compensate for parameter documentation. It does indirectly reference the 'target' enum by naming the hosts, but it provides no explanation of the 'options' object or its possible properties. The description adds minimal value beyond the schema for the 'target' and none for 'options'.
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 generates cache-header configuration for a specific set of hosts (netlify, vercel, nginx) and specifies the caching rules (revalidate HTML, cache content-hashed assets as immutable for a year). This is a specific verb+resource action, and it distinguishes itself from sibling tools that handle other aspects like head tags, JSON-LD, sitemaps, and robots.
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 used when generating cache headers for these hosts, but it does not explicitly state when to use it versus alternatives, nor does it provide any exclusions or prerequisites. The scope is clear from the description, but there is no direct guidance on selection among nearby 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?
With no annotations, the description carries the burden of behavioral disclosure. It details what the audit checks (head essentials, Open Graph, Twitter, JSON-LD, canonical agreement), which is useful, but it does not describe the return format, whether it is read-only, or any side effects. The agent cannot predict output structure or potential errors.
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 states the primary purpose first, then lists specific audit dimensions. Every word adds value with no redundant phrases or unnecessary detail.
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 audits multiple complex aspects but has no output schema and only one parameter. The description enumerates the audit scope but omits any explanation of the output format, scoring, or return structure. For a tool with this complexity and no structured return definition, additional detail on the result is needed.
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?
Schema coverage is 0%, so the description must compensate. It identifies the sole parameter as a 'page HTML string', which clarifies the expected content type and purpose. However, it does not specify whether the string must be a full document or fragment, nor any formatting constraints.
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 action (audit) on a specific resource (page HTML string) and enumerates exact audit dimensions (head essentials, Open Graph, Twitter, JSON-LD validity, canonical-og:url agreement). This clearly distinguishes it from sibling tools like generate_head or audit_surface.
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 implies use when you have an HTML string and need to assess findability, but it provides no explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives like audit_surface or audit_delivery. The context for choosing this tool over siblings is 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?
With no annotations, the description must disclose all behavioral traits. It mentions the escaping of </script>, which is a valuable detail, but it does not specify the return format (e.g., string vs. DOM node), error handling, or side effects. The tool appears safe, but the description lacks comprehensive behavioral disclosure.
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, well-structured sentence that conveys the action, input, output, and an important safety detail (escaping). It is concise, front-loaded, and contains no unnecessary words, making it highly scannable for an agent.
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 covers the core functionality but leaves gaps. There is no output schema, so the description should specify what is returned (e.g., a string containing the script tag). It also does not address error conditions or usage prerequisites. For a simple one-parameter tool, this is adequate but not fully complete.
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 no description on the schema property, so the description compensates by explaining that it accepts a schema object or an array of them. This adds semantic meaning beyond the schema's type declaration, clarifying what kind of objects are expected. It covers the single parameter adequately, though it could elaborate on the structure of the schema.org objects.
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: it serializes schema.org objects into a JSON-LD script tag. It specifies the input format (single object or array) and a key output detail (escaping </script>). This distinguishes it from siblings like generate_head or generate_sitemap, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when JSON-LD output is needed but does not explicitly state when to use this tool versus alternatives. Since the tool name and purpose are self-evident, the usage context is clear, but there is no explicit guidance on when to prefer it or when not to.
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 states the transformation (serialize) but omits behavioral details such as output format specifics (XML declaration, encoding), error handling for invalid URLs, or whether it validates input. The operation is simple and read-only in nature, so a score of 3 reflects adequate disclosure for a pure function.
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 main purpose and input details. There is no redundancy or filler, making it highly concise and structured.
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 simple with one parameter, and the description covers the input adequately. However, there is no output schema and the description does not clarify the exact return format beyond implying a serialized XML string (e.g., whether it includes XML declaration, pretty printing, or encoding). This gap in output specification keeps it from being fully complete.
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 schema provides zero coverage and only defines 'urls' as an array of strings or objects. The description compensates well by explicitly listing accepted formats: strings or objects with loc, lastmod, changefreq, priority. This adds meaningful semantics beyond 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 serializes a sitemap.xml from a list of canonical URLs, distinguishing it from sibling tools like generate_robots and generate_head. It uses a specific verb (Serialize) and resource (sitemap.xml) with input format details.
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 generating sitemap.xml but offers no explicit guidance on when to use this tool versus alternatives like generate_robots or generate_head. There is no when-not-to-use or alternative mention, so it only meets the implied usage level.
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 description states it returns the semantic token set, but provides no information about side effects, errors, or permissions. With no annotations, more behavioral detail would be beneficial.
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 packs all necessary parameter explanations and the return type without redundancy.
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 adequately covers parameters and return, but lacks deeper context on what 'verified contrast floors' entails or any constraints, though it's reasonably complete for a domain-specific tool.
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 description clarifies each parameter (mode, notch, family, vision) with enums and examples, adding meaning beyond the schema's bare types and enums, though not exhaustive.
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 solves a TEMPER palette to verified contrast floors, which is specific and distinct from sibling tools like audit_surface or generate_head.
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 does not explicitly mention when to use this tool over alternatives, nor does it provide usage context beyond the operation itself.
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. It communicates core behavior (serialization) and accepted input shapes, but does not disclose output format, potential side effects, or default handling of omitted fields. No contradiction exists, but behavioral coverage is only partially complete.
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 compact and front-loaded with the tool's core purpose. Both sentences earn their place: the first states what the tool does, and the second provides essential parameter and exclusion guidance.
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?
Given the sparse schema, absent annotations, and no output schema, the description provides helpful but incomplete context. It covers the main inputs and an important exclusion, yet the 'groups' property is unexplained, and behavior like return value or output destination is not stated.
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% and the schema properties are empty, so the description must compensate. It usefully explains allow/disallow accept a string or array and sitemap accepts one or more URLs, but it does not mention the 'groups' parameter at all, leaving its meaning ambiguous.
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 identifies a specific action ('Serialize a robots.txt') and resource, and states it is for crawl control. It also distinguishes itself by explicitly excluding index control, which belongs in a head robots directive, reinforcing separation from generate_head and generate_sitemap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It tells the agent exactly what to pass: allow/disallow as string or array and one or more sitemap URLs. It also gives a clear when-not-to-use instruction by directing index control to the head robots directive, providing an explicit exclusion boundary.
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, the description carries the burden of disclosing behavior. It states that it returns a string and includes the lang attribute, implying a pure, read-only generation operation. It does not mention any side effects, permissions, or error conditions, but for a generator that creates a string, this is acceptable.
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 immediately states the tool's primary function, then adds the lang attribute detail. There is no fluff or redundancy; every part contributes to understanding the tool.
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—one parameter, no output schema—the description provides sufficient context about what it returns and the SSR/build-time context. It could have mentioned potential errors or how missing metadata fields are handled, but for a basic generator, it covers the essentials.
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 briefly mentions 'flat metadata object' and lists the output tags, but does not explain the purpose of each input property (e.g., lang, image, title, siteName, canonical, description) or which are required. The schema lists properties and types, but the description adds minimal value beyond what the schema exposes.
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 identifies the tool's purpose: generating head tags (title, description, canonical, Open Graph, Twitter card) for a page. It specifies the output as an SSR/build-time string and mentions the additional lang attribute, distinguishing it from sibling tools like generate_jsonld, generate_sitemap, and generate_robots, which cover different outputs.
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 provides clear context (for a page, SSR/build-time) and implies when it might be used. Without explicit alternatives or exclusions, it doesn't fully guide the user away from or toward other tools, but the context is enough for most scenarios.
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?
No annotations are provided, so the description carries the full burden. It discloses a key behavioral trait: the report 'declares the axes a static check cannot judge rather than reporting them clean,' providing honesty about limitations. It also mentions fetching served HTML, implying a network request. It doesn't discuss safety or side effects, but as an audit tool, the implied read-only nature is acceptable.
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 sentences, front-loaded with the core purpose, and each clause adds value. It lists the six axes compactly and explains the output behavior without redundancy. No 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?
Given no output schema, the description appropriately outlines the return value ('per-axis report') and its honesty about unjudgeable axes. It covers inputs and output behavior. It references 'MISSING conformance auditor' without explanation, but that's a tool-specific detail. The absence of rate limits or auth notes is minor for an audit tool, and complexity is low with only two string parameters.
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 schema only defines url and html as optional strings with no descriptions. The description adds meaning: 'Pass a url to fetch and audit the served HTML, or pass html directly.' This explains the semantics of each parameter and their mutual exclusivity (implied by 'or'). It doesn't cover edge cases like providing both or none, but for two simple parameters this is adequate.
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 audits a 'shipped web surface' across six specific axes with the MISSING conformance auditor. The verb 'audit' and resource are precise, and the listed axes distinguish it from narrower siblings like audit_findability or audit_delivery.
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?
It explicitly explains how to invoke the tool: pass a url to fetch and audit, or pass html directly. This gives clear input guidance. However, it doesn't explicitly contrast with sibling tools (e.g., when to use this general audit vs audit_findability), though the scope (all six axes) implies broader use.
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, the description carries the full burden. It discloses key behaviors: reserving dimensions, setting loading=lazy for offscreen images, using eager+high fetchpriority for LCP, and generating <picture> when avif/webp are provided. It does not mention handling of srcset or sizes, but the core behavior is clearly articulated.
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 sentences, front-loaded with the core purpose and followed by specific behavioral notes. Every sentence contributes value, with no filler or redundancy.
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 nested object schema and no output schema, the description covers the main purpose, behavioral details, and key parameters. It doesn't elaborate on srcset/sizes behavior or output format, but as a markup generator, the output is implicitly the HTML string. The description is adequate for a capable agent, though leaving a few details to standard HTML knowledge.
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?
Schema description coverage is 0%, so the description must add meaning. It explains the role of avif/webp (trigger <picture>), priority (LCP eager), lazy (offscreen), and dimensions (reserved). While srcset, sizes, and alt are not explicitly explained, their names are self-explanatory in web context, and the description covers the most critical parameters.
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 generates responsive <img> or <picture> markup, with a specific verb (Generate) and resource (markup). It clearly distinguishes from sibling tools like audit_surface or generate_sitemap by focusing on image markup generation and optimization.
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 provides clear usage context: it instructs to mark LCP images with priority and offscreen images as lazy, and explains that passing avif/webp yields <picture>. While it doesn't explicitly exclude alternatives, there is no overlapping sibling tool, and these instructions give actionable when-to-use guidance.
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:

[![ds4ai-mcp MCP server](https://glama.ai/mcp/servers/Polymathie-Studio/ds4ai-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Polymathie-Studio/ds4ai-mcp)

Score Badge

Copy to your README.md:

[![ds4ai-mcp MCP server](https://glama.ai/mcp/servers/Polymathie-Studio/ds4ai-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Polymathie-Studio/ds4ai-mcp)

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/Polymathie-Studio/ds4ai-mcp'

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