Mythic MCP

by johanrobbenites

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 target distinct actions (file read vs. upload, shell vs. PowerShell, mimikatz vs. Rubeus), but ad_recon and enum_domain_users overlap in purpose, as enum_domain_users is a specific subset of AD reconnaissance. This is a minor ambiguity rather than a major one.
Naming Consistency4/5
The majority follow a verb_noun pattern (read_file, run_shell_command, execute_powershell, upload_file), but ad_recon and privilege_escalation_peas deviate by using nouns or abbreviations without a clear verb. The inconsistency is noticeable but not chaotic.
Tool Count5/5
With 12 tools, the set is well-scoped for a post-exploitation/Mythic C2 server. Each tool serves a clear function in the red-team workflow, and the count fits comfortably within the ideal range without feeling bloated or sparse.
Completeness4/5
The set covers core post-exploitation activities: execution, file operations, credential theft, privilege escalation, and AD reconnaissance. Missing features like process listing or lateral movement are notable but not critical for the primary purpose, and agents can often work around these gaps.
Average 3.2/5 across 12 of 12 tools scored. Lowest: 2.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior1/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. 'Run AD reconnaissance commands' is extremely opaque: it doesn't state whether operations are read-only or potentially modifying, what commands are executed, errors are handled, or what 'collate results' means in practice. There is zero depiction of side effects or privileges required.
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, concise sentence with no filler. It successfully front-loads the core action. However, its brevity borders on under-specification, but as a drafting matter it is efficient, so it earns a high score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is likely complex (running multiple AD commands and aggregating results), yet the description provides almost no operational context. There is no output schema to clarify returns, no mention of agent_id semantics, and no indication of what the collated results look like. The description is woefully incomplete for an agent to use the tool correctly.
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?
The schema has one required parameter, agent_id, with no description (0% coverage). The tool description does not mention this parameter at all, leaving its meaning, format, and purpose completely unexplained. The description fails to compensate for the schema's silence.
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 states a specific action ('Run AD reconnaissance commands') and an additional purpose ('collate results'), which distinguishes it from general shell execution or specific AD tools like run_sharphound or enum_domain_users. However, it lacks detail on which commands are included or what 'reconnaissance' covers, so it's clear but not fully differentiated.
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. Sibling tools like run_sharphound, enum_domain_users, and run_kerberoast are more specific AD reconnaissance tools, but the description does not explain whether ad_recon should be used instead or in conjunction. The reader is left to infer the intended 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?
No annotations exist, so the description carries full responsibility for behavioral disclosure. It only states that mimikatz runs and output is returned, omitting critical details like potential credential dumping, administrative requirements, security risks, or side effects. This is a significant gap for a sensitive tool.
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, clear sentence with no unnecessary words. It is appropriately concise, though the brevity sacrifices content quality in other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity and sensitivity of mimikatz, the description is severely incomplete. It lacks information about where the tool runs (agent_id), what mimikatz does, expected output format, or any warnings, making it insufficient for safe and correct invocation.
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%, and the description adds no meaning beyond the parameter names. It vaguely references 'provided arguments' but does not explain agent_id or the expected format of mimikatz_arguments, leaving the agent without guidance for filling parameters correctly.
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 mimikatz with provided arguments and returns output. The verb 'Runs' and specific resource 'mimikatz' distinguish it from sibling tools like run_shell_command or execute_powershell, which are generic execution tools.
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 guidance on when to use this tool versus alternatives such as run_shell_command or execute_powershell. It does not mention any prerequisites, exclusions, or preferred scenarios, leaving the agent without context for tool selection.
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 must fully disclose behavior, but it only notes that authentication is an 'attempt' and is 'for the current session.' It omits side effects, required permissions, failure modes, and the impact on subsequent operations. The phrase 'network calls only' is ambiguous and does not clarify the tool's behavior.
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 brief and front-loaded, with a single clear sentence followed by an args list. Explanations for username and password are useful and avoid fluff. However, the args section is somewhat redundant with the schema, and the missing agent_id is a structural gap.
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 three required parameters, no output schema, and no annotations, the description is insufficient. It fails to clarify the role of agent_id, the nature of 'network calls,' or the authentication's effect on the current session. For a security-sensitive tool, this lack of context is a significant gap.
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 the description must compensate for all three required parameters. It explains username and password meaningfully, but completely fails to mention agent_id, a required field. This leaves a critical parameter undocumented, offering only partial compensation.
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 purpose with a specific verb and resource: 'Attempt to authenticate as another user.' It distinguishes itself from sibling tools like run_shell_command or ad_recon by focusing on authentication rather than execution or reconnaissance. The qualifier '(network calls only)' adds further specificity.
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 guidance on when to use this tool versus alternatives. It does not mention prerequisites, recommended contexts, or any exclusions. No sibling tools are referenced, and the 'network calls only' hint is too vague to serve as a usage guideline.
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 adds a useful technical detail: the script is encoded to UTF-16LE and sent via -EncodedCommand, which reveals how the execution is performed. However, with no annotations, it fails to disclose output behavior, side effects, permissions, or failure modes, which are critical for an execution 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 is exceptionally concise, consisting of two clear sentences with no redundant information. Every word earns its place, and the structure is front-loaded with the core action.
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?
For an execution tool, the description is inadequate. It omits crucial information such as output/return behavior, execution duration, privilege requirements, and error handling. The encoding detail is helpful but does not compensate for the lack of annotations and output schema.
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 schema provides zero description coverage for parameters, but the description only explains script encoding and does not clarify the semantics of agent_id or the script content itself. It adds minimal value beyond parameter names, so the agent must infer meaning from names alone.
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 executes a PowerShell script on a target agent, which is a specific verb+resource and distinguishes it from sibling tools like run_shell_command. However, it does not explicitly highlight when to prefer this over other execution tools, so it doesn't fully meet the standard for 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided regarding when to use this tool versus alternatives such as run_shell_command. It does not mention prerequisites, scenarios, or exclusions, leaving the agent without direction for tool selection.
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 mentions uploading and running Rubeus, but does not disclose the system impacts, permissions required, output format, or that Kerberoasting involves network requests and potential hash extraction. This is a significant transparency gap.
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, efficient sentence with no filler. It front-loads the main action and purpose. While it is brief, it is not under-specified to the point of being a tautology.
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, no annotations, and no output schema, this minimal description is insufficient. It omits any guidance on parameter usage, expected outputs, or system behavior, leaving the agent to guess at essential details.
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% for three parameters. The description does not explain what rubeus_base64, agent_id, or args mean or how they should be populated. Since coverage is low and the description fails to compensate, parameter semantics are essentially absent.
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 uploads and runs Rubeus, a Kerberoasting tool. It identifies a specific verb+resource+scope, distinguishing it from generic shell or upload tools. However, it does not explicitly differentiate from similar sibling tools like run_sharphound, so it lacks full 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical '(Kerberoasting)' provides a clear context for when to use this tool: when performing Kerberoasting attacks. While it does not mention exclusions or alternatives, the context is explicit rather than implied.
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?
Without annotations, the description only notes that the command uses the default interpreter, omitting safety-critical details like potential system impact, required permissions, or return/error behavior. For a command execution tool, this is a significant transparency 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?
The description is compact and front-loaded with the purpose, followed by a clear Args list. Every sentence contributes, with no redundant boilerplate.
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 can execute arbitrary shell commands, the description is minimal: it does not address output format, error handling, security implications, or what 'running agent' means precisely. Sibling tools with specialized purposes underscore the need for more 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?
The Args section provides definitions for both agent_id and command_line, adding meaning beyond bare schema type information. However, it lacks details like command syntax, quoting rules, or constraints, leaving the agent to guess at proper usage.
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 'Execute' with a clear resource 'a running agent', stating the tool runs a shell command line. It distinguishes itself from specialized siblings like execute_powershell by specifying the default command line interpreter.
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?
There is no guidance on when to use this tool versus alternatives such as execute_powershell or run_as_user. The description only states what the tool does, leaving usage context to be inferred without explicit when/when-not guidance.
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. It discloses that the operation is an 'attempt' and includes a fallback method, but it does not specify whether this is read-only, what side effects (if any) might occur, what the output format is, or what happens on failure. This is insufficient for a tool with zero 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 two sentences, front-loaded with the primary purpose, and every word earns its place. It efficiently conveys the tool's function and fallback mechanism without fluff.
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?
The tool is simple (one parameter, no output schema), and the description covers the core action and method. However, it lacks important context such as required privileges, potential failure modes, or what the result looks like. Given the absence of annotations and schema details, the description could be more complete.
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 coverage is 0% and the description does not explain the 'agent_id' parameter. While the parameter name is somewhat self-explanatory, the description adds no value beyond the schema, and with no parameter documentation, the agent must infer the semantics from the tool name alone.
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 'enumerate' and the resource 'domain users', and it distinguishes the tool by specifying the method (AD cmdlets or net user fallback). This differentiates it from broader siblings like ad_recon or run_sharphound.
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 when to use it (when you need to enumerate domain users) but does not provide explicit guidance on when to prefer it over alternatives like ad_recon or run_sharphound, nor does it mention any exclusions or prerequisites.
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 must disclose behavioral traits, but it only says 'Run'. It does not mention that the tool uploads and executes arbitrary base64 binaries (which could be destructive, loud, or require specific privileges), nor does it describe the side effects or resource impact.
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 appropriately concise: a clear purpose sentence followed by a compact parameter list. Every line adds value, and the structure is front-loaded with the main intent.
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?
For a tool that executes arbitrary code on a target, the description is incomplete. It lacks usage context, behavior expectations, and output details. No annotations or output schema exist to compensate, and the sibling list offers similar actions without differentiators, so the agent is left without enough context to select and invoke it safely.
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 adds meaningful semantics for all parameters beyond the schema's bare titles. It specifies agent_id as 'Mythic agent ID', os_type as 'linux' or 'windows', peas_base64 as the encoded binary, and mode as 'quiet' or 'full'. However, it stops short of explaining what quiet vs full behavior entails, so not a perfect score.
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: 'Run linPEAS or winPEAS on the target agent for privilege escalation discovery.' This is a specific verb-resource-goal combination that distinguishes it from sibling tools like run_shell_command or execute_mimikatz.
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 gives no explicit guidance on when to use this tool versus alternatives. While it mentions the purpose 'for privilege escalation discovery', it does not state prerequisites, exclusions, or contexts where other tools (e.g., run_shell_command) might be more appropriate.
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 the full burden of behavioral disclosure. The word 'Returns' implies a read-only operation, but it does not explicitly state that there are no side effects, nor does it provide any additional behavioral context such as authentication requirements or limits. The description is adequate but minimal.
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 short sentence with no wasted words. It conveys the essential purpose in a directly front-loaded manner, earning a perfect score for conciseness.
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 tool with no parameters and no output schema, the description is nearly complete. It tells the agent what the tool returns (a list of active agents), which is sufficient for basic invocation. However, it does not define what constitutes an 'active' agent or describe the return format, which leaves minor ambiguity.
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 zero properties and the description does not need to explain parameters. According to the rubric, a tool with 0 params gets a baseline of 4. The description adds no parameter information, but none is needed.
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 'Returns a list of active agents' clearly states the tool's function with a specific verb and resource, but it does not differentiate it from sibling tools. The purpose is unambiguous, but no comparison to alternatives is provided.
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 given on when to use this tool versus the sibling tools. The description simply states what it does without any context or exclusions, leaving the agent to infer usage from the tool name and list of alternatives.
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 mentions the prerequisite and output directory, but does not disclose potential side effects like network activity, file creation on the target, or security/AV risks. This is a significant transparency gap for a security 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 is efficient and well-structured with an intro sentence, a prerequisite note, and a list of arguments. Every sentence provides necessary information with no redundancy.
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?
The description covers prerequisites and output location but lacks information on return format, how to retrieve the output ZIP, or behavioral risks. With no annotations and no output schema, it leaves meaningful gaps for a complex tool like SharpHound.
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?
Given 0% schema description coverage, the description compensates by explaining each parameter: agent_id as the Mythic agent ID, collection methods, output_dir for the ZIP, and stealth as recommended. This adds meaningful context beyond the schema's type/defaults, though it could offer more detail on allowed collection values.
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 runs SharpHound (BloodHound collector) on a Windows agent, which is a specific verb and resource. It doesn't explicitly differentiate from sibling AD tools like ad_recon, but the tool name and description are specific enough to distinguish the core purpose.
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 a clear prerequisite (SharpHound.exe must already exist) and recommends stealth mode, which gives context on when to use the tool. It doesn't mention exclusions or alternatives, so it stops short of an explicit 5.
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. It states that it returns file contents but does not mention side effects, permissions, error handling, or whether the operation is read-only. This is a significant gap for a tool with no annotation safety hints.
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 concise and front-loaded, with a clear first sentence stating the tool's purpose, followed by a compact Args section. Every sentence adds value, with no padding or redundancy.
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?
For a simple file-read tool, the description covers the core purpose and parameters, and mentions the return value. However, it lacks context on error conditions, file accessibility, or encoding, which an agent might need. It is moderately complete but leaves clear gaps.
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 parameter descriptions (0% coverage), so the description must compensate. It clarifies both parameters: 'agent_id: ID of agent to read file from' and 'file_path: Path to the file to read on the target server', adding meaningful context beyond the raw schema field 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 'Reads a file using the ReadFile win32 API call. Returns the contents of that file.' This specifies a distinct verb and resource, distinguishing it from siblings like run_shell_command or upload_file.
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?
Usage is implied through the description of parameters ('ID of agent to read file from', 'Path to the file to read on the target server'), but there is no explicit statement of when to use this tool over alternatives or any exclusions. The guidance is minimal but present.
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?
Without annotations, the description must disclose behavioral traits on its own. It does explain the two-step upload process and mentions that content is base64 encoded, but it does not state potential side effects, auth requirements, error behaviors, or whether it overwrites existing files. This is a moderate level of disclosure.
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 highly concise and well-structured: a two-sentence purpose statement followed by a clean Arg list. Every sentence earns its place without redundancy or unnecessary 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 four required parameters, no output schema, and no annotations. The description provides a clear action statement and parameter definitions, which is a good baseline. However, it omits return value behavior, error handling, and edge cases like file overwrites, leaving some gaps for a tool with no structured output.
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 zero description coverage, so the description must compensate. It does by listing each parameter with a concise explanation in the Args section, clarifying agent_id, file_name, remote_path, and content. This adds significant meaning beyond the bare schema, though it lacks deeper format or constraint details.
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 explicitly states the tool's function: uploading a file to the Mythic server and then to a remote target. The verb 'upload' and the two-stage resource description make the purpose clear and distinguishable from sibling tools like read_file or run_shell_command.
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 should be used for uploading files but provides no explicit guidance on when to use it instead of alternatives, nor does it mention any exclusions or prerequisites. This gives a clear context but lacks explicit decision-making support.
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

MCP-IA-for-Offensive-Security MCP server

Copy to your README.md:

[![MCP-IA-for-Offensive-Security MCP server](https://glama.ai/mcp/servers/johanrobbenites/MCP-IA-for-Offensive-Security/badges/card.svg)](https://glama.ai/mcp/servers/johanrobbenites/MCP-IA-for-Offensive-Security)

Score Badge

Copy to your README.md:

[![MCP-IA-for-Offensive-Security MCP server](https://glama.ai/mcp/servers/johanrobbenites/MCP-IA-for-Offensive-Security/badges/score.svg)](https://glama.ai/mcp/servers/johanrobbenites/MCP-IA-for-Offensive-Security)

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/johanrobbenites/MCP-IA-for-Offensive-Security'

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