WrapGuard MCP is a browser-driven auditing and fixing server for Korean/English mid-word wrapping issues in responsive pages.
Audit pages at multiple viewport widths (320, 375, 768, 1024 px by default) to detect Korean/English words split across visual lines.
Detect mid-word breaks using measured grapheme geometry in Chromium, including hard source newlines embedded inside words.
Inspect wrapping CSS for one element, showing computed properties and same-origin matching rules.
Suggest safe CSS fixes based on content type: prose, raw evidence, or code/URL content.
Verify wrap regressions against explicit error/warning thresholds for CI or release gates.
Apply explicit CSS fixes idempotently, with dry-run by default and real writes only when explicitly enabled and rooted.
Get server information such as display name, safety policy, and supported languages.
Supports local files, file URLs, and allowlisted HTTP(S) URLs with configurable ignore selectors and locale (auto/ko/en).
Inspects applied CSS wrapping rules, generates minimal CSS fixes for mid-word line breaks, and appends idempotent CSS rules to stylesheet files.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@wrapguard-mcp Audit https://example.com for mid-word line breaks and suggest CSS fixes."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
WrapGuard is an MCP server and CLI that renders responsive pages with Playwright and finds Korean or English words split across visual lines. It also reports hard newlines embedded inside words, such as 업로↵드, without rewriting immutable source evidence.
한글·영어 문장이 반응형 화면에서 단어 중간에 잘리는 문제를 실제 브라우저 좌표로 검사합니다. 표시 이름은 자유롭게 바꿀 수 있지만 npm/GitHub/MCP Registry의 패키지 식별자는 별도로 유지됩니다.
Korean eojeol-like tokens and English word tokens, including apostrophes and hyphens
Actual grapheme positions across 320, 375, 768, and 1024 px by default
Avoidable mid-word wraps versus unavoidable long identifiers
Hard source newlines between letters
Applied wrapping CSS and same-origin matching rules
Explicit, dry-run-first CSS suggestions
URLs, code, hashes, and immutable raw evidence can be excluded with patterns or data-wrapguard-ignore. Public fixtures contain no private data.
Related MCP server: Fast Playwright MCP
Requirements: Node.js 22 or newer and a Playwright Chromium installation.
npm install
npx playwright install chromium
npm run build
node dist/stdio.jsWith browserChannel: "auto" (the default), WrapGuard tries Playwright Chromium first and then an installed Chrome or Microsoft Edge. Installing Playwright Chromium is the reproducible choice for CI.
After an npm release, an MCP client can launch it directly:
{
"mcpServers": {
"wrapguard": {
"command": "npx",
"args": ["-y", "wrapguard-mcp"],
"env": {
"WRAPGUARD_SERVER_NAME": "My Typography Inspector",
"WRAPGUARD_CONFIG": "C:/absolute/path/wrapguard.config.json"
}
}
}
}On Windows, clients that do not resolve command shims may need npx.cmd instead of npx.
Run it as a release gate without MCP:
wrapguard audit ./dist/index.html --viewports 320,375,768,1024 --output wrap-report.json
wrapguard audit ./dist/index.html --format markdown --output wrap-report.mdExit code 0 means no avoidable split, 1 means regression issues were found, and 2 means the audit could not run.
Copy wrapguard.config.example.json to wrapguard.config.json, then edit:
{
"serverName": "우리집 문장 검사기"
}WRAPGUARD_SERVER_NAME overrides the JSON value. This changes the runtime MCP display name only. Before the first public release, change name, mcpName, repository URLs, and server.json together if you want a different permanent package identity.
server_info
audit_page
detect_midword_breaks
inspect_wrap_css
suggest_wrap_fix
verify_wrap_regression
apply_wrap_fix — dry-run by default; real writes require allowWrites: true and an allowed root
The default configuration audits local files under the configured roots and localhost only. Remote URL auditing, screenshots, and CSS writes are disabled unless explicitly enabled. A hosted instance should use a narrow allowedHosts list because unrestricted browser navigation creates an SSRF risk.
GitHub publishes source, issues, documentation, and releases. It does not by itself run an MCP endpoint.
npm publishes the stdio executable so users can run npx -y wrapguard-mcp.
Remote MCP hosts /mcp over Streamable HTTP for clients that do not run local processes.
After reviewing the repository name and public contents:
git init
git add .
git commit -m "feat: release WrapGuard MCP 0.1.1"
gh repo create wrapguard-mcp --public --source . --remote origin --push
npm login
npm publish --access publicThen validate and publish server.json with the official mcp-publisher. The npm package must be published first and the mcpName in package.json must match server.json.
The included container starts the Streamable HTTP server at /mcp:
docker build -t wrapguard-mcp:0.1.1 .
docker run --rm -p 8787:8787 \
-e WRAPGUARD_HTTP_TOKEN="replace-with-a-long-random-value" \
-e WRAPGUARD_HTTP_HOSTS="localhost,127.0.0.1" \
wrapguard-mcp:0.1.1For a public host, set WRAPGUARD_HTTP_HOSTS to the deployed domain and store WRAPGUARD_HTTP_TOKEN as a platform secret. Use a container service that supports Playwright/Chromium, such as Cloud Run, Fly.io, Render, Railway, or an equivalent service. Add the final HTTPS URL to the remotes field in server.json only after the endpoint exists.
Vercel Functions are not the default recommendation for this project because browser binaries, execution duration, and memory limits make browser audits less predictable than a long-running container.
npm run check
npm test
npm run build
npm pack --dry-runThe test suite uses synthetic Korean and English pages and an in-memory MCP client/server connection.
MIT
Append an idempotent CSS rule. Dry-run is the default; real writes require allowWrites and an allowed root.
| Name | Required | Description | Default |
|---|---|---|---|
| dryRun | No | ||
| cssFile | Yes | ||
| profile | Yes | ||
| selector | Yes |
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.
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.
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.
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.
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.
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.
Render a page at multiple widths and report Korean/English mid-word wraps and forced source newlines.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | ||
| target | Yes | Allowed local HTML path, file URL, or allowlisted HTTP(S) URL | |
| viewports | No | ||
| screenshotDir | No | ||
| ignoreSelectors | No |
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.
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.
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.
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.
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.
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.
Return only concrete Korean/English wrap issues measured from grapheme geometry in the browser.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | ||
| target | Yes | Allowed local HTML path, file URL, or allowlisted HTTP(S) URL | |
| viewports | No | ||
| screenshotDir | No | ||
| ignoreSelectors | No |
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.
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.
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.
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.
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.
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.
Inspect computed wrapping properties and same-origin matching CSS rules for one element.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | ||
| selector | Yes | ||
| viewport | No |
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.
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.
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.
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.
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.
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.
Show the configured display name, safety policy, and supported languages.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
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.
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.
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.
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.
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.
Generate a minimal CSS rule for Korean, English, mixed prose, raw evidence, or code/URL content.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | auto | |
| selector | Yes | ||
| contentKind | No | prose |
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.
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.
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.
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.
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.
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.
Audit a page and evaluate it against explicit error/warning thresholds for CI or release gates.
| Name | Required | Description | Default |
|---|---|---|---|
| locale | No | ||
| target | Yes | Allowed local HTML path, file URL, or allowlisted HTTP(S) URL | |
| maxErrors | No | ||
| viewports | No | ||
| maxWarnings | No | ||
| screenshotDir | No | ||
| ignoreSelectors | No |
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Validate HTML/CSS, audit SEO and JSON-LD, check links, and capture responsive screenshots.
Scan a web page for accessibility, security, privacy, quality and SEO issues, with fixes.
Playwright selector risk checks with healing suggestions and receipts.
Screenshot any URL/HTML as PNG/JPEG/WebP, or read it as clean Markdown/text for LLMs.
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
