blackarch-AI MCP Server

by Pusparaj99op

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have clearly distinct purposes: scanning (nmap, nikto, gobuster), credential attacks (hydra), local auditing (audit_*, lint_*, review_*), and offline cracking (crack_hash_offline). However, check_scope is a utility tool that could be considered overlapping with the scope checks built into other tools, but it serves as a proactive check rather than a reactive refusal.
Naming Consistency3/5
The naming pattern mixes styles: verbs like 'check_', 'nmap_scan', 'gobuster_dir', and 'hydra_bruteforce' use a tool_name format, while others like 'audit_listening_ports' and 'review_auth_log' use verb_noun. The category for local auditing tools is consistent, but the overall set lacks a single unified pattern.
Tool Count4/5
12 tools is a reasonable count for a security auditing server covering reconnaissance, brute-forcing, local system auditing, and offline cracking. It's slightly high but each tool has a specific role, and no tool feels redundant. The scope is well-defined for a BlackArch-oriented toolset.
Completeness3/5
The toolset covers external scanning, web vulnerability scanning, brute-forcing, local host auditing, and password cracking. However, there are gaps: no network sniffing, exploitation, or privilege escalation tools, and no reporting or logging of results. For a comprehensive security assessment suite, these missing capabilities could hinder an agent's workflow.
Average 3.5/5 across 12 of 12 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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 provided, the description carries full burden for behavioral disclosure. It reveals that the tool checks scope before execution, but omits other important traits such as concurrency level, noise profile (e.g., requests per second), handling of large wordlists, or cancellation behavior. The description is too sparse to give an agent a clear model of the tool's runtime effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (two sentences), which is concise. However, it sacrifices necessary information for brevity; important details like parameter semantics and usage guidance are missing. Conciseness should not come at the cost of completeness for a tool with moderate complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 parameters (one required), no annotations, and no parameter descriptions in the schema, the description is incomplete. It does not explain parameter options, output format (despite an output schema existing), error handling, or integration with gobuster's features (e.g., threads, status codes). The scope refusal is the only extra detail beyond the bare purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the schema provides no parameter descriptions. The tool description mentions only 'url' in code formatting but does not clarify expected format (e.g., protocol, trailing slashes). The 'wordlist' and 'extensions' parameters have defaults in the schema but receive no explanatory text. The description adds virtually no semantic value over the bare parameter names.
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 directory brute-forcing on a URL using gobuster. This specific verb-resource combination ('directory-brute-force url') distinguishes it from sibling tools like nmap_scan, nikto_scan, or hydra_bruteforce, which perform different security scanning operations.
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 only mentions that the tool 'refuses if the host is not in scope.yaml', which is a refusal condition rather than proactive guidance on when to use it. It does not explain scenarios where this tool is preferred over nikto_scan or other web-focused tools, nor provide context on when enumeration is appropriate.
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 must fully disclose behavior. It states it summarizes entries since `since` but does not explain what 'summarize' means (e.g., counts by IP, failed vs. successful logins), whether it modifies logs, requires elevated privileges, or performance implications. The behavioral scope is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) but lacks structure. It front-loads the purpose but omits important details. It is not verbose, but the brevity comes at the cost of completeness. A slightly longer description with structured details would be more effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there are no annotations, an output schema exists which could describe the return format, but the description does not leverage this or explain return values. The tool has only one parameter but the description fails to describe its format or behavior comprehensively. The description is inadequate for an agent to use confidently without additional context.
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?
Schema description coverage is 0%, so description must compensate. It mentions the `since` parameter but only says 'since `since`' which is redundant. It adds little meaning beyond the default value '24 hours ago' already in the schema. No details on format (ISO 8601, relative?), so the description provides minimal added value.
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 summarizes sshd auth log entries on the local host since a given time. It specifies a verb ('summarize'), resource ('sshd auth log entries'), and scope ('local host since since'). It distinguishes from sibling tools that perform scans or audits of different resources.
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 does not provide guidance on when to use this tool versus alternatives like check_scope or other audit tools. There is no mention of prerequisites (e.g., needing sudo), typical use cases, or scenarios where it should not be used. Agents must infer usage from context.
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 full burden. It only mentions refusal if target not in scope.yaml, but omits critical behaviors like scan duration, potential network disruption, required permissions, or output format. This is insufficient for a security scanning tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) and front-loaded, but it sacrifices completeness. It is adequately concise but could include more useful context without becoming verbose, such as a brief note on output or profile behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of multiple sibling tools and an output schema, the description does not address what the output contains or how the tool integrates with scoping. Missing details on profiles, performance expectations, and error handling make it incomplete for reliable agent usage.
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%, so description must compensate. It lists profile values but does not explain what each profile does (e.g., port range, speed). The 'target' parameter is left vague with no format hints (IP, hostname). Minimal added value beyond 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?
Description clearly states the action ('Run an nmap scan') and the resource ('target'). It distinguishes this tool from siblings like gobuster_dir or nikto_scan by specifying nmap scanning and listing available profiles (quick, full_tcp, service, udp).
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 on when to use this tool versus alternatives such as nikto_scan or hydra_bruteforce. The only behavioral note is a refusal condition, but no explicit context for selection among sibling tools.
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 provided, the description carries full responsibility. It discloses that the audit is offline and uses hashcat/john, implying potential intensive computation. However, it does not mention resource requirements, time expectations, or whether the hash file must be preprocessed. No annotation contradictions exist.
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 description is a single sentence under 15 words, which is concise and front-loaded. Every phrase earns its place: 'offline password-strength audit,' 'hashcat/john,' 'hash file placed in data/hashes/'. It could be slightly more structured but is efficient.
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 complexity (offline cracking with parameters like hash mode and wordlist) but having an output schema, the description is partially complete. It explains the purpose and file location but lacks guidance on hash mode selection, wordlist format, and expected output. With 0% schema coverage and no annotations, more detail is warranted.
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% (no parameters explained in description). While the description mentions 'hash file placed in data/hashes/', it does not explain hash_file, hash_mode, wordlist, or tool beyond the tool's default. The schema itself lacks descriptions for each property, so the description does not add enough semantic meaning for the 4 parameters.
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 it runs an offline password-strength audit using hashcat/john against a hash file. The verb 'Run' and resource 'password-strength audit' are specific, and the mention of specific tools (hashcat/john) adds clarity. It distinguishes from siblings like hydra_bruteforce (online) but could explicitly differentiate from other audit 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?
The description implies usage for offline password auditing, which contrasts with online tools like hydra_bruteforce. However, it does not state when to use this vs. other audit tools (e.g., audit_suid_world_writable) or provide any prerequisites or exclusions. The context suggests it's for offline cracking, but explicit guidance is missing.
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 provided, the description bears full responsibility for behavioral disclosure. It reveals one behavioral trait (refusal when out of scope) but omits critical details such as scan duration, potential destructiveness, network permissions, or that nikto scans can be intrusive. The output schema may cover return format, but the description does not mention any behavioral aspects beyond the refusal.
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 that conveys the essential purpose and a key constraint. It is front-loaded, contains no filler, and every word earns its place, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description lacks context about the scan's behavior, whether it is synchronous or asynchronous, expected duration, error handling, and what the return values represent. For a moderately complex tool like a security scanner, this is insufficient for an AI agent to use it correctly without additional clues.
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 input schema has 0% description coverage, so the description carries the burden. It adds meaning by explaining that 'target' and 'port' are used together in a 'target:port' format for a web vulnerability scan, clarifying that the target is a web server. This goes beyond the empty schema, though it does not specify format constraints (e.g., IP vs hostname).
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 runs a 'nikto web vulnerability scan' against a target and port, which is a specific verb and resource. It distinguishes itself from sibling tools like nmap_scan (port scanning) and gobuster_dir (directory brute force) by specifying web vulnerability scanning.
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 only mentions that the tool refuses if the target is not in scope.yaml, which is a condition rather than guidance on when to use it. It does not provide explicit context for choosing this tool over alternatives like nmap_scan or gobuster_dir, nor does it describe prerequisites or typical scenarios.
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 of behavioral disclosure. While it states the core action (find files), it does not reveal whether the operation is read-only, what permissions are required, how results are returned (despite an output schema existing), or any side effects. A 2 reflects the minimal behavioral context added beyond the bare 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, front-loaded sentence with zero redundancy. Every word contributes meaning: verb, object, scope, and defaults. It is optimally concise for its information content.
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 low parameter count, no annotations, and the presence of an output schema, the description is minimally adequate for a simple file-finding tool. It lacks details on invocation permissions, result format, or performance impact, but the output schema likely fills some gaps. The completeness is middle-tier because the description covers the 'what' and 'where' but not the 'how' or 'what else'.
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?
Schema description coverage is 0%, so the description must compensate. It adds value by specifying the default paths (`/usr /etc /opt /home`), which are not present in the schema. It also clarifies that `paths` is the search location. However, it does not explain the parameter's array nature or provide examples, leaving some ambiguity for an AI agent.
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 action ('Find') and specific resource ('SUID and world-writable files'), along with scope ('under `paths` (default /usr /etc /opt /home) on this local host'). This distinguishes it from sibling tools like audit_listening_ports (network ports) and audit_pacman_packages (package integrity).
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 explicit guidance is given on when to use this tool versus alternatives (e.g., check_scope, nmap_scan, or other audit tools). The phrase 'on this local host' hints at a local-only scope, but there is no explanation of prerequisites, limitations, or alternative tools for remote or different privilege scenarios.
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?
There are no annotations, so the description carries the full burden of behavioral transparency. The description says 'inventory' which is a read-only operation, implying safety, but it does not explicitly state that it is non-mutating. It does not describe any side effects, output details, or dependencies on system state. Given the lack of annotations, the description could be more explicit about it being a harmless read operation, but it's not misleading.
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 description is one concise sentence that front-loads the main purpose and includes a useful parenthetical detail about categorization. It doesn't waste any words, and the structure is clean. Minor deduction because it could arguably include a brief note on output format, but it's still efficient.
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 this is a simple, parameterless tool with an output schema (which the description doesn't need to detail), the description is relatively complete. It explains what the output is (installed tools grouped by categories), which aligns with the tool's purpose. The sibling tools are more complex, but for a list/inventory tool, this provides sufficient context. It could mention typical use cases (e.g., pre-engagement assessment), but that's not necessary.
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?
This tool has zero parameters, so the schema automatically covers 100% of the parameters. The description does not need to describe any parameters. The baseline for zero parameters is 4, and the description does not add unnecessary parameter info, so it's appropriate.
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 purpose: to inventory installed BlackArch security-tool packages, and mentions categorization by category, which helps distinguish it from the sibling tools that are more specific operations (e.g., nmap_scan, hydra_bruteforce). This is a specific verb-resource combination (list installed packages) with useful contextual detail (grouped by category).
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 that this is a discovery/inventory tool, which should be used to see what tools are installed. However, it does not explicitly state when to use this over siblings, nor does it mention alternatives (e.g., for more detailed tool info, use audit_pacman_packages). The context is clear enough for an agent to infer it's a broad inventory read, but lacks explicit guidance.
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 full burden. It states the tool checks authorization but does not explain what happens on success/failure (e.g., returns boolean, throws error, or modifies state). Return value behavior is not clarified, which is a gap for a tool that likely outputs a boolean or result.
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?
One sentence, front-loaded with the core action, no wasted words. It perfectly balances brevity with essential information.
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 presence of an output schema and only one parameter, the description is reasonably complete for a simple authorization check tool. However, the lack of clarity on return behavior (what does 'check' return? a boolean?) and absence of any error handling context (what if scope.yaml missing?) leaves some gaps. The output schema likely fills some of this, but the description could be more explicit.
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 description provides some semantics for the single parameter `target` by mentioning it should be checked against 'scope.yaml.' Since schema coverage is 0%, the description compensates meaningfully. However, it does not elaborate on format or constraints (e.g., must be a URL, IP, hostname). Still, for a single param, the context is helpful.
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 checks authorization of a `target` against a scope.yaml file before running red-team tools. The verb 'check' and resource 'scope' are specific, and it distinguishes itself from sibling tools which are direct attack/audit tools rather than a preflight authorization check.
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 explicitly says to run this tool 'before running any red-team tool,' providing clear usage context. However, it does not provide explicit when-not-to-use guidance or alternatives, though the purpose as a prerequisite makes that less critical. The sibling tools are all red-team tools, so the usage is well implied.
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 full burden. It states 'Check' which implies a read-only operation, and the resource is a config file. However, it does not disclose permissions needed (e.g., root), potential side effects, or the nature of the baseline ruleset. The behavior is partially transparent.
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 concise sentence that is front-loaded with the key action and resource. Every phrase earns its place, with no superfluous 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?
For a simple tool with one optional parameter and an output schema, the description covers the core action and location. It specifies that the check is on the local host. The output schema exists to describe return values, so the description is sufficiently complete. Minor gaps: origin of the baseline ruleset is not mentioned.
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?
Schema description coverage is 0%, so the description must compensate. It references the `path` parameter and clarifies it is the path to sshd_config, which adds minimal meaning beyond the schema's name and default. No further details on format or validation are provided.
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 verb 'Check' and the resource 'sshd_config' at a specified path against a baseline hardening ruleset on the local host. It distinguishes the tool from all siblings, none of which deal with SSH config auditing.
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 when-to-use or when-not-to-use guidance is provided. The context is implied (check SSH config hardening), but no alternatives are mentioned. Since there are no obvious sibling tools for this task, the lack of explicit guidance is acceptable but not ideal.
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 full burden. It discloses the double opt-in (confirm=True) and scope constraint, which are important behavioral guardrails. However, it does not mention potential side effects (account lockouts, network impact) or what happens on success/failure, limiting transparency for a destructive tool.
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 consists of two concise sentences with no filler. The purpose is front-loaded, and every sentence adds critical information (what the tool does, prerequisites).
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 need not be explained. The tool has 5 parameters (4 required, no enums). The description covers the main use case and prerequisites but lacks details on file path construction, safety considerations, and what happens if confirm=False or target is out of scope. Adequate but with notable gaps.
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?
Schema description coverage is 0%, so the description must add meaning. It explains that 'target' and 'service' are brute-forced, and 'userlist'/'passlist' are local files, and clarifies that 'confirm=True' is required to execute. This adds moderate value, but it does not specify file path formats, supported service types, or the behavior when confirm=False.
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 states a specific verb ('brute-force'), resource ('target/service with hydra'), and method ('using local userlist/passlist files'). It clearly distinguishes from sibling tools like nmap_scan or crack_hash_offline, as none of those perform online credential brute-forcing.
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 the tool (credential brute-forcing) and explicit prerequisites ('confirm=True', 'target must be in scope.yaml'). However, it does not explicitly state when NOT to use it or name alternatives; given sibling tools are all distinct, this is a minor gap.
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?
The description explicitly marks the operation as read-only, which is valuable for safety. However, with no annotations provided, it does not disclose potential prerequisites (e.g., sudo access) or any locking behavior of the pacman database. Additional context about what is not affected would improve transparency.
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-formed sentence that immediately conveys the tool's action, data produced, method, and safety characteristic. Every word adds value with no redundancy.
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 (no parameters, read-only, local host) and the presence of an output schema, the description is largely complete. It could optionally mention that this only works on Arch Linux-based systems, but the context of pacman strongly implies that. Overall sufficient.
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?
There are no parameters in the schema, so the description does not need to add parameter details. Schema coverage is 100% vacuously. The description correctly clarifies the scope (local host, specific report types), which aligns with the baseline of 4 for zero-parameter tools.
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 reports orphan packages, available updates, and package integrity using pacman on the local host. It uses a specific verb-resource combination and distinguishes from sibling audit tools like audit_listening_ports or audit_suid_world_writable.
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 usage for pacman-based package auditing but provides no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions or prerequisites, leaving the agent to infer based on the name and sibling list.
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 full burden. It states the operation is 'list', implying read-only, and mentions the underlying command 'ss -tulnp'. However, it does not explicitly confirm no side effects or mention permissions needed. Without annotations, the description is adequate but not fully explicit.
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, 14 words, front-loaded with action. No unnecessary words or repetition. Earning its place fully.
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?
Given zero parameters and an output schema present (so return values need not be described), this description fully covers the tool's behavior. It mentions the command used and the cross-referencing aspect, leaving no gaps for an agent to misuse it.
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?
There are zero parameters, so baseline is 4. The schema coverage is 100% trivially. The description does not need to explain parameters and does not add confusion.
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 'List' and resource 'listening ports', and adds cross-referencing with firewall rules on the local host. This clearly distinguishes it from sibling tools like nmap_scan (remote scanning) and audit_suid_world_writable (file permissions).
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 states what the tool does but does not explicitly indicate when to use it versus alternatives or when not to use it. The context of sibling tools and tool name imply it is for local port auditing, but no direct guidance is provided.
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:

[![blackarch-AI MCP server](https://glama.ai/mcp/servers/Pusparaj99op/blackarch-AI/badges/card.svg)](https://glama.ai/mcp/servers/Pusparaj99op/blackarch-AI)

Score Badge

Copy to your README.md:

[![blackarch-AI MCP server](https://glama.ai/mcp/servers/Pusparaj99op/blackarch-AI/badges/score.svg)](https://glama.ai/mcp/servers/Pusparaj99op/blackarch-AI)

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/Pusparaj99op/blackarch-AI'

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