Spaceship MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.5
Disambiguation5/5
All tools have clearly distinct purposes: create vs delete vs get vs list for agents, orchestrations, etc. Even similar tools like get_run_logs and get_run_status target different aspects of runs (logs vs status). test_agent and run_agent differ in synchronous vs asynchronous execution. No ambiguity.
Naming Consistency5/5
All tool names consistently follow the verb_noun pattern with underscores (e.g., create_agent, get_run_status, list_projects). No mixing of camelCase or other styles. Very predictable.
Tool Count5/5
16 tools is appropriate for a platform managing agents and orchestrations. It covers essential operations without being overwhelming. Each tool earns its place.
Completeness4/5
The tool set covers agent lifecycle (CRUD), run management (run, test, status, logs), orchestration operations (list, get, run, test), and listing of projects/tools. Missing delete/update for orchestrations and projects, but those may be out of scope. Minor gaps, but core workflows are complete.
Average 4.2/5 across 16 of 16 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states that it returns id, name, and slug, which is helpful but does not disclose additional behavioral traits such as read-only nature, pagination, or authorization requirements beyond 'authenticated organization.'
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 concise and front-loaded, with the purpose in the first sentence. It is efficient but could be slightly tighter by removing the second sentence's redundancy (e.g., the output format is implied by the mention of fields).
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 there is an output schema, the description need not fully explain return values, but it does briefly. However, it lacks completeness in areas like pagination, ordering, or any side effects. It is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, meaning no parameters are described in the description. There is one optional parameter (limit with default 50) that is not mentioned. Since coverage is low and the description does not compensate, the score is below baseline.
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 'List all projects in the authenticated organization,' which is a specific verb+resource. However, it does not explicitly distinguish from sibling list tools like list_agents, though the context is clear.
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 usage guidance: 'Use this to discover which projects exist before listing or creating agents.' This gives context on when to use the tool, but does not mention when not to use it or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits. It mentions that each orchestration includes its members and attached tools, which is helpful. However, it does not disclose pagination behavior, ordering, rate limits, or the fact that limit parameter exists but is not described.
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 concise with two short paragraphs. The first sentence gives the core purpose, the second explains the main parameter. No unnecessary words, but could be slightly more structured.
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 presence of an output schema (unknown content) and two parameters, the description should cover both parameters and typical list behavior. It only covers project_id, missing limit and any mention of output details or pagination.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description should explain all parameters. It explains project_id and its source, but the limit parameter (default 50) is not mentioned at all. This is a significant gap.
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 'List orchestrations in the organization, optionally filtered by project.' This is a specific verb and resource, and it distinguishes from sibling tools like list_agents or list_projects.
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 when to use the project_id parameter ('to scope results to a single project') and references list_projects. It does not explicitly state when not to use the tool or mention alternatives, but for a list tool with no alternative for this resource, it is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially discloses behavior: it mentions 'scaffold_applied: true' in response and that at least one of description/prompt is recommended. However, it does not discuss idempotency, error cases, or side effects like permanent creation.
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 front-loaded with the purpose, then explains key features, and uses a clean Args list. Every sentence adds value, though it is slightly longer than necessary.
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?
For a create tool with 6 parameters and no output schema, the description covers creation flow, parameter relationships, and a response hint (scaffold_applied). Missing details like return format or error handling, but still solid.
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?
Schema coverage is 0% (only titles provided), but the description adds detailed meaning: explains the difference between description and prompt, that tools are UUIDs from list_tools, and defaults like framework='langchain'. This compensates well for the schema gap.
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 'Create a new agent' with the verb 'create' and resource 'agent'. It distinguishes from siblings like update_agent and delete_agent through the specific action.
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 explains the two modes for system prompt (description vs. prompt) but does not explicitly state when to use this tool versus update_agent or other siblings. Usage context is implied but not compared directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behaviors: it starts a run, polls every 2 seconds, has a 90-second timeout, reports progress via notifications, and returns status and execution_id. It lacks explicit safety or side-effect details (e.g., whether it modifies state), but the core behavior is well-covered.
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 with no unnecessary words. It uses a clear structure: one-line summary, behavior paragraph, then arg list. Every sentence adds value, making it highly efficient.
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 no output schema, the description covers return value (final status and execution_id). It also explains polling, timeout, and notifications. It does not address error scenarios or preconditions, but for a test tool, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It explains orchestration_id as a UUID and input_data as optional, but omits any explanation for ctx, leaving one of three parameters undocumented. This incomplete compensation lowers the score.
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 explicitly states 'Quick synchronous test of an orchestration', using a specific verb (test) and resource (orchestration). It further details behavior (polling, timeout, notifications) that distinguishes it from sibling tools like run_orchestration, which likely lacks such synchronous testing features.
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 quick synchronous tests with a 90-second timeout, but does not explicitly state when to use this tool versus alternatives like run_orchestration, nor does it provide clear when-not-to-use guidance or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. The description implies read-only operation (listing runs) without stating non-destructiveness explicitly. It does not mention authentication needs, rate limits, or side effects, but the read-only nature is reasonably inferred.
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 concise with three short sections. It front-loads the purpose, adds usage context, and lists parameter details without superfluous text. However, it could be more structured (e.g., bullet points for Args) to improve readability.
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 an output schema exists, the description does not need to explain return values. It covers purpose, usage, and parameters adequately for an agent to use the tool correctly. Minor gap: no mention of sorting or time range, but 'recent runs' implies recency.
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?
Schema coverage is 0%, so the description compensates by explaining both parameters: 'agent_id: The agent's UUID' and 'limit: Number of runs to return (default 10, max 50).' This adds meaning beyond the schema, which only provides titles and types.
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 explicitly states 'List recent runs for an agent with their status and duration.' It uses a specific verb (list) and resource (runs), and differentiates from sibling list tools like list_agents and list_orchestrations by focusing on agent executions.
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 clear context: 'Useful for reviewing run history or checking whether a previous run succeeded before starting a new one.' It explains when to use the tool but does not explicitly mention when not to use it or suggest alternatives, though sibling names imply the distinctions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns full details including tools and system prompt, indicating it is a read operation with no side effects. Additional details like error handling or permissions are absent, but the description is adequate for a simple get.
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 two lines plus an 'Args:' block, concise and front-loaded with the main purpose. 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?
For a simple get operation with one parameter, the description covers the essentials. It mentions what is returned (full details including tools and system prompt), compensating for the lack of an output schema. No critical 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?
The only parameter, agent_id, has no description in the schema (0% coverage). However, the description adds: 'The agent's UUID (from list_agents or create_agent),' which clarifies its type and source, adding value beyond the schema.
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 states 'Get full details of a single agent including its tools and system prompt,' clearly indicating the verb and resource, and specifies what details are included. This distinguishes it from siblings like list_agents (list) and update_agent (modify).
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 implies use when full details of a specific agent are needed and provides context for the agent_id source ('from list_agents or create_agent'). It does not explicitly state when not to use, but the purpose is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It mentions output includes tools and configuration, adding behavior beyond schema. However, does not explicitly state read-only nature, auth needs, or rate limits.
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?
Three concise sentences: purpose, parameter usage, output content. No fluff, each sentence adds value.
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?
For a simple list tool with 2 params and output schema present, description covers purpose, one parameter detail, and output content. Lacks pagination info for limit, but default provided. Adequate for the task.
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?
Schema has 0% description coverage. Description adds meaning for project_id: UUID from list_projects. Does not describe limit parameter beyond default value, but overall partially compensates for low schema coverage.
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 'List agents in the organization, optionally filtered by project.' Verb 'list', resource 'agents', scope 'organization', optional filter. Distinguishes from sibling CRUD tools like create_agent or get_agent.
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 for project_id parameter (UUID from list_projects) and filtering usage. Does not explicitly state when not to use or compare to alternatives, but usage is implied for listing agents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must cover behavioral traits. It mentions what is returned (built-in and custom tools) but lacks details on authentication, rate limits, or data freshness. Adequate for a simple read-only list.
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 effectively convey the tool's purpose and usage. 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 no parameters and an output schema (mentioned in context signals), the description covers the essentials. It could optionally mention authentication or result structure but is complete enough for a 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 in the input schema, so baseline is 4. The description adds no parameter info, which is acceptable as there are none to document.
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 lists tools available to attach to agents, distinguishing between built-in and custom tools. It also mentions the uuid field's usage, adding context.
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 when to use the tool (for attaching tools to agents) and provides guidance on using the uuid field. It does not explicitly exclude alternatives but is sufficient for basic use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses synchronous polling behavior, 2-second interval, MCP notifications, timeout, and return fields. However, lacks explanation of the 'ctx' parameter and does not explicitly state whether the tool is read-only or has side effects, though it is implied to be non-destructive.
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?
Concisely structured: first sentence states purpose, then explains mechanics and usage, followed by arguments. Every sentence adds value with no unnecessary words.
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?
Provides sufficient context for a test tool: describes behavior, timeout, polling, notifications, and links to sibling tools for production use and logs. Missing details on returned status format, but overall complete given the tool's scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the purpose of agent_id and prompt, but the required 'ctx' parameter is completely undocumented in the description. With 0% schema coverage, the description should cover all parameters, and this omission reduces utility for the agent.
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 the tool is a quick synchronous test of an agent with a 90-second timeout, distinguishing it from production alternatives like run_agent. It specifies the verb 'test' and resource 'agent', and advises using get_run_logs afterwards.
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?
Explicitly states when to use (quick synchronous test) and when not (production, prefer run_agent + get_run_status). Also suggests using get_run_logs for output, providing clear guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explicitly states the action is permanent and irreversible, and lists what gets deleted (logs, memories, threads), providing excellent transparency.
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 very concise with a front-loaded warning about permanence, followed by the parameter. Every sentence is necessary and adds value.
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 essential aspects: irreversibility, affected data, and parameter. For a simple delete tool, it is complete, though it could mention any prerequisites.
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 0%, but only one parameter. The description adds 'The agent's UUID' beyond the schema's 'Agent Id' title, which is helpful but minimal. It does not fully compensate for low coverage.
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 permanently deletes an agent and all associated data (logs, memories, threads). This distinguishes it from sibling tools like create_agent, get_agent, and update_agent.
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?
It advises to double-check the agent_id, implying careful use, but does not explicitly state when to use or mention alternatives. The caution is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It implies a read-only operation ('Get full details') and mentions no side effects, which is appropriate for a GET tool. No contradictions exist.
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 two sentences plus an args section, front-loading the purpose and providing parameter details. 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?
Given no output schema and no annotations, the description covers the main purpose and parameter. Mention of 'members and tools' gives sufficient detail for a get operation, though 'full details' is somewhat vague.
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?
Schema coverage is 0%, so the description compensates by documenting the parameter: 'orchestration_id: The orchestration's UUID (from list_orchestrations).' This adds type and source context beyond the schema.
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 'Get' and the resource 'full details of a single orchestration including its members and tools.' It distinguishes from sibling tools like list_orchestrations (which lists) and run_orchestration (which executes).
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 notes that orchestration_id comes from list_orchestrations, providing a source for the parameter. However, it lacks explicit guidance on when to use this tool over alternatives, such as when detailed info is needed versus a summary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description details return content (every event type) and purpose. Doesn't mention auth or limits, but sufficient for read operation.
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?
Three focused sentences plus Args section. Efficient use of words with clear structure.
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?
Covers purpose, return content, and parameter origins. Output schema exists, so detailed return spec not needed. Could mention truncation but not critical.
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?
Schema only provides titles; description adds meaning: agent_id is UUID, execution_id is from run_agent. Good compensation for 0% schema coverage.
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 'Fetch the full event log for a completed run in chronological order' with specific verb and resource. It elaborates on the types of events included, distinguishing it from get_run_status.
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?
Implicitly indicates usage for completed runs, contrasting with status tools. No explicit when-not or alternative names, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior. It covers the polling nature, status sequence, and timing expectations. However, it does not mention error handling (e.g., what happens if run not found) or rate limits, leaving some gaps.
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: 5 lines total, starting with a clear purpose, followed by status list, polling advice, and parameter docs. No superfluous text, well-organized.
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 no output schema, the return value (status) is implied but not explicitly described. The description covers usage context and parameters well. It could mention the response format (e.g., a status string) but is sufficient for a polling tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description provides explicit meanings for both parameters: 'agent_id: The agent's UUID' and 'execution_id: The execution UUID returned by run_agent'. This fully compensates for the schema's lack of descriptions.
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 'Poll the status of a specific run' and enumerates status transitions. It distinguishes itself from siblings like list_executions (which lists runs) and run_agent (which starts a run) by being a targeted polling tool for a single run.
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 advises to poll every 3-5 seconds and notes typical completion times (30-60 seconds), providing practical usage guidance. It does not explicitly exclude use cases (e.g., non-existent runs) but is adequate for typical polling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It transparently states the asynchronous behavior and the immediate return of an execution_id. It does not, however, detail error conditions or side effects (e.g., if agent_id is invalid), but it covers the essential behavioral aspects.
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 and well-structured. It begins with a clear summary, then provides a note about the execution_id and follow-up tools, followed by a bullet-style Args section. Every sentence adds value with no 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?
Given there is no output schema, the description explains the return of an execution_id and references sibling tools for further operations. It covers all parameters and the async nature. It could mention error handling or validation but is largely complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully explains each parameter: agent_id (UUID), prompt (user message), thread_id (memory continuity), and params (optional extra parameters). This adds significant meaning beyond the input schema's minimal titles.
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 starts an asynchronous agent run and returns immediately. The verb 'Start' and resource 'agent run' are specific, and it distinguishes itself from sibling tools like 'get_run_status' and 'get_run_logs' by indicating their purpose for follow-up.
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 tells you when to use this tool (to start an agent run) and what to use next (get_run_status for polling, get_run_logs for output). However, it does not explicitly state when not to use it, such as when a synchronous run is needed or when the agent doesn't exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description discloses key behaviors: description re-runs scaffolding, prompt sets directly, tools are fully replaced. It lacks details on permissions, atomicity, or immediate effect, but is sufficient 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 concise: a one-line summary followed by clear bullet-like parameter explanations. Every sentence adds value, and the structure is front-loaded.
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 all parameters and their behavioral traits. However, it lacks information about the return value (no output schema) and does not mention error conditions or side effects on ongoing runs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the raw schema by explaining the effect of each parameter (e.g., 'triggers re-scaffolding', 'replacement list'). This compensates for the 0% schema description coverage.
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 updates an agent's name, prompt, or tools, with specific verb and resource. It distinguishes from sibling tools like create_agent (creation) and delete_agent (deletion).
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 when to use each parameter (e.g., description triggers re-scaffolding, prompt sets directly, tools replaces list). However, it does not explicitly state when not to use this tool or contrast with alternatives beyond the parameter behaviors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description covers key behaviors: async execution, immediate return, and how to retrieve results. Lacks explicit mention of side effects or idempotency, but is overall 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?
Concise, well-structured with a clear summary line and Args section. No redundancy, every sentence adds value.
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 tool with 3 parameters and no output schema, the description covers purpose, async behavior, return value, and how to monitor progress. Complete and actionable.
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?
Schema has 0% description coverage, but the description adds meaning: explains orchestration_id as UUID, input_data with example, and params as optional. Compensates well for schema gaps.
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 starts an asynchronous orchestration run and returns immediately. It distinguishes from sibling 'test_orchestration' which blocks, and specifies the returned execution_id.
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?
Explicitly mentions when to use this tool (for async runs) and provides alternatives: 'test_orchestration' for blocking or polling '/executions' for status updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![spaceship-mcp MCP server](https://glama.ai/mcp/servers/Spaceship-AI/spaceship-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Spaceship-AI/spaceship-mcp)

Score Badge

Copy to your README.md:

[![spaceship-mcp MCP server](https://glama.ai/mcp/servers/Spaceship-AI/spaceship-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Spaceship-AI/spaceship-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/Spaceship-AI/spaceship-mcp'

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