offsec-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most 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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.9/5 across 10 of 10 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- No stable releases found
- 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

Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
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 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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

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:

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

Score Badge

Copy to your README.md:

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

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