Skip to main content
Glama
cyberbuff

Atomic Red Team MCP

by cyberbuff
OverviewSchemaRelated ServersScoreDiscussions
Python
Remote

server_info

Read-onlyIdempotent

Retrieve server configuration details including version, transport, OS, and data directory to verify setup and confirm compatibility before executing atomic tests.

Instructions

Get comprehensive information about the MCP server configuration and environment.

This tool returns server metadata including version, transport protocol, operating system, and data directory location. Use this to:

  • Verify server configuration

  • Check server version for compatibility

  • Confirm the platform before executing atomic tests

  • Locate the atomic tests data directory

Args: ctx: MCP context (provided automatically by the framework)

Returns: ServerInfoOutput: Server information with the following fields: - name (str): Server name - always "Atomic Red Team MCP" - version (str): Installed package version (e.g., "1.2.3") Shows "dev" if running from source without installation - transport (str): MCP transport protocol being used Values: "stdio" (default), "sse", or "streamable-http" - os (str): Operating system platform Values: "Darwin" (macOS), "Linux", "Windows" Use this to verify test compatibility before execution - data_directory (str): Absolute path to atomic tests storage directory This is where atomic YAML files are stored Use this path when creating new atomic tests - execution_enabled (bool): Whether atomic test execution is enabled on this server

Examples: # Get server information info = server_info(ctx) print(f"Running version {info.version} on {info.os}")

# Check if remote server for execution
if info.transport == 'streamable-http':
    print("This is a remote MCP server")

# Get data directory for creating tests
data_dir = info.data_directory
print(f"Create new tests in: {data_dir}/T####/T####.yaml")

Use Cases: 1. Before executing tests: Check OS matches supported_platforms 2. Creating atomic tests: Use data_directory to know where to save files 3. Debugging: Verify configuration settings 4. Version compatibility: Ensure tools match server version

Notes: - This tool always succeeds and never raises exceptions - Information reflects the current runtime configuration - Transport and data_directory come from Settings (environment variables/.env) - OS is detected at runtime and cannot be changed

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
osYesOperating system platform (Darwin, Linux, Windows)
nameYesServer name
versionYesServer version number
transportYesMCP transport protocol being used (stdio, sse, streamable-http)
data_directoryYesAbsolute path to atomic tests storage directory
execution_enabledYesWhether atomic test execution is enabled on this server

Tool Definition Quality

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnlyHint and idempotentHint annotations, the description discloses that the tool always succeeds and never raises exceptions, reflects current runtime configuration, derives transport and data_directory from settings, and detects OS at runtime. It also details each return field's possible values, adding significant context.

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 lengthy but well-structured with sections, bullet lists, examples, and notes. It is front-loaded with the main purpose, followed by return field details, examples, and use cases. Although some redundancy exists between the 'Use this to' list and the 'Use Cases' section, every section earns its place and the organization makes it scannable.

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?

For a tool with no parameters and rich annotations, the description covers all necessary context: return field semantics, example usage, use cases, environment variable dependencies, and error behavior. It even provides a path template for creating tests, making it fully self-contained.

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 user-supplied parameters; the schema coverage is 100%. The description mentions the framework-provided ctx only as a placeholder. With zero parameters, the baseline is 4, and no further parameter explanation is needed.

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 opens with a clear verb and resource: 'Get comprehensive information about the MCP server configuration and environment.' It distinguishes this tool from siblings like query_atomics and generate_atomic by focusing on server metadata. The use cases further clarify its unique role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides an explicit 'Use this to' list covering verification, compatibility checks, platform confirmation before atomic tests, and locating the data directory. The 'Use Cases' section adds concrete scenarios such as before executing tests and creating atomic tests. Although no alternative tools are named, the guidance is complete for this unique informational tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

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/cyberbuff/atomic-red-team-mcp'

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