MCP Serverman has 11 tools with complete input schemas and descriptions present for all. However, descriptions are moderately detailed (80-200 chars average) rather than LLM-optimized, and output schemas are not explicitly documented. Parameter descriptions are present but generic in places. Error handling returns plain text strings rather than structured guidance. Tool naming is clear and verb-first (list_, enable_, disable_, save_, load_, set_), which is strong. However, there are no return type specifications visible, parameter constraints (enums, ranges) are missing where applicable, and error responses lack actionable recovery guidance. No parameter type validation constraints (min/max, enum options, format specs) are documented. The server manages MCP server configurations but exposes operational tools that could benefit from stricter input validation and richer error messages.
Disable a specified server. The optional 'client' parameter uses the default client if not specified.
Bulk disable servers given an array of server names. The optional 'client' parameter uses the default client if not specified.
Enable a specified server. If version is not provided, version 1 will be used. The optional 'client' parameter uses the default client if not specified.
Bulk enable servers given an array of server names. If version is not provided, defaults to 1. The optional 'client' parameter uses the default client if not specified.
List all registered clients.
List all available versions for the given server. Returns a dictionary with the server name and a list of versions. If no state is ever saved, the list will be empty. Each version includes its index, hash, timestamp, comment, and config content. The optional 'client' parameter uses the default client if not specified.
Output schemas not documented. Tools return dicts/strings but no explicit schema specification visible in code or tool registration. LLMs cannot predict return fields for planning downstream calls.
Error responses are unstructured plain-text strings (e.g., 'Error enabling server: ...') with no recovery guidance. LLMs cannot determine if errors are retryable, user-fixable, or fatal.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 54 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 49 | - | v1 |
List all servers (enabled and disabled). The optional 'client' parameter uses the default client if not specified.
Load a profile (preset) into the current configuration. The optional 'client' parameter uses the default client if not specified.
Save the current configuration as a profile (preset) under the given name. The optional 'client' parameter uses the default client if not specified.
Save the current state of a server. The optional 'client' parameter uses the default client if not specified.
Set the specified client as the default client.
'version' parameter in enable_server and enable_servers lacks numeric constraints (range, default behavior when null). Description says 'defaults to 1' but no min/max bounds. LLM could pass invalid values.
bulk operations (enable_servers, disable_servers) return mixed success/failure results as dicts, but inconsistent response structure. enable_servers wraps dict in a string message; disable_servers returns raw dict. Agents cannot reliably parse per-item success/failure.
No idempotency guarantees or confirmations for destructive operations. disable_server, disable_servers, and load_profile modify state but lack dry-run or confirmation steps. Agents should be asked before destructive actions.
'server_name' and 'profile_name' parameters accept free-form strings with no validation hints (length, charset, reserved names). Description lacks 'expected format' guidance. LLM could pass invalid names.
list_server_versions description is detailed but output schema incomplete. Returns 'version_list' with nested fields (index, hash, timestamp, comment, config_content) but LLM cannot see the full structure or field types.
'client' parameter is optional and uses a default if not specified, but no documentation on how the default is chosen or what happens if no default is set. Agents need to understand fallback behavior.