wrapguard-mcp

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation4/5
Most tools target distinct actions: detect, audit, inspect, suggest, apply, verify. The only real overlap is between detect_midword_breaks and audit_page, since both report wrap issues, but audit_page's multi-width rendering and forced-newline reporting help separate them.
Naming Consistency4/5
Tool names mostly follow a clear verb_noun pattern like detect_, audit_, inspect_, suggest_, apply_, and verify_. The single deviation is server_info, which uses a noun phrase instead of a verb-based name, but the overall convention is consistent.
Tool Count5/5
Seven tools is well-scoped for a focused Korean/English wrapping server. Each tool contributes to a clear workflow without excessive redundancy or an undersized surface.
Completeness4/5
The set covers the full lifecycle: audit/detect issues, inspect CSS, suggest fixes, apply fixes, and verify regressions. The main minor gap is the lack of an explicit undo/remove operation for applied wrap fixes.
Average 3.4/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 4 commits in the last 12 weeks
- Last stable release on September 2, 2026
- 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?
Annotations already indicate a read-only, closed-world operation. The description adds useful context by specifying that only same-origin matching CSS rules are inspected, which is a meaningful scope limitation. However, it does not describe output format, error behavior, or any other runtime traits.
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, front-loaded sentence with no filler. Every phrase contributes meaning: 'computed wrapping properties,' 'same-origin matching CSS rules,' and 'for one element' are all substantive.
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?
Without an output schema, the description should clarify what the inspection returns, but it only names the general result categories. It also fails to explain the viewport parameter, which is likely important for wrapping behavior, and leaves parameter semantics unresolved.
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%, so the description must compensate, but it only hints at 'one element' without explaining target, selector, or viewport. The role of viewport in wrapping behavior is especially unclear, and target/selector semantics are left to inference.
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 specific action ('Inspect') and a specific resource ('computed wrapping properties and same-origin matching CSS rules') scoped to 'one element.' It is clear and distinguishes the tool from fix/suggest/apply siblings, but it does not explicitly differentiate from the closely related detect_midword_breaks.
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 explains what the tool does but gives no guidance on when to choose it over alternatives, no prerequisites, and no exclusions. Sibling tools like detect_midword_breaks or audit_page are not mentioned, so an agent must infer usage purely from the verb 'Inspect.'
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 readOnlyHint annotation already establishes that this is a safe read operation, and the description adds useful behavioral detail about multi-width rendering and the specific report categories. However, it does not disclose the effect of screenshotDir (which may imply saving screenshots), the output format, or any constraints or prerequisites, leaving some behavioral ambiguity.
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 with no fluff. The core action and output are front-loaded, and every word contributes meaning.
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?
For a tool with five parameters, no output schema, and several closely related sibling tools, this description is too thin. It omits parameter semantics, return value expectations, and any guidance for choosing this tool versus its siblings, so an agent is left to infer important operational details.
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 only 20%, and the description does little to compensate. It hints at 'multiple widths' and a page target, but does not explain the meaning or interaction of locale, viewports, screenshotDir, or ignoreSelectors beyond what the bare schema already exposes.
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 specific action ('Render a page at multiple widths') and the exact findings it reports ('Korean/English mid-word wraps and forced source newlines'), making the tool's function easy to identify. However, it does not explicitly differentiate itself from sibling tools like detect_midword_breaks or verify_wrap_regression, so it stops 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a sensible use case—responsive wrapping audits across viewport widths—but gives no explicit guidance on when to choose this tool over detect_midword_breaks, inspect_wrap_css, or verify_wrap_regression. No exclusions or alternative routing 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?
Annotations already declare readOnlyHint=true, so the read-only safety is covered. The description adds useful context that results are limited to concrete issues measured from grapheme geometry, implying empirical detection rather than heuristics, but it does not discuss output shape, browser interaction details, or potential coverage caveats.
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 front-loaded sentence with no filler. Every phrase earns its place: 'Return only', 'Korean/English wrap issues', 'grapheme geometry', and 'in the browser' all add meaningful scoping.
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?
For a tool with 5 parameters and no output schema, the description is too thin. It omits what the returned issues look like, how viewports affect detection, what ignoreSelectors excludes, and when a caller should pick this tool over the sibling tools.
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 only 20%, with only target documented in the schema. The description does not compensate by explaining locale behavior, viewports semantics, ignoreSelectors, or screenshotDir. It only vaguely connects 'Korean/English' to the locale 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 states a specific verb ('Return') and resource ('concrete Korean/English wrap issues measured from grapheme geometry in the browser'). It clearly differentiates detection of empirically measured wrap issues from sibling tools like suggest_wrap_fix or apply_wrap_fix.
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 gives no explicit guidance on when to use this tool versus siblings such as suggest_wrap_fix, inspect_wrap_css, or verify_wrap_regression. The word 'only' hints at a detection/verification role, but this is left to inference rather than 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?
The description discloses that the tool generates a minimal CSS rule rather than mutating anything, which aligns with readOnlyHint=true. It adds the 'minimal' qualifier, but does not elaborate on what 'safe' means, whether the returned rule is guaranteed valid, or any constraints on the selector. No contradiction with 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?
One sentence, front-loaded with the action and object, with no filler or repeated annotation information. The list of content types is compact and the description earns its place.
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 generation tool this description covers the core output, but it omits selector semantics, the meaning of 'safe', and how this tool relates to the apply/inspect siblings. Since there is no output schema, a bit more guidance would materially improve call correctness.
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 coverage is 0%, so the description had to compensate, but it only paraphrases the values already present in the locale and contentKind enums. The required selector parameter is not described or even hinted at, leaving its purpose and format to inference.
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?
States a clear verb ('Generate') and resource ('a minimal CSS rule') and enumerates the content types it covers, so an agent can tell what the tool produces. It does not explicitly differentiate from siblings such as apply_wrap_fix or inspect_wrap_css, though the title 'Suggest' hints at the distinction.
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 content-type list ('Korean, English, mixed prose, raw evidence, or code/URL') gives a sense of when the fix applies. There are no when-not-to-use instructions or references to alternatives, so the agent must infer when to prefer this over apply_wrap_fix or verify_wrap_regression.
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?
The description adds behavioral context beyond the annotations by disclosing the dry-run default and the permission requirement for real writes. It also reinforces idempotency, which is already in the annotations. There is no contradiction with 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no filler. The first sentence states the core action; the second presents the critical default and guardrail. Information is front-loaded and easy to parse.
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?
With four parameters, no output schema, and zero schema descriptions, the description is too sparse. It does not explain what the generated CSS rule looks like, how selector and profile interact, what a successful operation returns, or how this tool fits into the wrap-fix workflow. An agent would need external information to call it confidently.
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 description only implicitly references dryRun via 'Dry-run is the default.' It does not explain the purpose or role of cssFile, selector, or profile, leaving the agent to infer how these parameters affect the appended CSS rule. The enum values for profile are not contextualized.
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 and resource: 'Append an idempotent CSS rule.' This differentiates the tool from obvious siblings like suggest_wrap_fix or inspect_wrap_css at a surface level by describing the action. However, it does not explicitly name a sibling or elaborate on what a 'wrap fix' is, so the distinction is not fully reinforced.
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 provides useful context: dry-run is the default and real writes require allowWrites and an allowed root. This tells an agent when actual file modification can occur. But it does not say when to use this tool versus suggest_wrap_fix or verify_wrap_regression, and the mentioned allowWrites/root are not parameters in the schema, which could confuse.
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 readOnlyHint and openWorldHint annotations already cover the safety profile, so the bar is lower. The description adds that thresholds are involved, but it does not explain pass/fail behavior, exit semantics, or how error/warning counts are evaluated across viewports.
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. It communicates the purpose and intended usage context economically.
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?
For a tool with seven parameters, no output schema, and several sibling tools, this high-level description is under-specified. It omits what the output/result looks like, how thresholds are applied, and how this relates to audit_page or detect_midword_breaks.
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 only 14%, so the description should compensate for seven parameters, but it only hints at error/warning thresholds. It leaves locale, viewports, screenshotDir, ignoreSelectors, and the target constraints mostly unexplained.
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 action and resource: audit a page and evaluate it against explicit error/warning thresholds for CI or release gates. This distinguishes it from generic audit_page by emphasizing threshold-based regression checking, though it relies on the title for the wrap-specific focus.
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 'for CI or release gates' gives clear usage context. It does not explicitly name sibling alternatives or say when not to use this tool, so it falls short of a 5.
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 readOnlyHint annotation already declares the read-only safety profile, and the description's 'Show' wording is consistent with that. The description adds some value by enumerating the specific configuration fields exposed, but it does not disclose any other behavioral details such as authentication requirements or response characteristics.
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 that immediately states the tool's purpose and enumerates the returned information without any filler. It is optimally concise for a no-parameter read-only information tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, zero-parameter, read-only info tool, the description sufficiently covers what the agent needs to know: the tool's purpose and the specific configuration values it returns. There is no output schema, but the description explicitly lists the main return fields, making the tool's behavior predictable.
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 tool has zero parameters, so parameter semantics are not a burden on the description. The input schema is fully self-explanatory with no properties, and the description correctly focuses on what the tool returns rather than on nonexistent inputs.
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 a specific verb ('Show') and names the resource plus the exact fields returned (display name, safety policy, supported languages), distinguishing it from the operation-focused sibling tools. Even with no parameters, an agent immediately knows what server_info is for.
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 that an agent should call this tool when it needs server-level configuration such as display name, safety policy, or supported languages. However, it gives no explicit guidance about when not to use it or which sibling might be a better alternative for related needs.
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:

[![wrapguard-mcp MCP server](https://glama.ai/mcp/servers/Yuni9959/wrapguard-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Yuni9959/wrapguard-mcp)

Score Badge

Copy to your README.md:

[![wrapguard-mcp MCP server](https://glama.ai/mcp/servers/Yuni9959/wrapguard-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Yuni9959/wrapguard-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/Yuni9959/wrapguard-mcp'

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