Magg

Overview Schema Source Related Servers Discussions Admin

magg_add_server

Add and configure a new MCP server in Magg by providing its name, source, and command or URI, so LLMs can extend their available tools dynamically.

Instructions

Add a new MCP server.

Input Schema

TableJSON Schema

Name	Required	Description
`cwd`	No	Working directory (for commands)
`env`	No	Environment variables (dict or JSON string)
`uri`	No	URI for HTTP servers
`name`	Yes	Unique server name
`notes`	No	Setup notes
`enable`	No	Whether to enable the server immediately (default: True)
`prefix`	No	Tool prefix (default: none, tools keep their original names)
`source`	Yes	URL of the server package/repository
`command`	No	Full command to run (e.g., 'python server.py', 'npx @playwright/mcp@latest')
`transport`	No	Transport-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

TableJSON Schema

Name	Required	Description	Default
`errors`	No
`output`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv1.3.0Sep 28, 2026

changedInput schema / properties / prefix / description

Previous value: -"Tool prefix (defaults to conformed server name)"New value: +"Tool prefix (default: none, tools keep their original names)"

Changed14 schema fields changedv1.1.0Jun 29, 2026
- 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"
```
First observedv1.0.0Aug 15, 2025

TDQS

C2.8/5.0

Behavior2/5

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

With no annotations provided, the description carries the full behavioral burden, yet it says nothing about persistence, whether the server is persisted to config, whether a reload is required for the change to take effect, or any failure modes. The presence of sibling magg_reload_config hints at a non-obvious post-step the description should disclose but does not.

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?

It is a single front-loaded sentence with zero waste, which is structurally clean. However, at this brevity it reads as under-specification rather than genuine conciseness, given the tool's complexity.

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

Completeness2/5

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

For a 10-parameter mutation tool with distinct server modes (command-based vs uri-based) and a conditional transport config, a one-line description is inadequate. An output schema exists so return values need not be explained, but the description omits which parameter combinations are valid for which server type — a major gap.

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 documents all ten parameters, including the detailed transport options and the required name/source fields. The description adds no parameter meaning beyond that, so the baseline of 3 applies.

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

Purpose4/5

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

The description states a clear verb and resource ('Add a new MCP server'), which an agent can distinguish from siblings like magg_remove_server and magg_list_servers. However, it offers no differentiation beyond the obvious CRUD contrast and does not clarify scope relative to magg_load_kit or magg_smart_configure.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives, no mention of prerequisites, and no note that a config reload (magg_reload_config) may be needed afterward. The agent must infer all usage context from the name alone.

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

Deploy Server