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., "@offsec-mcp Find subdomains of example.com and check the main site's security headers."
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.
Offensive-security tooling for AI agents — over the Model Context Protocol.
Give Claude, Cursor, or any MCP client the ability to run reconnaissance, pull CVE intelligence, analyze JavaScript, and scan ports — only against targets you're authorized to test.
Pentesters and bug-bounty hunters live in a dozen CLI tools. AI agents are great at orchestrating multi-step work — but they can't touch those tools. offsec-mcp bridges the gap: it exposes a focused set of security capabilities as MCP tools, so you can just ask —
"Enumerate subdomains of
example.com, check which are live, and tell me if any run software with a critical CVE."
— and the agent chains recon_subdomains → http_probe → cve_search for you.
Built on battle-tested logic from reconwave, cve-forge, and jsintel.
Related MCP server: wrg-mcp-server
This is a dual-use tool, so authorization is enforced in code, not left to good intentions:
Passive OSINT (CT logs, DNS, RDAP, NVD, analyzing pasted JS) runs freely — it never touches the target.
Active tools (port_scan, http_probe, security_headers) refuse to run unless the
target is in your configured authorization scope. No scope → no active probing.
Discovered secrets are redacted in output, never returned in full.
See SECURITY.md for the responsible-use policy.
Tool | Type | What it does |
| passive | Sub-domain enumeration from Certificate Transparency (crt.sh) |
| passive | A/AAAA/MX/NS/TXT/CNAME via DNS-over-HTTPS |
| passive | Registration data via RDAP (registrar, dates, nameservers) |
| passive | Search NVD by keyword, filter by CVSS |
| passive | Full details + references for a CVE id |
| passive* | Extract secrets, endpoints & params from JS |
| active | Status, headers & tech fingerprint of a URL |
| active | Audit security headers, grade A–F |
| active | Async TCP-connect scan of common/custom ports |
| — | Report whether an authorization scope is set |
* analyze_js is passive on pasted content; fetching a URL requires scope.
Run instantly with uv — no clone needed:
uvx offsec-mcp # runs the server (stdio) — or: pip install offsec-mcpOr install from source:
git clone https://github.com/nadirzhon/offsec-mcp
cd offsec-mcp
uv pip install -e ".[dev]"Add to your MCP config (see examples/claude_desktop_config.json):
{
"mcpServers": {
"offsec": {
"command": "uvx",
"args": ["offsec-mcp"],
"env": {
"OFFSEC_SCOPE": "example.com,*.staging.example.com,10.0.0.0/24"
}
}
}
}Active tools only run against hosts you list. Two ways to set it:
# inline — domains, wildcards, and CIDRs
export OFFSEC_SCOPE="example.com,*.staging.example.com,10.0.0.0/24"
# or a file, one entry per line (# comments allowed)
export OFFSEC_SCOPE_FILE="./scope.txt"For a fully-owned lab you control, OFFSEC_ALLOW_ANY=1 disables the guard. NVD_API_KEY
(optional) raises NVD rate limits.
You: Find subdomains of example.com and check the main site's security headers.
Agent: → recon_subdomains("example.com") → 143 subdomains from CT logs
→ security_headers("https://example.com")
→ Grade C (60): missing CSP, Permissions-Policy.
www, api, staging, dev.example.com are live.See examples/sample_output.md for real tool output.
uv pip install -e ".[dev]"
pytest # scope guard + tool logic
ruff check .offsec-mcp — MCP server giving AI agents offensive-security tools (recon, CVE, JS analysis) · (this repo)
specter — autonomous AI recon agent that drives those tools end-to-end
vigil — AI security review for every pull request
mcpscan — security scanner for MCP servers (tool poisoning, injection surfaces)
State of MCP Security — research: 87% of scanned MCP servers expose a medium+ hardening issue
MIT — see LICENSE. Published for authorized security testing, research, and education only. You are responsible for having explicit permission to test any target.
Extract secrets, endpoints, and parameters from JavaScript (pasted content or a URL).
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the core function but does not disclose that fetching a URL likely makes a network request, any permission requirements, or rate limits. However, the tool appears to be read-only and non-destructive, so the lack of explicit safety disclaimers is a moderate gap.
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, well-structured sentence immediately states the tool's purpose and input flexibility. No fluff, no repetition, and all words contribute 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?
With one parameter, an output schema present, and a clear purpose, the description covers most needed context. It could mention behavior on invalid URLs or whether pasted content is required versus URL, but the overall completeness is good for a focused 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?
The schema only declares 'source' as a string with 0% schema description coverage. The description's mention of 'pasted content or a URL' meaningfully clarifies what the source parameter accepts, adding value beyond the schema. For a single parameter, this is sufficient.
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 the specific verb 'extract' and clearly states the resources (secrets, endpoints, parameters) and the input source (JavaScript pasted content or URL). It clearly distinguishes this from sibling tools which focus on subdomains, DNS, CVEs, etc.
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 implicitly conveys when to use this tool: when you have JavaScript content (pasted or via URL) and need to extract security-relevant data. It does not explicitly name alternative tools or exclusions, but the context is clear and distinct from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch full details and references for a specific CVE id (e.g. CVE-2024-3094).
| Name | Required | Description | Default |
|---|---|---|---|
| cve_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 only says 'Fetch full details and references', which indicates a read operation but does not disclose additional behavioral traits such as return format, potential errors, or any constraints. The description adds minimal context beyond the action.
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 well-structured sentence that front-loads the verb ('Fetch') and resource ('full details and references'), with an example. No wasteful words.
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?
The tool is simple with one parameter and an output schema. The description covers the purpose and the parameter adequately. However, it could be more complete by explicitly contrasting with cve_search, but given the low complexity, it is largely complete.
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 schema has 0% description coverage for the single parameter, but the description explicitly explains it as a 'specific CVE id' and provides an example (CVE-2024-3094). This gives the agent clear guidance on what to pass, and the parameter name is self-explanatory.
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 the tool 'Fetch full details and references for a specific CVE id', using a specific verb and resource. It distinguishes itself from sibling 'cve_search' by emphasizing a specific CVE id rather than searching, making the purpose unambiguous.
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 the tool is for looking up a known CVE ID, but it does not explicitly state when to use this tool over cve_search or provide any exclusions. Usage context is implied rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the NVD for recent CVEs by keyword, filtered by minimum CVSS score.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| keyword | Yes | ||
| min_cvss | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the search scope and filter but does not disclose how 'recent' is defined, default sorting, pagination, rate limits, or any other behavioral traits. The information provided is minimal and leaves key operational details undisclosed.
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, well-structured sentence that is front-loaded with the key action and resource. Every word adds value, and there is no unnecessary filler or repetition.
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?
Given the tool's moderate complexity (3 params, a sibling tool, no annotations), the description covers the core purpose but omits usage differentiation with cve_lookup and important behavioral details. Since an output schema exists, return value explanation is not required, but for a search tool, more context about how results are limited or ordered would improve completeness.
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 description explicitly mentions keyword and minimum CVSS score, which adds meaning to two of the three parameters. However, the 'limit' parameter is not described, and with 0% schema description coverage, the description should more thoroughly explain all parameters. It partially compensates but leaves gaps.
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 the tool searches the NVD for recent CVEs by keyword and filters by minimum CVSS score, with a specific verb ('Search') and resource ('NVD'). However, it does not explicitly differentiate from sibling tool cve_lookup, which may be used for retrieving a specific CVE by ID, so it misses some sibling differentiation.
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 the tool is for finding CVEs by keyword, but provides no explicit guidance on when to use it versus the sibling cve_lookup tool. It does not mention exclusions or prerequisites, relying on the user to infer usage from the wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve A/AAAA/MX/NS/TXT/CNAME records for a domain (via DNS-over-HTTPS).
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It adds the specific behavioral detail that queries go over DNS-over-HTTPS, and the list of supported record types clarifies the scope. However, it does not mention potential edge cases like NXDOMAIN responses or rate limits, though these are minor for a read-only DNS lookup.
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 that immediately states the action and scope. Every word adds value, including the parenthetical note about the transport method.
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 single-parameter tool with an output schema, the description is adequately comprehensive. It specifies the exact record types supported and the resolution method. The simple nature of the DNS lookup means no additional context about pagination or error handling is strictly necessary, though mentioning the absence of other record types could have added clarity.
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 schema only defines 'domain' as a required string with no description. The description adds meaning by stating the tool resolves records 'for a domain,' confirming the parameter is a domain name. However, it does not clarify expected formats (e.g., no protocol, no trailing dot) or examples, so the description only partially compensates for the 0% schema coverage.
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 the specific verb 'Resolve' and lists concrete record types (A/AAAA/MX/NS/TXT/CNAME), clearly distinguishing this DNS lookup tool from sibling tools like recon_subdomains and whois. The 'via DNS-over-HTTPS' detail further specifies the method, leaving no ambiguity about what the tool does.
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 clearly implies the tool is for DNS record lookup requests, and the explicit list of record types sets expectations. However, it does not explicitly state when to prefer this over alternatives or when not to use it, though no sibling tool overlaps with DNS record resolution directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a URL and report status, key headers, and detected technologies. [active — needs scope]
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It reveals that the tool actively fetches a URL and requires scope, but it does not disclose potential side effects, rate limits, or how redirects/errors are handled.
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 that conveys purpose, outputs, and operational context efficiently without superfluous detail.
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?
The tool has one parameter and an output schema, so the description's mention of reported status, headers, and technologies covers the output. The scope note adds operational context, though more detail on error behavior or required permissions would make it fully complete.
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?
With schema coverage at 0%, the description compensates by indicating the 'url' parameter is the target to fetch. Although minimal, it suffices given there is only one parameter and its role is self-evident from the tool name and description.
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 the tool fetches a URL and reports status, key headers, and detected technologies. This specific verb+resource combination distinguishes it from sibling tools like dns_lookup or port_scan.
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 its use for probing a URL, and the note '[active — needs scope]' provides a constraint. However, it does not explicitly state when to use this tool versus alternatives or provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
TCP-connect scan a host for open ports (defaults to common ports). [active — needs scope]
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | ||
| ports | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the active nature, the TCP-connect method, and the default behavior of scanning common ports. It also flags authorization needs via 'needs scope', which is valuable behavioral context beyond the schema.
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 followed by a brief scope note. Every word earns its place, with no redundancy or filler.
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 two-parameter tool, the description covers the essential behavior, default logic, and authorization requirement. An output schema exists, so the description need not enumerate return values. Minor gaps like listing the common ports are not critical.
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 schema provides no descriptions for 'host' or 'ports', and coverage is 0%. The description compensates by linking 'host' to 'a host' and explaining that 'ports' defaults to common ports when null. This adds meaningful semantics, though it does not detail array format or valid ranges.
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 the tool performs a TCP-connect scan on a host to identify open ports, which is a specific verb and resource. This distinguishes it from sibling tools like dns_lookup or http_probe, which have different purposes.
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 clear context by noting the scan is 'active — needs scope', indicating it requires authorization and is not passive. However, it does not explicitly mention alternatives or when not to use it, though the context implies it is for port enumeration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Passively enumerate sub-domains of a domain from Certificate Transparency logs.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It states the tool is 'passive' and uses Certificate Transparency logs, which implies a read-only, non-intrusive operation. However, it does not explicitly mention rate limits, authentication needs, or any side effects, leaving some ambiguity for a tool with no annotation coverage.
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, well-structured sentence that front-loads the action ('Passively enumerate') and provides the source ('Certificate Transparency logs') without any redundant or extraneous information.
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?
Given the simple one-parameter tool and the presence of an output schema, the description sufficiently covers the core purpose and source. It notes the passive nature and CT log source, but could enhance completeness by mentioning its relationship to active DNS enumeration tools or its coverage limits.
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 schema only defines a 'domain' string with no description. The description compensates by explaining that the tool enumerates sub-domains of 'a domain,' making it clear that the parameter is the target domain. This adds meaningful semantics beyond the raw schema.
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 the tool's function: 'Passively enumerate sub-domains of a domain from Certificate Transparency logs.' It uses a specific verb (enumerate) with a resource (sub-domains) and distinguishes itself from sibling tools like dns_lookup and port_scan by specifying the passive CT log source.
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 no explicit guidance on when to use this tool versus alternatives. It does not mention any exclusions or recommended use cases beyond its basic function, leaving the agent to infer the appropriate context from the passive nature and source.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report whether an authorization scope is configured for active tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden; it clearly states a reporting action, implying no side effects, but doesn't elaborate on edge cases or what 'configured' means.
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?
Single sentence, straightforward, no filler.
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?
Given the tool's simplicity, the description covers the core purpose; output schema provides return details; slight ambiguity about 'active tools' prevents a 5.
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?
With zero parameters, the description doesn't need to add anything; the schema already covers everything, so baseline 4 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?
The description uses a specific verb 'Report' and clearly identifies the resource ('authorization scope configured for active tools'), distinguishing it from sibling recon tools.
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?
No explicit usage guidance or alternatives mentioned, but the function itself implies it is a status check to be used before other tools; still, there is no statement about when to use vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Audit a site's HTTP security headers and grade them A–F. [active — needs scope]
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It discloses the audit action but omits key traits like whether it sends network requests, potential side effects, or authorization needs.
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 extremely concise—one sentence plus a short scope note—with no filler words. Every part 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?
An output schema exists, so return values are covered. However, the description lacks context on scope requirements, usage scenarios, and behavioral expectations, making it minimally viable but not comprehensive.
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 does not compensate. The single 'url' parameter is not elaborated; the description only implies a site to audit, leaving format and constraints unspecified.
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 specifies a clear verb ('Audit'), a resource ('a site's HTTP security headers'), and the expected output (grade A–F). This clearly distinguishes it from sibling reconnaissance tools like dns_lookup or port_scan.
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?
No guidance is provided on when to use this tool versus alternatives, prerequisites, or exclusions. The bracketed '[active — needs scope]' note hints at a scope requirement but does not clarify when or how to apply it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up domain registration data (registrar, dates, nameservers) via RDAP.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on the full burden. It discloses the underlying protocol (RDAP) and the type of data returned, which provides useful behavioral context beyond the tool name. It doesn't mention rate limits or error handling, but for a read-only lookup these are not critical omissions.
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 of about 12 words, front-loaded with the action and object. Every word adds value, with no repetition or filler.
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?
The tool is simple (one required parameter) and has an output schema, so return value details are covered. The description fully explains the tool's purpose and method. Minor gaps like TLD support or error cases are acceptable given the output schema and the tool's simplicity.
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 input schema has 0% description coverage, so the description must compensate. The only parameter is 'domain', and the description does not add any formatting, input constraints, or examples beyond what the parameter name already implies. It adds no semantic value to the schema.
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 the action ('Look up'), the resource ('domain registration data'), and specific data fields (registrar, dates, nameservers). It also identifies the method (via RDAP), which distinguishes it from sibling tools like dns_lookup or recon_subdomains.
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 clear context for when to use this tool (when domain registration data is needed) and the RDAP method implies a specific alternative to traditional whois. However, it does not explicitly name alternative tools or exclusions, so it stops 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0analyze_jscve_lookupcve_searchdns_lookuphttp_probeport_scanrecon_subdomainsscope_statussecurity_headerswhoisMost tools target distinct actions (recon, DNS, WHOIS, CVE search/lookup, JS analysis, HTTP probing, header auditing, port scanning), but http_probe and security_headers both fetch a URL and could be confused without careful reading. cve_search and cve_lookup are also similar in name but serve different purposes.
Tool names mostly follow a snake_case pattern with a clear verb_noun structure (recon_subdomains, cve_search, analyze_js, port_scan). A few names like whois and scope_status deviate from this, but the overall convention is consistent and readable.
Ten tools is well-scoped for an offensive security server. Each tool represents a distinct phase of recon or assessment, and none feel redundant or superfluous.
The set covers passive recon (subdomains, DNS, WHOIS), vulnerability research (CVE), and active assessment (HTTP, headers, ports, JS). Minor gaps exist like no explicit tool for web technology fingerprinting beyond http_probe, but the core workflow is well covered.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Security scanner for MCP servers. Detect vulnerabilities, prompt injection, and tool poisoning.
MCP server for Pentest-Tools.com: run scans, manage findings and reports via your preffered LLM.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/nadirzhon/offsec-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
