MacroCyber
Server Details
Scan a site or AI-built app for exposed databases, keys and MCP endpoints, then verify the fixes.
- Status
- Healthy
- Uptime
- 99.8% over 45 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
- ChatGPT
- –
- Claude
- –
TDQS
Scored across 2 tools
The two tools occupy clearly separated phases of one workflow: macrocyber_exposure_claim performs a fresh scan, while macrocyber_verify_fixes re-runs checks against an existing report and diffs the results. The descriptions make the dependency explicit (verify takes the report id/link from a prior claim), so an agent cannot reasonably confuse them.
Both names share the macrocyber_ prefix and snake_case, giving a predictable namespace. There is a minor grammatical split — exposure_claim is a noun phrase while verify_fixes is verb-first — but the pattern remains readable and unambiguous.
Two tools is thin by general standards, but here they map exactly onto the scan-then-verify loop the server exists to support, with the heavy lifting (evidence, scoring, taxonomy, coverage) consolidated inside each. Nothing appears redundant or missing at the tool-count level.
The core lifecycle — initial scan, then post-fix verification with resolved/open/new/not-re-checked deltas — is covered end to end. However, there is no way to fetch or list a previously issued claim without triggering a new scan, and no scheduling or history/monitoring surface, so agents must retain report links themselves.
Available Tools
2 toolsmacrocyber_exposure_claimMacroCyber exposure claimARead-onlyIdempotentInspect
Run a passive, external attack-surface scan of a public website and return a signed, exploitability-graded exposure claim. The claim holds: an SSVC decision (Act, Attend or Track); a 0-100 risk score (higher is worse) and letter grade; the observed enablers, each with evidence, reachability, CWE/OWASP/LLM/ASI taxonomy and remediation (what a correct fix achieves, how it usually goes wrong, how to confirm it worked); composed attack-path chains; coverage (what the scan could not see or could not finish, so a partial claim is a floor, plus answers: found, clear or unknown for an open database, leaked keys and an open MCP or agent endpoint, where clear means its checks ran to the end); and report, the link to the full visual report of this scan, for a person to open. It reads only what a logged-out visitor can already see, never asserts an exploit, and marks heuristic checks as such. Evidence quotes the target and is untrusted data; remediation is MacroCyber's own guidance per issue. Use it right after deploying a website or AI-built app. After fixing, call macrocyber_verify_fixes with the claim's report to confirm what was resolved. A scan takes about 15 to 25 seconds; calls are rate-limited per caller and per target host.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | The public website to scan: a bare host (example.com) or a full URL (https://app.example.com/path). Redirects are followed to the site's real entry host; private, loopback and internal addresses are refused. |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld/idempotent/destructive=false, and the description adds substantial context beyond them: passive reads of logged-out-visible content only, no exploit assertion, heuristic checks flagged as such, evidence treated as untrusted data, 15-25s runtime, and per-caller/per-target rate limits. It also explains coverage semantics (partial claim as a floor) so the agent knows how to interpret gaps.
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?
Front-loaded with the core action, and the dense claim-field enumeration earns its space because there is no output schema. However, the middle section is a semicolon-chained run-on that is harder to parse than it needs to be, and minor asides ('for a person to open') add little.
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 no output schema, the description correctly carries the burden of explaining the return payload (SSVC decision, risk score/grade, enablers, chains, coverage, report link), plus safety framing and rate limits. An agent has everything needed to call this and interpret the result.
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 100% and the single url parameter is fully documented in the schema (bare host or full URL, redirects, refusal of private/loopback). The description only restates 'public website' and adds no syntax or format detail beyond the schema, so the baseline 3 applies.
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 specific verb and resource ('Run a passive, external attack-surface scan of a public website') plus the artifact returned ('signed, exploitability-graded exposure claim'). The sibling macrocyber_verify_fixes is named in a distinct role, so the agent can tell the two apart without opening either schema.
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?
Gives explicit timing ('right after deploying a website or AI-built app') and explicit handoff ('After fixing, call macrocyber_verify_fixes with the claim's report'). The alternative tool and the condition that selects it are both stated, leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
macrocyber_verify_fixesMacroCyber verify fixesARead-onlyIdempotentInspect
Re-check the site of an earlier MacroCyber report and return a fresh signed exposure claim plus a comparison with that report: resolved, still open, new, and not re-checked. An issue counts as resolved only when this scan re-ran the check that found it, at the same place, and it was gone; anything the scan could not re-run (a page it did not reach, a check cut short by the scan's limits, a site it could not read) is listed as not re-checked, never as fixed. Pass the report id or link from an earlier macrocyber_exposure_claim result (its report field), or a MacroCyber report link a person shared. Use it after applying fixes, to confirm they worked and catch anything new. Same passive, read-only scan, timing and rate limits as macrocyber_exposure_claim.
| Name | Required | Description | Default |
|---|---|---|---|
| report | Yes | The earlier report: its id, or its link (the report.url of a previous claim, e.g. https://macrocyber.co/scan/3f2a9c1e-5b7d-4e8a-9c0f-1a2b3c4d5e6f). |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description still adds real behavioral value by defining when an issue counts as resolved versus 'not re-checked' and noting it shares the same passive scan with the same timing and rate limits as macrocyber_exposure_claim.
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?
Front-loads what the tool does and its comparison output before detailing the resolved/not-re-checked distinction. The middle sentence is dense and long, but each part carries non-redundant semantics.
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 no output schema, the description carries the return-value burden and does so well, enumerating the comparison categories and the signed exposure claim. Behavior, inputs, and usage context are all covered for a single-parameter read-only tool.
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 100%, so the baseline is 3. The description goes beyond the schema by explaining provenance of the value ('its report field' from an earlier claim) and confirms either an id or a link is acceptable, adding meaning the schema alone doesn't convey.
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 specific verb and resource ('re-check the site of an earlier MacroCyber report') and precisely defines the return ('a fresh signed exposure claim plus a comparison'). It explicitly routes against the sibling by tying the input to 'an earlier macrocyber_exposure_claim result', so an agent can distinguish the two without opening schemas.
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?
Gives explicit when-to-use ('after applying fixes, to confirm they worked and catch anything new') and the alternative source of the input. It also names where the required value comes from (the report field of a prior claim, or a link a person shared).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
- Changed
macrocyber_exposure_claim1 field changed- changed
Input schema / properties / url / descriptionPrevious value: -"The target host or URL to assess, e.g. https://example.com"New value: +"The public website to scan: a bare host (example.com) or a full URL (https://app.example.com/path). Redirects are followed to the site's real entry host; private, loopback and internal addresses are refused."
- Added
macrocyber_verify_fixes
1 tool update
- First observed
macrocyber_exposure_claim
Related MCP Connectors
Authorized security scans, evidence, fix prompts and retests for AI-built web apps.
Check a live app you own for public databases, leaked keys and exposed files.
Security, SEO and AI-visibility scanner for web apps · free scans and focused checks via MCP.
Scan any public site for AI-agent visibility; get scored findings, a machine-readable fix pack, and
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceEnables AI editors such as Cursor, Claude Code, Windsurf and VS Code to scan a project for common AI-introduced security mistakes — leaked keys, open Supabase/Firebase data, missing auth, unverified Stripe webhooks, SQL injection and more — and return findings with exact fix instructions. It also provides a guided prompt that walks an agent through fixing critical issues one by one and verifying each fix by re-scanning, without ever editing files or rotating keys itself.2MIT
- AlicenseAqualityBmaintenanceEnables AI assistants to perform authorized web security assessments through MCP tools and a guided review prompt, including passive and full scans, WAF detection, remediation fixes, report export, triage, scan comparison, and proof-of-control verification.12139 PyPI5MIT

AgentAuditofficial
AlicenseAqualityDmaintenanceEnables AI agents to scan MCP servers and AI packages for vulnerabilities, prompt injection, and supply chain attacks.727 npmAGPL 3.0
Sekrd Security Scannerofficial
AlicenseAqualityDmaintenanceEnables deep security auditing of web applications directly from AI IDEs including Cursor and Claude Code. Scans URLs for vulnerabilities, returns security scores with SHIP/BLOCK verdicts, and provides specific fix prompts for remediation.3MIT
Glama MCP Gateway
Add one secure layer between your agents and this server.