Secops Toolkit MCP

by glatinone

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.9.0
Disambiguation5/5
Each tool has a clear, distinct purpose: IOC handling (defang/refang/extract), hashing, password entropy, CIDR operations, shell command assessment, and repo scanning. No overlap or ambiguity.
Naming Consistency4/5
All tools use snake_case, but naming pattern varies between verb_noun (extract_iocs, scan_repo_root) and noun_noun (password_entropy, cidr_info). Mostly consistent but minor mixing.
Tool Count5/5
9 tools cover a broad range of secops tasks without being excessive. Each tool adds value, and the count is well-scoped for the server's purpose.
Completeness4/5
Covers core secops areas: IOC handling, hashing, password analysis, CIDR, shell assessment, repo scanning. Minor gaps like URL analysis missing, but no critical dead ends.
Average 4/5 across 9 of 9 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 17 commits in the last 12 weeks
- Last stable release on July 29, 2026
- 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?
No annotations are provided, and the description only reveals the transformation effect. It does not disclose any side effects, reversibility, permissions, or other behavioral traits beyond the basic operation.
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. However, it could be slightly improved by expanding on parameter semantics without becoming verbose.
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 transformation tool with one input and a likely clear output, the description is mostly complete. The missing parameter detail is a gap, but overall it provides sufficient context for an agent to understand the tool's core function.
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?
With 0% schema description coverage, the description must explain the 'indicator' parameter but only gives an IP example. It does not clarify what types of indicators are accepted (e.g., IPs, URLs, hashes), leaving ambiguity.
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 ('make an indicator safe to share by defanging it') and provides an example transformation. It distinguishes itself from the sibling tool 'refang_ioc' by specifying the defanging direction.
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 use when sharing indicators safely, but does not explicitly state when to use this tool vs alternatives (e.g., refang_ioc) or any 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?
No annotations are provided, so the description must disclose behavioral traits. It only states 'check whether', which is read-only, but fails to mention error conditions (e.g., invalid IP or CIDR format), or any additional side effects. The output schema exists but its details are not visible.
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 immediately conveys the tool's purpose. There is no redundant information, and it 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (two string parameters) and the presence of an output schema, the description is minimally complete. However, it lacks guidance on input formats, edge cases, and how it complements sibling tools like 'cidr_info'. With no annotations, more detail would be beneficial.
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%, meaning the schema has no descriptions for the two parameters. The tool description does not add any semantic details, format hints, or examples for 'ip' or 'cidr' strings, leaving the agent without guidance on valid input formats.
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 'IP address falls inside a given CIDR network'. It is distinct from sibling tools like 'cidr_info' which returns info about a CIDR, and other sibling tools are unrelated to IP/CIDR checks.
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 testing IP membership in a CIDR network, but does not explicitly state when to use this tool versus alternatives (e.g., 'cidr_info'), nor does it mention when not to use it. It relies on the agent inferring the context.
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 carries the burden of behavioral transparency. It implies a read-only operation ('Describe') and lists return attributes, but does not explicitly state safety, authorization needs, or potential side effects. It is adequate but not thorough.
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—two sentences—with the purpose stated upfront and an example immediately following. Every word adds value, and there is 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 (single parameter, no annotations), the description covers core functionality and input format. The output schema is present, so return values are not required in the description. It is nearly complete for the tool's complexity.
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 0% schema coverage, the description compensates by providing concrete examples of valid CIDR notation (e.g., '192.168.0.0/24' and '10.0.0.5/8'). This adds significant meaning beyond the schema's bare parameter name.
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: to describe an IPv4/IPv6 network, listing specific attributes like netmask, host range, size, and privacy. It differentiates well from siblings such as ip_in_cidr, which focuses on IP membership checks.
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 like ip_in_cidr or extract_iocs. The description lacks explicit context for appropriate usage scenarios or exclusions.
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 discloses that it returns a dict keyed by indicator type (only types found) and handles defanged indicators, but does not specify behavior for empty inputs (e.g., returns empty dict or None) or any performance considerations.
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 three concise sentences with no unnecessary words. The main purpose is front-loaded, and every sentence adds useful information. It is well-structured and easy to scan.
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 a single parameter, no annotations, and an output schema (not shown), the description covers the core functionality, supported IOC types, and return format. However, it omits details about how to handle cases with no indicators found, which is a minor gap for 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?
There is only one parameter 'text' with 0% schema description coverage. The description adds that it expects free-form text or log output, but no further details on constraints like length, encoding, or format are provided, which is minimal 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?
The description clearly states the tool extracts indicators of compromise from free-form text or log output. It lists specific indicator types (IPv4, URLs, domains, hashes, CVE IDs) and mentions handling defanged indicators, which distinguishes it from sibling tools like defang_ioc and refang_ioc.
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 text containing IOCs and mentions defanged handling, but it does not explicitly state when to use this tool over alternatives like hash_text or cidr_info. No direct comparison or exclusion criteria are provided.
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?
No annotations, so description must carry full weight. It explains the tool is non-destructive (read-only estimation) and describes return values and limitation. Good for a simple 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?
Two sentences, no fluff, directly conveys purpose and limitations. Perfectly sized and front-loaded.
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 low complexity and presence of output schema, description covers return values and key limitation. Could mention if password is sensitive, but otherwise adequate.
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 0% and description adds no extra meaning for the single 'password' parameter. It's obvious from context, but no format, length constraints, or sensitivity warnings 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?
Description clearly states the tool estimates password strength as bits of entropy, returns specific fields, and distinguishes it from breach checking. Sibling tools are unrelated, so no confusion.
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?
Explicitly notes it's a quick floor estimate and not a breach list check, implying its use case. Could detail when to use exactly, but siblings are distinct so not critical.
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 full burden and effectively discloses behavior: it checks top-level for shadowed executables and whole-tree for external symlinks, with severity levels. It does not mention non-destructive nature or auth needs, but these are implied by scanning.
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 well-structured, starting with the purpose and then detailing two distinct checks with rationale. It is relatively long but every sentence adds value, explaining the threat model and severity. Minor trimming possible but justified by complexity.
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 the complexity of two scanning operations, no annotations, and an output schema present (so return values don't need explanation), the description is complete. It covers what is checked, why, severity, and the security patterns involved. No gaps are apparent.
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 a single required 'path' parameter, but the description provides no explicit definition or example of what the path should represent. With 0% schema description coverage, the description must compensate, but it only implies the path via context. This is insufficient for unambiguous parameter understanding.
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 checks a repo's top-level directory for shadowed developer command names and the whole tree for external symlinks. This is specific, actionable, and distinguishes it from sibling tools which focus on IOCs and text manipulation.
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 advises running this tool 'before opening a freshly cloned or downloaded repository in an agentic coding tool,' and explains the security rationale. It does not provide explicit when-not-to-use guidance or alternatives, but the context is clear.
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?
No annotations are present, so the description carries full burden. It accurately describes the transformation with an example. However, it does not mention error handling, input validation, or any side effects. For a simple transformation, this is adequate.
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 plus an example. No wasted words. Front-loaded with action and example.
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 (1 param, no enums, output schema exists), the description is nearly complete. It lacks details on validation or edge cases, but the core functionality is well-covered.
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%. The description adds context via an example but does not explain what constitutes a defanged indicator or the expected format. This is a gap when the schema provides only a type.
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: 'Reverse a defanged indicator back to its real form' with an illustrative example. It distinguishes this tool from its counterpart 'defang_ioc' by specifying the reverse operation.
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 implies use when a defanged indicator needs to be restored, but does not explicitly state when not to use or mention alternatives. The sibling tool 'defang_ioc' provides natural contrast, but explicit guidance would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description details that the tool never executes the command, tokenizes with POSIX rules, and returns risk levels and findings. It also explains the types of dangerous constructs flagged (e.g., command substitution, variable expansion, symlink attacks). Since no annotations are provided, the description fully carries the burden of behavioral disclosure.
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 thorough and well-structured, starting with the overarching purpose, then detailing specific attack classes, and ending with output fields. While slightly long, every sentence adds value, making it appropriately detailed for a complex tool.
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?
The description covers the tool's purpose, behavior, output (risk, findings, bypassed_raw_pattern_match), and specific attack patterns. It is complete for an agent to understand when and how to use the tool, especially given the complexity and the existence of an output schema.
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 only parameter is 'command', which is a string. The description adds meaning by explaining it is a shell command to assess, but the schema is minimal (0% coverage). Given the single obvious parameter, the description is adequate.
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 assesses shell commands for constructs that bypass naive string matching, listing specific attack classes (GuardFall, DuneSlide, Terminal Tool Bypass). It is distinct from sibling tools (e.g., refang_ioc, extract_iocs) which deal with IOCs, not shell commands.
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 tells when to use the tool (when you need to detect obfuscated shell commands) but does not explicitly state when not to use it or name alternatives. However, the specificity makes usage clear, and no sibling tool performs similar analysis.
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?
No annotations are provided, but the description fully discloses the behavior: compute a hash, algorithm options, and return format (algorithm + hex digest). No side effects or permissions needed, so adequate for a pure function.
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?
Two sentences with no waste. Front-loaded with the action verb and resource. Every sentence adds value.
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 the tool's low complexity (2 params, no nested objects) and existence of an output schema, the description fully covers what the tool does and returns. No gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds meaning by explaining the text parameter as the string to hash and listing the algorithm options (md5, sha1, sha256, sha512) with a default. This compensates fully.
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 computes a cryptographic hash of a string, which is a specific verb and resource. It lists the supported algorithms and default, and it is distinct from sibling tools that handle IOCs and entropy.
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?
No explicit when-to-use or when-not-to-use guidance, but sibling tools are clearly unrelated (IOC handling, CIDR), so it is evident this tool is for hashing strings. Context is clear.
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:

[![secops-toolkit-mcp MCP server](https://glama.ai/mcp/servers/glatinone/secops-toolkit-mcp/badges/card.svg)](https://glama.ai/mcp/servers/glatinone/secops-toolkit-mcp)

Score Badge

Copy to your README.md:

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

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