Loading ToolBench
MCP server for Spaceship AI — manage agents from Claude Code and other MCP clients
14 tools with complete schemas and descriptions. Naming follows verb_noun pattern consistently (list_, get_, create_, update_, delete_, run_). Descriptions are detailed (100-250 chars typical) and explain WHEN to use each tool. However, output schemas are not documented, LLMs cannot predict response structure. Parameter descriptions are present but lack format constraints (enums, ranges, patterns). No error handling guidance. Risk annotations (READ_ONLY, WRITE, DESTRUCTIVE) are present in metadata but not exposed in tool definitions. Missing idempotency guidance for retry-heavy operations like run_agent + polling.
Create a new agent. Pass ``description`` to let the server auto-generate a detailed system prompt (``scaffold_applied: true`` in the response). Pass ``prompt`` to set the system prompt directly. At least one of description or prompt is recommended.
PERMANENTLY delete an agent and all its logs, memories, and threads. This action is irreversible. Double-check the agent_id before calling.
Get full details of a single agent including its tools and system prompt.
Get full details of a single orchestration including its members and tools.
Fetch the full event log for a completed run in chronological order. Returns every event (start, tool_call, memory_access, completion, error, …) so you can see exactly what the agent did and what it returned.
Output schemas not documented. LLMs cannot predict response structure (fields, types, nested objects). Forces agents to guess what data is available after each call.
Parameter constraints missing. 'limit' params lack min/max bounds (e.g., limit: 1 - 50). 'framework' in create_agent lacks enum (only 'langchain' shown). LLMs may pass invalid values.
No error recovery guidance. Descriptions do not explain what to do if a call fails (e.g., 'agent not found' → try list_agents; 'execution timeout' → retry with get_run_status). Agents left guessing.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Poll the status of a specific run. Status values: ``queued`` → ``running`` → ``completed`` | ``error`` | ``cancelled`` | ``paused`` (waiting for approval). Poll every 3-5 seconds. Most agents complete within 30-60 seconds.
List agents in the organization, optionally filtered by project. Pass ``project_id`` (UUID from list_projects) to scope the results to a single project. Each agent record includes its tools and configuration.
List recent runs for an agent with their status and duration. Useful for reviewing run history or checking whether a previous run succeeded before starting a new one.
List orchestrations in the organization, optionally filtered by project. Pass ``project_id`` (UUID from list_projects) to scope results to a single project. Each orchestration includes its members and their attached tools.
List all projects in the authenticated organization. Use this to discover which projects exist before listing or creating agents. Returns each project's id, name, and slug.
Start an asynchronous agent run and return immediately. Returns an ``execution_id`` — use ``get_run_status`` to poll for completion or ``get_run_logs`` to fetch the full output once done.
Start an asynchronous orchestration run and return immediately. Returns an ``execution_id`` — use ``test_orchestration`` to block until completion or poll ``/executions`` for status updates.
Quick synchronous test of an agent with a 90-second timeout. Starts a run and polls every 2 seconds until it completes (or times out). Reports progress via MCP notifications while waiting. Returns the final status and execution_id. Use ``get_run_logs`` afterwards to see the output. For production usage, prefer ``run_agent`` + ``get_run_status`` (non-blocking).
Update an agent's name, prompt, or tools. Providing ``description`` re-runs server-side prompt scaffolding and overwrites the current system prompt. Providing ``prompt`` sets it directly. Providing ``tools`` replaces the full tool list.
Destructive operations lack confirmation pattern. delete_agent is irreversible but has no dry-run or confirmation step. Agents can permanently delete without safeguard.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) present in metadata but not exposed in MCP tool definitions. LLMs cannot see risk classification.