Loading ToolBench
Wisp Panel MCP server for secure game server management through the Wisp Client API
Wisp MCP demonstrates solid definition quality with 23 well-named tools following verb_noun conventions (list_servers, read_file, safe_write_file). All tools have descriptions (avg ~120 chars, within 10-1024 range). Input schemas are present with type definitions and parameter descriptions. Tool annotations are correctly implemented (_READ_ONLY, _ADDITIVE, _IDEMPOTENT_WRITE, _DESTRUCTIVE) matching risk levels. Key strengths: clear action verbs, pagination support (page/per_page with min/max constraints), SHA-256 fingerprinting for safe writes, and comprehensive parameter descriptions. Weaknesses: output schemas are not explicitly documented in the code (only inferred from API responses); some parameter descriptions could be more prescriptive about format/constraints; error handling guidance is minimal in tool descriptions.
Read one page of Wisp audit events for a server. Use to investigate recent panel actions or changes; page and per_page control pagination and no state is modified.
Read metadata for one backup without downloading it. Use for size, date, or completion status checks.
Inspect which Wisp operation classes are enabled before choosing a management tool. Returns configuration flags and the default server ID, but never API tokens or other secrets.
Request a new backup for one server. Use before risky changes; the backup is queued and may take time to complete.
Read metadata for one database without changing it. Use for host, port, or credential checks.
Delete a backup permanently. This is destructive and cannot be undone.
Output schemas not explicitly documented. Tool descriptions state what is returned (e.g., 'returns configuration flags', 'returns metadata') but JSON Schema output definitions are absent from code. LLMs cannot plan downstream tool calls without knowing response field names and types.
Error handling guidance missing from tool descriptions. Destructive tools (restore_backup, delete_backup, set_power_state) do not document recovery paths or confirmation requirements. Agents lack guidance on what to do if a call fails.
Parameter constraints under-specified in descriptions. 'action' parameter in set_power_state lists enum values (start, stop, restart, kill) but description does not explicitly state these are the only valid options. 'query' in find_in_file mentions 'regex pattern' but does not clarify regex dialect or escaping rules.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2026-07-28+ | v2 |
Search for text patterns in a file and return matching line numbers and context. Use to locate relevant sections before reading or editing.
Compute the SHA-256 fingerprint of a file without reading its full content. Use to verify file identity before or after edits.
List backups for one server. Use to discover backup IDs before restore or download operations; results are paginated.
List databases for one server. Use to discover database IDs before rotation or management operations; results are paginated.
List entries in one server directory without reading file contents. Use for filesystem discovery before read or write operations; results are paginated.
List Wisp servers visible to the configured API token. Use this to discover server IDs; results are paginated and can optionally include node, egg, or allocation metadata.
Read a text file and return its content plus fingerprint metadata. Use when the full file is needed; content is truncated at max_chars, so use read_file_chunk for controlled continuation.
Read a portion of a text file by byte offset. Use to continue reading after truncation or to access specific regions without loading the entire file.
Replace text in a file by pattern matching with SHA-256 verification. Use for targeted edits when you have a prior fingerprint and know the exact text to replace.
Restore a server from a backup. This is destructive and will overwrite the current server state.
Generate a new password for a database. Use to rotate credentials; the new password is returned and must be saved.
Write or create a text file with SHA-256 verification to prevent concurrent edits. Use for safe file updates when you have a prior fingerprint.
Send a console command to a running server. Use for in-game administration; the command is queued and executed asynchronously.
Read metadata for one Wisp server without changing it. Use for identity, allocation, feature, node, or egg details; omit server_id only when a default server is configured.
Read the current runtime state and resource usage for one server. Use for power state, CPU, memory, disk, network, and game-query checks; this performs no mutation.
Change the power state of a server: start, stop, restart, or kill. Use for server lifecycle management; state changes are asynchronous.
Update server configuration such as name, description, or resource limits. Use for server metadata changes.
Pagination result limits not documented. list_servers, list_directory, audit_logs, list_backups, list_databases accept per_page (1-25) but tool descriptions do not state total result count or next_cursor availability, making it unclear how to iterate large result sets.
Chaining IDs not guaranteed in responses. read_file returns content and fingerprint, but tool description does not confirm whether server_id is echoed back. If not, agents cannot reliably chain read_file → safe_write_file without re-parsing or storing state.