Skip to main content
Glama
sitbon

Magg

by sitbon
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

🧲 Magg - The MCP Aggregator

Python Version PyPI Version GitHub Release DeepWiki Downloads

Tests Docker

A Model Context Protocol server that manages, aggregates, and proxies other MCP servers, enabling LLMs to dynamically extend their own capabilities.

What is Magg?

Magg is a meta-MCP server that acts as a central hub for managing multiple MCP servers. It provides tools that allow LLMs to:

  • Search for new MCP servers and discover setup instructions

  • Add and configure MCP servers dynamically

  • Enable/disable servers on demand

  • Aggregate tools from multiple servers under unified prefixes

  • Persist configurations across sessions

Think of Magg as a "package manager for LLM tools" - it lets AI assistants install and manage their own capabilities at runtime.

Related MCP server: MCP-MCP

Features

  • Self-Service Tool Management: LLMs can search for and add new MCP servers without human intervention.

  • Dynamic Configuration Reloading: Automatically detects and applies config changes without restarting.

  • Automatic Tool Proxying: Tools from added servers are automatically exposed with configurable prefixes.

  • ProxyMCP Tool: A built-in tool that proxies the MCP protocol to itself, for clients that don't support notifications or dynamic tool updates (which is most of them currently).

  • Smart Configuration: Uses MCP sampling to intelligently configure servers from just a URL.

  • Persistent Configuration: Maintains server configurations in .magg/config.json.

  • Multiple Transport Support: Works with stdio, HTTP, and in-memory transports.

  • Bearer Token Authentication: Optional RSA-based JWT authentication for secure HTTP access.

  • Docker Support: Pre-built images for production, staging, and development workflows.

  • Health Monitoring: Built-in magg_status and magg_check tools for server health checks.

  • Real-time Messaging: Full support for MCP notifications and messages - receive tool/resource updates and progress notifications from backend servers.

  • Python 3.12+ Support: Fully compatible with Python 3.12 and 3.13.

  • Kit Management: Bundle related MCP servers into kits for easy loading/unloading as a group.

  • MBro CLI: Included MCP Browser for interactive exploration and management of MCP servers, with script support for automation.

Installation

Prerequisites

  • Python 3.12 or higher (3.13+ recommended)

  • uv (recommended) - Install from astral.sh/uv

Quick Install (Recommended)

The easiest way to install Magg is as a tool using uv:

# Install Magg as a tool
uv tool install magg

# Run with stdio transport (for Claude Desktop, Cline, etc.)
magg serve

# Run with HTTP transport (for system-wide access)
magg serve --http

Alternative: Run Directly from GitHub

You can also run Magg directly from GitHub without installing:

# Run with stdio transport
uvx --from git+https://github.com/sitbon/magg.git magg

# Run with HTTP transport
uvx --from git+https://github.com/sitbon/magg.git magg serve --http

Local Development

For development, clone the repository and install in editable mode:

# Clone the repository
git clone https://github.com/sitbon/magg.git
cd magg

# Install in development mode with dev dependencies
uv sync --dev

# Or with poetry
poetry install --with dev

# Run the CLI
magg --help

Docker

Magg is available as pre-built Docker images from GitHub Container Registry:

# Run production image (WARNING log level)
docker run -p 8000:8000 ghcr.io/sitbon/magg:latest

# Run with authentication (mount or set private key)
docker run -p 8000:8000 \
  -v ~/.ssh/magg:/home/magg/.ssh/magg:ro \
  ghcr.io/sitbon/magg:latest

# Or with environment variable
docker run -p 8000:8000 \
  -e MAGG_PRIVATE_KEY="$(cat ~/.ssh/magg/magg.key)" \
  ghcr.io/sitbon/magg:latest

# Run beta image (INFO log level)
docker run -p 8000:8000 ghcr.io/sitbon/magg:beta

# Run with custom config directory
docker run -p 8000:8000 \
  -v /path/to/config:/home/magg/.magg \
  ghcr.io/sitbon/magg:latest

Docker Image Strategy

Magg uses a multi-stage Docker build with three target stages:

  • pro (Production): Minimal image with WARNING log level, suitable for production deployments

  • pre (Pre-production): Same as production but with INFO log level for staging/testing (available but not published)

  • dev (Development): Includes development dependencies and DEBUG logging for troubleshooting

Images are automatically published to GitHub Container Registry with the following tags:

  • Version tags (from main branch): 1.2.3, 1.2, dev, 1.2-dev, 1.2-dev-py3.12, etc.

  • Branch tags (from beta branch): beta, beta-dev

  • Python-specific dev tags: beta-dev-py3.12, beta-dev-py3.13, etc.

Pull requests build and test images but do not publish them unless a maintainer adds the push-image label, which publishes ephemeral pr-NN / pr-NN-dev tags (same-repo PRs only). Ephemeral pr-* tags and untagged manifests are cleaned up weekly; version tags are kept forever, so pinned deployments are never affected.

Docker Compose

For easier management, use Docker Compose:

# Clone the repository
git clone https://github.com/sitbon/magg.git
cd magg

# Run production version
docker compose up magg

# Run staging version (on port 8001)
docker compose up magg-beta

# Run development version (on port 8008)
# This uses ./.magg/config.json for configuration
docker compose up magg-dev

# Build and run with custom registry
REGISTRY=my.registry.com docker compose build
REGISTRY=my.registry.com docker compose push

See compose.yaml and .env.example for configuration options.

Usage

Running Magg

Magg can run in three modes:

  1. Stdio Mode (default) - For integration with Claude Desktop, Cline, Cursor, etc.:

    magg serve

  2. HTTP Mode - For system-wide access or web integrations:

    magg serve --http --port 8000

  3. Hybrid Mode - Both stdio and HTTP simultaneously:

    magg serve --hybrid
magg serve --hybrid --port 8080  # Custom port

    This is particularly useful when you want to use Magg through an MCP client while also allowing HTTP access. For example:

    With Claude Code:

    # Configure Claude Code to use Magg in hybrid mode
claude mcp add magg -- magg serve --hybrid --port 42000

    With mbro:

    # mbro hosts Magg and connects via stdio
mbro connect magg "magg serve --hybrid --port 8080"

# Other mbro instances can connect via HTTP
mbro connect magg http://localhost:8080

Available Tools

Once Magg is running, it exposes the following tools to LLMs:

  • magg_list_servers - List all configured MCP servers

  • magg_add_server - Add a new MCP server

  • magg_remove_server - Remove a server

  • magg_enable_server / magg_disable_server - Toggle server availability

  • magg_search_servers - Search for MCP servers online

  • magg_list_tools - List all available tools from all servers

  • magg_smart_configure - Intelligently configure a server from a URL

  • magg_analyze_servers - Analyze configured servers and suggest improvements

  • magg_status - Get server and tool statistics

  • magg_check - Health check servers with repair actions (report/remount/unmount/disable)

  • magg_reload_config - Reload configuration from disk and apply changes

  • magg_load_kit - Load a kit and its servers into the configuration

  • magg_unload_kit - Unload a kit and optionally its servers from the configuration

  • magg_list_kits - List all available kits with their status

  • magg_kit_info - Get detailed information about a specific kit

Quick Inspection with MBro

Magg includes the mbro (MCP Browser) CLI tool for interactive exploration. A unique feature is the ability to connect to Magg in stdio mode for quick inspection:

# Connect mbro to a Magg instance via stdio (no HTTP server needed)
mbro connect local-magg magg serve

# Now inspect your Magg setup from the MCP client perspective
mbro:local-magg> call magg_status
mbro:local-magg> call magg_list_servers

MBro also supports:

  • Scripts: Create .mbro files with commands for automation

  • Shell-style arguments: Use key=value syntax instead of JSON

  • Tab completion: Rich parameter hints after connecting

See the MBro Documentation for details.

Authentication

Magg supports optional bearer token authentication to secure access:

Quick Start

  1. Initialize authentication (creates RSA keypair):

    magg auth init

  2. Generate a JWT token for clients:

    # Generate token (displays on screen)
magg auth token

# Export as environment variable
export MAGG_JWT=$(magg auth token -q)

  3. Connect with authentication:

    • Using MaggClient (auto-loads from MAGG_JWT):

      from magg.client import MaggClient

async def main():
    async with MaggClient("http://localhost:8000/mcp") as client:
        tools = await client.list_tools()

    • Using FastMCP with explicit token:

      from fastmcp import Client
from fastmcp.client import BearerAuth

jwt_token = "your-jwt-token-here"
async with Client("http://localhost:8000/mcp", auth=BearerAuth(jwt_token)) as client:
    tools = await client.list_tools()

Key Management

  • Keys are stored in ~/.ssh/magg/ by default

  • Private key can be set via MAGG_PRIVATE_KEY environment variable

  • To disable auth, remove keys or set non-existent key_path in .magg/auth.json

Authentication Commands

  • magg auth init - Initialize authentication (generates RSA keypair)

  • magg auth status - Check authentication configuration

  • magg auth token - Generate JWT token

  • magg auth public-key - Display public key (for verification)

  • magg auth private-key - Display private key (for backup)

See examples/authentication.py for more usage patterns.

Configuration

Magg stores its configuration in .magg/config.json in your current working directory. This allows for project-specific tool configurations.

Dynamic Configuration Reloading

Magg supports automatic configuration reloading without requiring a restart:

  • Automatic file watching: Detects changes to config.json and reloads automatically (uses watchdog when available)

  • SIGHUP signal: Send kill -HUP <pid> to trigger immediate reload (Unix-like systems)

  • MCP tool: Use magg_reload_config tool from any MCP client

  • Smart transitions: Only affected servers are restarted during reload

Configuration reload is enabled by default. You can control it with:

  • MAGG_AUTO_RELOAD=false - Disable automatic reloading

  • MAGG_RELOAD_POLL_INTERVAL=5.0 - Set polling interval in seconds (when watchdog unavailable)

See Configuration Reload Documentation for detailed information.

Environment Variables

Magg supports several environment variables for configuration:

  • MAGG_CONFIG_PATH - Path to config file (default: .magg/config.json)

  • MAGG_LOG_LEVEL - Logging level: DEBUG, INFO, WARNING, ERROR, CRITICAL (default: INFO)

  • MAGG_STDERR_SHOW=1 - Show stderr output from subprocess MCP servers (default: suppressed)

  • MAGG_AUTO_RELOAD - Enable/disable config auto-reload (default: true)

  • MAGG_RELOAD_POLL_INTERVAL - Config polling interval in seconds (default: 1.0)

  • MAGG_READ_ONLY=true - Run in read-only mode

  • MAGG_SELF_PREFIX - Prefix for Magg tools (default: "magg"). Tools will be named as {prefix}{sep}{tool} (e.g., magg_list_servers)

  • MAGG_PREFIX_SEP - Separator between prefix and tool name (default: "_")

Example configuration:

{
  "servers": {
    "calculator": {
      "name": "calculator",
      "source": "https://github.com/executeautomation/calculator-mcp",
      "command": "npx @executeautomation/calculator-mcp",
      "prefix": "calc",
      "enabled": true
    }
  }
}

Adding Servers

Servers can be added in several ways:

  1. Using the LLM (recommended):

    "Add the Playwright MCP server"
"Search for and add a calculator tool"

  2. Manual configuration via magg_add_server:

    name: playwright
url: https://github.com/microsoft/playwright-mcp
command: npx @playwright/mcp@latest
prefix: pw

  3. The magg server CLI (see below)

  4. Direct config editing: Edit .magg/config.json directly

Managing Servers from the CLI

Server and kit configuration can be managed entirely from the command line — no MCP client or running server required. The CLI edits .magg/config.json directly, and a running Magg instance picks up the changes automatically via config reload. (Tools that require a live server, like magg_search_servers, magg_check, and magg_smart_configure, remain available through any MCP client such as mbro.)

# List servers (human-readable, or JSON on stdout for scripting)
magg server list
magg server list --json

# Add a server
magg server add playwright https://github.com/microsoft/playwright-mcp \
    --command "npx @playwright/mcp@latest" --prefix pw

# Add a server without enabling it, with transport options
magg server add web https://example.com/web --uri http://localhost:9000/mcp \
    --transport '{"keep_alive": false}' --disable

# Update an existing server (pass '' to clear an optional field)
magg server update playwright --prefix play --notes "Browser automation"
magg server update playwright --command "npx @playwright/mcp@next"
magg server update playwright --notes ""

# Enable / disable / inspect / remove
magg server enable playwright
magg server disable playwright
magg server info playwright --json
magg server remove playwright

Real-time Notifications with MaggClient

The MaggClient now supports real-time notifications from backend MCP servers:

from magg import MaggClient, MaggMessageHandler

# Using callbacks
handler = MaggMessageHandler(
    on_tool_list_changed=lambda n: print("Tools changed!"),
    on_progress=lambda n: print(f"Progress: {n.params.progress}")
)

async with MaggClient("http://localhost:8000/mcp", message_handler=handler) as client:
    # Client will receive notifications while connected
    tools = await client.list_tools()

See Messaging Documentation for advanced usage including custom message handlers.

Kit Management

Magg supports organizing related MCP servers into "kits" - bundles that can be loaded and unloaded as a group:

# List available kits
magg kit list

# Load a kit (adds all its servers)
magg kit load web-tools

# Unload a kit (removes servers only in that kit)
magg kit unload web-tools

# Get information about a kit
magg kit info web-tools

# Export the current configuration (or a loaded kit) as a kit file
magg kit export --name my-kit --output my-kit.json

When unloading a kit, servers that belong only to that kit are removed, while servers shared with other kits are kept.

You can also manage kits programmatically through Magg's tools when connected via an MCP client:

  • magg_list_kits - List all available kits

  • magg_load_kit - Load a kit and its servers

  • magg_unload_kit - Unload a kit

  • magg_kit_info - Get detailed kit information

Kits are JSON files stored in ~/.magg/kit.d/ or .magg/kit.d/ that define a collection of related servers. See Kit Documentation for details on creating and managing kits.

MBro Scripts

Automate common workflows with MBro scripts:

# Create a setup script
cat > setup.mbro <<EOF
# Connect to Magg and check status
connect magg magg serve
call magg_status
call magg_list_servers

# Add a new server if needed
call magg_add_server name=calculator source="npx -y @modelcontextprotocol/server-calculator"
EOF

# Run the script
mbro -x setup.mbro

MCP 2026-07-28 (Stateless Spec)

The MCP 2026-07-28 spec moves the protocol to a stateless request/response core. Magg's take: something still has to own long-lived stdio subprocesses, backend connections, and tool-list caching — and that's exactly the layer an aggregator provides. See Magg and the Stateless MCP Spec for the impact analysis and migration plan, including how Magg bridges pre-2026 (stateful) backends to stateless-era clients and how hierarchical Magg deployments fit in.

Documentation

For more documentation, see docs/.

Appearances

Magg appears in multiple locations. Please feel free to submit a PR to add more appearances below in alphabetical order.

Listing, Index, and other MCP Sites

Magg ships a server.json manifest for the official MCP Registry (as io.github.sitbon/magg), and magg_search_servers queries the registry as a first-class discovery source alongside Glama, GitHub, and npm. See MCP Registry Documentation for publishing instructions.

mcp-name: io.github.sitbon/magg

Awesome GitHub MCP Lists

Available Tools

16 tools
magg_add_serverC

Add a new MCP server.

ParametersJSON Schema
NameRequiredDescriptionDefault
cwdNoWorking directory (for commands)
envNoEnvironment variables (dict or JSON string)
uriNoURI for HTTP servers
nameYesUnique server name
notesNoSetup notes
enableNoWhether to enable the server immediately (default: True)
prefixNoTool prefix (defaults to conformed server name)
sourceYesURL of the server package/repository
commandNoFull command to run (e.g., 'python server.py', 'npx @playwright/mcp@latest')
transportNoTransport-specific configuration (dict or JSON string) Common options for all command-based servers: - `keep_alive` (boolean): Keep the process alive between requests (default: true) Python servers (command="python"): - `python_cmd` (string): Python executable path (default: sys.executable) Node.js servers (command="node"): - `node_cmd` (string): Node executable path (default: "node") NPX servers (command="npx"): - `use_package_lock` (boolean): Use package-lock.json if present (default: true) UVX servers (command="uvx"): - `python_version` (string): Python version to use (e.g., "3.13") - `with_packages` (array): Additional packages to install - `from_package` (string): Install tool from specific package HTTP/SSE servers (uri-based): - `headers` (object): HTTP headers to include - `auth` (string): Authentication method ("oauth" or bearer token) - `sse_read_timeout` (number): Timeout for SSE reads in seconds Examples: - Python: `{"keep_alive": false, "python_cmd": "/usr/bin/python3"}` - UVX: `{"python_version": "3.11", "with_packages": ["requests", "pandas"]}` - HTTP: `{"headers": {"Authorization": "Bearer token123"}, "sse_read_timeout": 30}`

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorsNo
outputNo

TDQS

C2.9/5.0
Behavior2/5

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

The description does not disclose any behavioral traits beyond the basic action. Without annotations, it fails to mention side effects, installation steps, or required permissions.

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. While it is not verbose, it could benefit from slightly more detail without harming conciseness.

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 a complex input schema with 10 parameters and no annotations, the description does not provide any context about the server setup process or how parameters relate. It is insufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already covers 100% of parameters with descriptions. The description adds no additional meaning to the parameters, which is acceptable given high schema coverage.

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 the verb and resource clearly: 'Add a new MCP server.' It distinguishes the tool from siblings like 'remove_server' and 'enable_server'. However, it is minimally descriptive.

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 vs alternatives, nor any prerequisites or context for using the tool.

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

magg_analyze_serversB

Analyze configured servers and provide insights using LLM.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/5

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

No annotations provided. The description implies a read-like operation ('provide insights') but does not explicitly state if it modifies state, authentication requirements, or limitations. Important behavioral traits are missing.

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, no fluff, front-loaded. Every word earns its place.

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?

With zero parameters and no output schema, the description is too minimal. It does not explain what insights are provided, output format, or how the LLM is used. Incomplete for a tool performing analysis.

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?

Input schema has zero parameters with 100% coverage. The description adds no param info (trivially fine). Baseline 3 with no need for extra detail; slight improvement for clarity.

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 action (analyze) and resource (configured servers), and mentions use of LLM. It distinguishes from siblings like magg_list_servers and magg_check.

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 vs alternatives like magg_search_servers or magg_smart_configure. No conditions or exclusions mentioned.

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

magg_checkC

Check health of all mounted servers and handle unresponsive ones.

ParametersJSON Schema
NameRequiredDescriptionDefault
actionNoAction to take for unresponsive servers: 'report' (default), 'remount', 'unmount', or 'disable'report
timeoutNoTimeout in seconds for health check per server

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorsNo
outputNo

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description bears full burden for behavioral disclosure. It states health check and handling unresponsive servers but does not explicitly warn about potential destructive side effects of 'remount', 'unmount', or 'disable' actions. The lack of caution about state changes or permissions needed is a significant 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 sentence, very concise with no wasted words. It front-loads the core action (check health) and scope (all mounted servers). While it could benefit from additional context, the conciseness itself is a strength.

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?

The description is incomplete for a tool with output schema and potential side effects. It does not mention return value, behavior of each action, or impact on server state. The AI lacks crucial context to decide whether to use this tool or how to interpret results.

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 100%, so the schema already explains both parameters. The description adds no further meaning beyond the schema. It does, however, implicitly reinforce the action parameter's role by mentioning 'handling' unresponsive servers. Baseline 3 is appropriate as schema carries the load.

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 health of all mounted servers and handles unresponsive ones. It uses specific language ('check health', 'handle unresponsive servers') and the resource scope is explicit. However, it does not explicitly differentiate from sibling tools like magg_status or magg_list_servers, missing a chance to 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 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 over alternatives or when to choose each action (report, remount, unmount, disable). There is no mention of prerequisites, context, or exclusions, leaving the AI to infer usage from schema alone.

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

magg_disable_serverC

Disable a server.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesServer name to disable

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorsNo
outputNo

TDQS

C2.5/5.0
Behavior2/5

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

With no annotations, the description bears full burden. It only says 'Disable a server' without disclosing behavioral traits like reversibility, side effects on connections, or permission requirements. This is insufficient.

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?

Extremely concise, but at the cost of completeness. One sentence with no structure; it is not front-loaded with important context. Adequately concise but not optimally informative.

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 low complexity and presence of an output schema, the description is too brief. It lacks details on the meaning of disable, expected outcomes, and prerequisites, making it incomplete.

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 coverage is 100%, so baseline is 3. The parameter description 'Server name to disable' adds little beyond the schema itself. No additional semantic context is provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the action and resource but lacks specificity. It does not distinguish between similar actions like disable vs. remove or enable. The verb 'disable' is vague without indicating the scope or effect.

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 siblings such as magg_remove_server or magg_enable_server. The description provides no context about prerequisites or consequences.

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

magg_enable_serverC

Enable a server.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesServer name to enable

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorsNo
outputNo

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations provided, the description 'Enable a server' must stand alone. It fails to disclose behavioral traits such as whether the operation is reversible, what side effects occur, authentication requirements, or the impact on the server's state.

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 very concise, consisting of a single sentence that is front-loaded with the key action and resource. Every word earns its place, though it could benefit from a minor expansion for completeness.

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 (one required parameter) and the presence of an output schema, the description is minimally adequate. However, it lacks contextual details about the enabling behavior and expected outcomes, which would help an agent use it correctly.

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 input schema covers 100% of the single parameter 'name' with a clear description 'Server name to enable'. The tool description adds no additional meaning beyond what the schema already provides, so a baseline score of 3 is 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 'Enable a server' clearly states the action (enable) and the resource (server). It effectively distinguishes from sibling tools like 'disable_server' or 'add_server' by using the contrasting verb 'enable'.

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, such as 'magg_disable_server' or other configuration tools. There is no mention of prerequisites, typical scenarios, or when it should not be used.

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

magg_kit_infoC

Get detailed information about a specific kit.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesKit name to get information about

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorsNo
outputNo

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description bears full responsibility for behavioral disclosure. It only states a read operation with no details on side effects, permissions, or response format. The output schema exists but is not referenced.

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 extraneous information. It is front-loaded with the key action and resource, but could benefit from slightly more context.

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 simplicity of the tool (one parameter, output schema present), the description is minimally complete. However, it lacks usage guidance and behavioral details, which are important for correct invocation in 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 input schema has 100% coverage with a description for the 'name' parameter. The tool description does not add any additional meaning beyond what the schema already provides, so baseline score of 3 is 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 action 'Get detailed information' and the resource 'a specific kit', distinguishing it from sibling tools like magg_list_kits which list all kits.

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 such as magg_list_kits for listing or magg_load_kit for loading. The description does not mention prerequisites or typical workflow.

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

magg_list_kitsA

List all available kits with their status.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorsNo
outputNo

TDQS

A3.6/5.0
Behavior2/5

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

No annotations provided; description does not explicitly state read-only nature or any other behavioral traits beyond the implied listing operation. Lacks disclosure of permissions or side effects.

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, efficient, no wasted words. Perfectly concise.

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?

Output schema exists, so return values need not be described. The description covers the basic purpose. Could hint at relationship with magg_kit_info but is still fairly complete for a simple list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so description does not need to add param meaning. Baseline score 4 for zero parameters.

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 verb 'List' and resource 'kits' with added detail 'with their status'. It distinguishes from siblings like magg_kit_info (focused on single kit) and magg_list_servers (different resource).

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 (e.g., magg_kit_info for details). Lacks context for selection.

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

magg_list_serversA

List all configured servers.

Unlike the /servers/all resource, this tool also provides the runtime status of each server (mounted or not).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorsNo
outputNo

TDQS

A4.3/5.0
Behavior3/5

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

No annotations exist, so description must cover behavioral traits. It indicates listing with runtime status but does not confirm read-only nature or other side effects.

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 concise sentences, no wasted words, front-loaded with the core action.

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 zero-parameter tool with an output schema, the description covers the essential distinction (runtime status). No 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?

No parameters present, so schema coverage is 100%. The description need not add parameter details. Baseline score of 4 is appropriate.

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?

Clearly states 'list all configured servers' and distinguishes from an alternative by noting the inclusion of runtime status. This is specific and differentiates from other actions.

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?

Provides context about when to use this tool over /servers/all by highlighting the runtime status feature. No explicit exclusions or when-not instructions, but clear enough.

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

magg_load_kitB

Load a kit and its servers into the configuration.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesKit name to load (filename without .json)

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorsNo
outputNo

TDQS

B3.2/5.0
Behavior2/5

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

Without annotations, the description bears full responsibility for behavioral disclosure. It only says 'load into the configuration' without explaining side effects (e.g., whether it overwrites existing configuration, adds servers, or requires specific permissions). This is insufficient for a state-modifying 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 a single, clear sentence with no redundancies. It effectively front-loads the purpose without extraneous information.

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 only one parameter and an output schema, the description fails to provide context about the configuration update behavior (e.g., additive vs. replacement), error conditions, or the return value. For a tool that modifies state, more detail is needed.

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 100%, so baseline is 3. The description adds no extra meaning beyond the schema's parameter description ('Kit name to load (filename without .json)'), simply restating that it loads a kit and servers.

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 'load' and resource 'kit and its servers', clearly distinguishing it from sibling tools like magg_unload_kit or magg_add_server. It succinctly states what the tool does.

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

Usage 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, such as prerequisites or scenarios where loading a kit is appropriate. The description lacks any usage context.

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

magg_reload_configA

Reload configuration from disk and apply changes.

This will:

  1. Re-read the configuration file

  2. Detect changes (added/removed/modified servers)

  3. Apply changes by mounting/unmounting servers as needed

Note: This operation may briefly interrupt service for affected servers. Config reload can also be triggered via SIGHUP signal on Unix systems.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorsNo
outputNo

TDQS

A4.4/5.0
Behavior4/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 discloses that service may be briefly interrupted for affected servers and provides a step-by-step breakdown of operations. It could add details on prerequisites or error handling, but current coverage is good.

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 well-structured with a clear purpose statement, numbered steps, and a separate note. Every sentence adds value, 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.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that there are no parameters and an output schema exists, the description covers the main effects and process. It lacks details on the return value (though output schema handles that) and error conditions, but is otherwise complete for a no-input tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, and schema coverage is 100%. The description does not need to add parameter explanations, but it could explicitly state that no arguments are required. Since it's implicit from schema, a score of 4 is appropriate.

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 reloads configuration from disk and applies changes, with a step-by-step breakdown. It distinguishes from sibling tools that manage individual servers (e.g., magg_add_server) by focusing on the config reload process.

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 explains the process and notes alternative trigger via SIGHUP, giving context on when to use the tool. However, it does not explicitly state when not to use it or compare with other tools that might achieve similar effects.

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

magg_remove_serverB

Remove a server.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesServer name to remove

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorsNo
outputNo

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. While 'Remove a server' implies a destructive action, it fails to mention any side effects, such as permanent deletion, disconnection, or cleanup of associated resources. The output schema exists but is not referenced, leaving the agent unaware of what response to expect.

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 extremely concise at just four words, with no wasted text. It is front-loaded with the verb. However, it may be overly terse, missing important context that could be added without significant bloat.

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 performs a destructive removal operation with only one parameter and no annotations, the description is insufficient. It does not explain return values (despite an output schema existing), confirm requirements, or outline post-removal effects. The description leaves the agent underinformed for correct and safe usage.

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 coverage is 100% because the single parameter 'name' is described as 'Server name to remove'. The tool description adds no additional semantic information beyond what the input schema already provides, so a baseline score of 3 is appropriate.

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 'Remove' and the resource 'server', making its primary action immediately obvious. It effectively distinguishes from sibling tools like magg_add_server, magg_disable_server, and magg_enable_server, which perform different actions.

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 offers no guidance on when to use this tool versus alternatives. It does not specify prerequisites, such as whether the server should be disabled before removal, or context in which removal is appropriate. This lack of usage direction may lead to incorrect invocation.

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

magg_search_serversC

Search for MCP servers online.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of results to return per search source
queryYesSearch query for MCP servers

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorsNo
outputNo

TDQS

C2.9/5.0
Behavior2/5

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

With no annotations, the description bears full burden. It only states 'search online' without revealing behavior such as network requirements, result format, pagination, error handling, or limits. The output schema exists but is not referenced.

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 extremely concise with one sentence that efficiently conveys the core purpose. It is front-loaded but may be too terse, lacking context for effective use.

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 that output schema exists, return value explanation is not needed. However, the description omits critical context about search sources, result behavior, and how this differs from sibling tools, leaving the agent underinformed.

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 coverage is 100%, so the schema already documents both parameters. The description adds no extra meaning beyond the schema, so baseline score of 3 is 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 tool searches for MCP servers online, specifying both the action and the resource. It differentiates from 'magg_list_servers' by implying external search, but could be more specific about the search scope.

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 'magg_list_servers' (listing known servers) or 'magg_add_server'. Missing context on appropriate search scenarios or search source defaults.

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

magg_smart_configureA

Use LLM sampling to intelligently configure and add a server from a URL.

This tool performs the complete workflow:

  1. Collects metadata about the source URL

  2. Uses LLM sampling (if context provided) to generate optimal configuration

  3. Automatically adds the server to your configuration

Note: This requires an LLM context for intelligent configuration. Without LLM context, it falls back to basic metadata-based heuristics. For generating configuration prompts without sampling, use configure_server_prompt.

ParametersJSON Schema
NameRequiredDescriptionDefault
sourceYesURL of the server package/repository
allow_addNoWhether to automatically add the server after configuration (default: False)
server_nameNoOptional server name (auto-generated if not provided)

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorsNo
outputNo

TDQS

A4.4/5.0
Behavior4/5

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

The description outlines the three-step workflow (metadata collection, LLM-based config generation, auto-add) and notes the fallback heuristic, but does not explicitly detail side effects beyond 'automatically adds the server.' Given no annotations, this is adequate but could be more explicit about mutability.

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, front-loaded with main purpose, and structured with steps and a note. Every sentence adds value without 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?

The description covers the workflow, fallback, and alternative tool, but slightly misstates 'automatically adds' when the default allow_add is false, causing a minor completeness gap. Output schema exists, so return values are not needed.

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 coverage is 100%, so baseline is 3. The description adds no extra parameter details beyond the schema, thus meets the minimum but no bonus.

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 uses LLM sampling to intelligently configure and add a server from a URL, distinguishing it from sibling tools like configure_server_prompt (explicitly mentioned) and others in the list.

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 explicitly specifies when to use (with LLM context for intelligent config), when to avoid (fallback to heuristics without context), and suggests an alternative (configure_server_prompt for generating prompts without sampling).

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

magg_statusB

Get basic Magg server status and statistics.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorsNo
outputNo

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are present, so the description bears full responsibility for behavioral disclosure. It only states the tool gets status, but does not mention any other behavioral traits such as authentication requirements or rate limits. The read-only nature is implied but not explicit.

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, concise and front-loaded. It is efficient but could be slightly more informative without losing 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?

Given that there are no parameters and an output schema exists (though not provided), the description is reasonably complete for a simple status tool. It states the key purpose, and the output schema should cover return values.

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, and schema description coverage is 100% trivially. The baseline score for 0 parameters is 4, and the description adds no parameter information since none exist.

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 gets 'basic Magg server status and statistics', which is a specific verb+resource. It is distinguishable from siblings like magg_analyze_servers or magg_list_servers, though it does not explicitly differentiate.

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 magg_check or magg_analyze_servers. The description lacks usage context.

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

magg_unload_kitB

Unload a kit and optionally its servers from the configuration.

ParametersJSON Schema
NameRequiredDescriptionDefault
nameYesKit name to unload

Output Schema

ParametersJSON Schema
NameRequiredDescription
errorsNo
outputNo

TDQS

B3.4/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden for behavioral disclosure. It indicates a destructive action (unloading from configuration) but does not disclose reversibility, permissions required, or what happens to the kit's servers beyond being optional. Insufficient for a mutation 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 a single concise sentence of 12 words, front-loaded with the main action. Every word earns its place; no redundancy.

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?

The tool has a simple input and output schema, but the description lacks context on what unloading entails, its effects, and when to use it given many sibling tools (e.g., magg_remove_server, magg_load_kit). More context would aid agent decision-making.

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 input schema covers the single parameter 'name' with a description, achieving 100% schema description coverage. The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.

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 unloads a kit and optionally its servers from configuration, with a clear verb and resource. It distinguishes from siblings like magg_load_kit (opposite) and magg_remove_server (different focus).

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 unloading a kit, but does not explicitly state when to use this tool versus alternatives (e.g., magg_remove_server for removing servers only). No when-not or alternative guidance is provided.

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

proxyA

Main proxy tool for dynamic access to mounted MCP servers.

This tool provides a unified interface for:

  • Listing available tools, resources, or prompts across servers

  • Getting detailed info about specific capabilities

  • Calling tools, reading resources, or getting prompts

Annotations are used to provide rich type information for results, which can generally be expected to ultimately include JSON-encoded EmbeddedResource results that can be interpreted by the client.

ParametersJSON Schema
NameRequiredDescriptionDefault
argsNoArguments for a 'call' action (call tool, read resource, or get prompt). Can be a dict or JSON string.
pathNoName or URI of the specific tool/resource/prompt (with FastMCP prefixing). Not allowed for 'list' and 'info' actions.
typeYesType of MCP capability to interact with: tool, resource, or prompt.
limitNoMaximum number of items to return (for 'list' action only). Default: 100
actionYesAction to perform: list, info, or call.
offsetNoNumber of items to skip (for 'list' action only). Default: 0
filter_serverNoFilter results by server name prefix (for 'list' action only)

TDQS

A3.8/5.0
Behavior2/5

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

No annotations are provided, and the description only mentions that results include JSON-encoded EmbeddedResource results, without disclosing behavioral traits like read-only/destructive nature, authentication needs, or side effects.

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, front-loading the main purpose and using bullet points for clarity, with no superfluous information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a proxy tool with multiple actions and types, the description provides moderate completeness: it explains the unified interface and hints at return types. However, it lacks details on pagination, error handling, or result structure beyond JSON encoding.

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 descriptions cover 100% of parameters, so baseline is 3. The description does not add significant meaning beyond what the schema provides, repeating parameter types and actions without new context.

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 it is a main proxy tool for dynamic access to mounted MCP servers, listing specific actions (list, info, call) and types (tool, resource, prompt). It distinguishes from sibling tools which are for server management.

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 unified interface for interacting with MCP capabilities, implying usage for accessing tools/resources/prompts. It does not explicitly state when not to use or alternatives, but siblings are clearly different in purpose.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. 16 tool updatesv1.1.0
    • Changedmagg_add_server14 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • removedInput schema / properties / command / title
        Removed value: -"Command"
      • removedInput schema / properties / cwd / title
        Removed value: -"Cwd"
      • removedInput schema / properties / enable / title
        Removed value: -"Enable"
      • removedInput schema / properties / env / title
        Removed value: -"Env"
      • removedInput schema / properties / name / title
        Removed value: -"Name"
      • removedInput schema / properties / notes / title
        Removed value: -"Notes"
      • removedInput schema / properties / prefix / title
        Removed value: -"Prefix"
      • removedInput schema / properties / source / title
        Removed value: -"Source"
      • removedInput schema / properties / transport / title
        Removed value: -"Transport"
      • removedInput schema / properties / uri / title
        Removed value: -"Uri"
      • removedOutput schema / properties / errors / title
        Removed value: -"Errors"
      • removedOutput schema / properties / output / title
        Removed value: -"Output"
      • removedOutput schema / title
        Removed value: -"MaggResponse"
    • Changedmagg_analyze_servers1 field changed
      • addedInput schema / additionalProperties
        Added value: +false
    • Changedmagg_check6 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • removedInput schema / properties / action / title
        Removed value: -"Action"
      • removedInput schema / properties / timeout / title
        Removed value: -"Timeout"
      • removedOutput schema / properties / errors / title
        Removed value: -"Errors"
      • removedOutput schema / properties / output / title
        Removed value: -"Output"
      • removedOutput schema / title
        Removed value: -"MaggResponse"
    • Changedmagg_disable_server5 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • removedInput schema / properties / name / title
        Removed value: -"Name"
      • removedOutput schema / properties / errors / title
        Removed value: -"Errors"
      • removedOutput schema / properties / output / title
        Removed value: -"Output"
      • removedOutput schema / title
        Removed value: -"MaggResponse"
    • Changedmagg_enable_server5 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • removedInput schema / properties / name / title
        Removed value: -"Name"
      • removedOutput schema / properties / errors / title
        Removed value: -"Errors"
      • removedOutput schema / properties / output / title
        Removed value: -"Output"
      • removedOutput schema / title
        Removed value: -"MaggResponse"
    • Changedmagg_kit_info5 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • removedInput schema / properties / name / title
        Removed value: -"Name"
      • removedOutput schema / properties / errors / title
        Removed value: -"Errors"
      • removedOutput schema / properties / output / title
        Removed value: -"Output"
      • removedOutput schema / title
        Removed value: -"MaggResponse"
    • Changedmagg_list_kits4 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • removedOutput schema / properties / errors / title
        Removed value: -"Errors"
      • removedOutput schema / properties / output / title
        Removed value: -"Output"
      • removedOutput schema / title
        Removed value: -"MaggResponse"
    • Changedmagg_list_servers4 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • removedOutput schema / properties / errors / title
        Removed value: -"Errors"
      • removedOutput schema / properties / output / title
        Removed value: -"Output"
      • removedOutput schema / title
        Removed value: -"MaggResponse"
    • Changedmagg_load_kit5 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • removedInput schema / properties / name / title
        Removed value: -"Name"
      • removedOutput schema / properties / errors / title
        Removed value: -"Errors"
      • removedOutput schema / properties / output / title
        Removed value: -"Output"
      • removedOutput schema / title
        Removed value: -"MaggResponse"
    • Changedmagg_reload_config4 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • removedOutput schema / properties / errors / title
        Removed value: -"Errors"
      • removedOutput schema / properties / output / title
        Removed value: -"Output"
      • removedOutput schema / title
        Removed value: -"MaggResponse"
    • Changedmagg_remove_server5 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • removedInput schema / properties / name / title
        Removed value: -"Name"
      • removedOutput schema / properties / errors / title
        Removed value: -"Errors"
      • removedOutput schema / properties / output / title
        Removed value: -"Output"
      • removedOutput schema / title
        Removed value: -"MaggResponse"
    • Changedmagg_search_servers6 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • removedInput schema / properties / limit / title
        Removed value: -"Limit"
      • removedInput schema / properties / query / title
        Removed value: -"Query"
      • removedOutput schema / properties / errors / title
        Removed value: -"Errors"
      • removedOutput schema / properties / output / title
        Removed value: -"Output"
      • removedOutput schema / title
        Removed value: -"MaggResponse"
    • Changedmagg_smart_configure7 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • removedInput schema / properties / allow_add / title
        Removed value: -"Allow Add"
      • removedInput schema / properties / server_name / title
        Removed value: -"Server Name"
      • removedInput schema / properties / source / title
        Removed value: -"Source"
      • removedOutput schema / properties / errors / title
        Removed value: -"Errors"
      • removedOutput schema / properties / output / title
        Removed value: -"Output"
      • removedOutput schema / title
        Removed value: -"MaggResponse"
    • Changedmagg_status4 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • removedOutput schema / properties / errors / title
        Removed value: -"Errors"
      • removedOutput schema / properties / output / title
        Removed value: -"Output"
      • removedOutput schema / title
        Removed value: -"MaggResponse"
    • Changedmagg_unload_kit5 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • removedInput schema / properties / name / title
        Removed value: -"Name"
      • removedOutput schema / properties / errors / title
        Removed value: -"Errors"
      • removedOutput schema / properties / output / title
        Removed value: -"Output"
      • removedOutput schema / title
        Removed value: -"MaggResponse"
    • Changedproxy8 fields changed
      • addedInput schema / additionalProperties
        Added value: +false
      • removedInput schema / properties / action / title
        Removed value: -"Action"
      • removedInput schema / properties / args / title
        Removed value: -"Args"
      • removedInput schema / properties / filter_server / title
        Removed value: -"Filter Server"
      • removedInput schema / properties / limit / title
        Removed value: -"Limit"
      • removedInput schema / properties / offset / title
        Removed value: -"Offset"
      • removedInput schema / properties / path / title
        Removed value: -"Path"
      • removedInput schema / properties / type / title
        Removed value: -"Type"
  2. 16 tool updatesv1.0.0
    • First observedmagg_add_server
    • First observedmagg_analyze_servers
    • First observedmagg_check
    • First observedmagg_disable_server
    • First observedmagg_enable_server
    • First observedmagg_kit_info
    • First observedmagg_list_kits
    • First observedmagg_list_servers
    • First observedmagg_load_kit
    • First observedmagg_reload_config
    • First observedmagg_remove_server
    • First observedmagg_search_servers
    • First observedmagg_smart_configure
    • First observedmagg_status
    • First observedmagg_unload_kit
    • First observedproxy
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.5/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose, with detailed descriptions that prevent ambiguity. Even similar-sounding tools like magg_add_server and magg_smart_configure are well-differentiated by their methods.

Naming Consistency4/5

Most tools follow a magg_verb_noun pattern (e.g., add_server, list_servers), but there are minor deviations: 'proxy' lacks the prefix, 'magg_check' is a single verb, and 'magg_status' is a noun. Overall, the naming is still predictable and readable.

Tool Count5/5

16 tools cover a comprehensive range of server and kit management operations without being excessive. Each tool serves a necessary function, making the count ideal for the server's scope.

Completeness4/5

The tool set covers core CRUD operations for servers and kits, plus health checks, analysis, online search, smart configuration, and dynamic access via proxy. Minor gaps like explicit server editing tools are absent but manageable via config reload.

Maintenance

ActivityMaintained
ResponsivenessSyncing

Resources

Related MCP Connectors

Related MCP Servers

  • MCP-MCP

    wojtyniak
    A
    license
    A
    quality
    B
    maintenance
    A Meta-MCP Server that acts as a tool discovery service, helping AI assistants find appropriate MCP servers from a database of 800+ servers when they need capabilities that aren't currently available.
    1
    23
    MIT

  • InfiniteMCP

    day50-dev
    F
    license
    Not graded
    quality
    D
    maintenance
    A meta-MCP server that acts as a universal gateway, allowing users to discover and execute tools from thousands of other MCP servers through semantic search. It dynamically loads servers on demand and provides standardized functions for searching, discovering, and running tools across the entire MCP ecosystem.
    6
    -

Appeared in Searches

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/sitbon/magg'

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