Orgo MCP Server

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

Annotations provide readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false. The description adds valuable context beyond annotations: it explains the fire-and-forget nature, mentions hosted AI infrastructure, and details error handling (e.g., 'Resource not found', 'Insufficient credits'). However, it doesn't explicitly address rate limits or authentication beyond error messages, leaving some behavioral aspects implicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with clear sections (purpose, behavior, Args, Returns, Examples, Error Handling). It's appropriately sized for a complex tool, but could be more front-loaded; the core purpose is stated first, but some details like error handling are verbose. Every sentence adds value, with no wasted text.

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

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

Given the tool's complexity (asynchronous AI agent execution), rich annotations, and output schema, the description is highly complete. It covers purpose, usage, parameters, return format, examples, and error handling. The output schema exists, so the description appropriately focuses on contextual details rather than re-explaining return values, making it sufficient for effective agent use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 1 parameter (params) with 0% description coverage, but the description compensates by detailing the nested PromptInput structure in the Args section. It explains each field's purpose, defaults, and constraints (e.g., 'max_iterations: Max agent loops, 1-200 (default: 50)'), adding significant meaning beyond the schema's minimal descriptions. It doesn't fully explain all schema nuances like null handling, but provides substantial value.

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

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

The description clearly states the tool's purpose: 'Send an AI agent to complete a task on an Orgo computer (fire-and-forget).' It specifies the verb ('send'), resource ('AI agent'), and distinguishes it from siblings by emphasizing asynchronous execution and returning a progress URL, unlike tools like orgo_bash or orgo_click that perform immediate actions.

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

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

The description explicitly states when to use this tool: 'ideal for long-running tasks where you don't want to wait for completion.' It provides alternatives: 'Check progress at the returned URL or use orgo_screenshot.' The examples further clarify usage with vs. without computer_id, distinguishing it from sibling tools like orgo_create_computer.

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