Skip to main content
Glama
HalidSaglam

saglitzdesign-mcp

by HalidSaglam

Audit Security

audit_security
Read-onlyIdempotent

Scan frontend source code to identify shipped security defects—missing CSP and HSTS, exposed secrets, unsafe scripts—with actionable findings and severity ratings.

Instructions

Audit a web project or snippet for security defects a frontend actually ships: missing or weak Content-Security-Policy, absent HSTS, unpinned cross-origin scripts, mixed content, credentials in localStorage, secret-named NEXT_PUBLIC_/VITE_ variables, unsandboxed third-party iframes, wildcard postMessage, raw-HTML sinks with no sanitiser, production source maps and un-ignored .env files. Header state is inferred from wherever your stack declares it — next.config, vercel.json, netlify.toml, _headers, staticwebapp.config.json, firebase.json, Nuxt routeRules, a Remix/React Router headers export, SvelteKit hooks.server.ts and kit.csp, Astro middleware and Next.js middleware or its Next 16 rename proxy.ts, new Response(body, { headers }) and new Headers({…}) on Cloudflare Workers/Deno/Bun — and, as rules rather than places, a quoted header-name property in any JSON or object literal, and any call whose method name is set, setHeader, append or header whatever the object is called (res.set, res.setHeader, headers.set, headers.append, Fastify reply.header, Hono c.header, Koa ctx.set) — and , read as text and never evaluated. It reads source and does not measure anything: it makes no request to your site, tests no live endpoint, and no finding is or can be a penetration-test or vulnerability-scan result — so do not call it expecting one. Returns markdown plus structured output: findings (rule, severity, message, fix, doc, file, line), a severity summary, and a machine-readable notVisible list of what it could not check. A missing or non-directory path is returned as an error result, not as an empty audit. Pair with audit_project for design drift and audit_accessibility for WCAG.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
codeNoA single snippet to audit instead of a directory. Source rules only.
pathNoDirectory to audit. Absolute paths are strongly preferred. Required for configuration and header rules — a snippet cannot show them.
filenameNoFilename for the snippet, e.g. 'page.html' or 'Page.tsx'. Some rules depend on it: an inline onclick is a defect in HTML and normal JSX in a .tsx file.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
summaryYesCounts by severity. Always agrees with `findings` — it is derived from the same list.
findingsYesEvery finding, in the order the markdown report lists them.
notVisibleYesWhat this audit structurally could not check, one limitation per entry. Read it as a peer of `findings`: silence on a subject named here is this tool's reach, not a clean result. Nothing any of these tools reports is measured.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Addedv0.28.0

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint and idempotentHint annotations, the description discloses static-only behavior, no network evaluation, header parsing as text rather than execution, error handling for missing or non-directory paths, and the structured output shape including the `notVisible` list. This is exactly the behavioral context an agent needs beyond structured metadata. No contradiction with annotations exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening sentence front-loads purpose effectively, and the long enumerations of security rules and config-file locations are dense with actionable detail rather than fluff. However, the description is quite long and could be more scannable with structured lists, so it earns four rather than five.

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 tool with this complexity, the description is remarkably complete: it covers input modes, detection scope, framework inference, limitations, return format, error behavior, and related sibling tools. The output schema already handles return-value documentation, so the description does not need to repeat that. Nothing essential for correct selection or invocation appears to be missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although schema coverage is 100%, the description adds genuinely new meaning: `path` is required for configuration and header rules while `code` is source-rules-only, absolute paths are strongly preferred, and `filename` affects rule interpretation by extension. This helps an agent select and fill parameters correctly in a way the schema alone does not.

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 opens with a precise verb-object pairing: 'Audit a web project or snippet for security defects a frontend actually ships.' It enumerates concrete defect categories, making the tool's scope unmistakable. It also distinguishes itself from siblings by explicitly pairing with audit_project and audit_accessibility for other concerns.

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?

The description gives clear when-to-use context by scoping to source-based frontend security checks and explicitly stating what it cannot do: 'it makes no request to your site, tests no live endpoint, and no finding is or can be a penetration-test or vulnerability-scan result — so do not call it expecting one.' It also names companion tools for adjacent use cases, helping an agent route correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Latest Blog Posts

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/HalidSaglam/saglitzdesign-mcp'

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