Orgo MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have clearly distinct purposes, but some overlap exists (e.g., orgo_bash vs orgo_exec, orgo_download_file vs orgo_export_file). Descriptions are detailed enough to resolve confusion, but the large number of tools still requires careful reading.
Naming Consistency5/5
All tools follow a consistent orgo_verb_noun pattern using snake_case (e.g., orgo_create_computer, orgo_list_projects). The naming is predictable and uniform across the entire set.
Tool Count3/5
35 tools is significantly above the typical 3-15 range, but the broad domain (project/computer management, file operations, AI, streaming) justifies most tools. However, some tools could be consolidated (e.g., start/stop/restart per resource).
Completeness4/5
The tool surface covers CRUD for projects/computers, file operations, AI completions, streaming, and system interaction. Missing are update operations (e.g., update_computer, update_project) and possibly batch file actions, but core workflows are well-supported.
Average 4.2/5 across 35 of 35 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 6 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?
Annotations indicate this is not read-only, not open-world, not idempotent, and not destructive, but the description adds minimal behavioral context. It mentions the return value ('confirmation of scroll action'), which is useful since annotations don't cover output. However, it lacks details on side effects (e.g., page position changes), error conditions, or performance implications, leaving gaps in understanding the tool's behavior.
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 highly concise and well-structured: a brief purpose statement followed by organized Args and Returns sections. Every sentence adds value—no fluff or repetition. It's front-loaded with the core action, making it easy for an agent to quickly grasp the tool's function.
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 tool's moderate complexity (interactive UI action) and annotations covering basic hints, the description is minimally complete. It explains parameters and return value, but lacks context on integration with siblings (e.g., scrolling after clicking) or operational constraints. The output schema exists, so describing returns is redundant, but overall completeness is adequate with room for improvement in usage scenarios.
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 schema description coverage is 0%, so the description carries full burden. It effectively explains all three parameters (computer_id, direction, amount) with clear semantics: computer_id identifies the target, direction specifies scroll axes, and amount defines intensity with a default. This compensates well for the schema's lack of descriptions, though it could elaborate on parameter interactions (e.g., how amount scales).
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 the action ('scroll the page') and the resource ('page'), which is specific and actionable. It distinguishes from siblings like 'orgo_click' or 'orgo_drag' by focusing on scrolling rather than clicking or dragging. However, it doesn't explicitly differentiate from all possible UI interaction tools beyond the basic verb.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an active computer/project), compare to similar tools like 'orgo_drag' for scrolling, or specify scenarios where scrolling is appropriate (e.g., navigating long pages). The agent must infer usage from context alone.
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?
Annotations indicate readOnlyHint=false, destructiveHint=false, etc., covering basic safety. The description adds useful behavioral context: it mentions the need to click an input field first and that the return is a confirmation string (truncated if long). However, it doesn't disclose potential side effects like focus changes or error conditions, leaving room for improvement.
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 well-structured with clear sections: purpose, usage instructions, args, returns, and examples. It's front-loaded with the core functionality. However, the 'Args' section could be more concise by integrating with the main text, and there's minor redundancy (e.g., repeating 'text to type'), keeping it from a perfect 5.
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 1 parameter, low schema coverage, and an output schema (returns str), the description is fairly complete. It covers purpose, usage, parameters, and return value with examples. However, it lacks details on error handling or computer_id semantics, and with annotations providing limited behavioral info, it could be more thorough for a tool that interacts with UI elements.
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 description coverage is 0%, so the description must compensate. It explains the parameters in the 'Args' section, detailing computer_id and text with examples. This adds meaning beyond the bare schema. However, it doesn't clarify the purpose of computer_id (e.g., why it's needed) or text constraints beyond minLength, so it's adequate but not comprehensive.
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 the tool's purpose: 'Type text at the current cursor position.' It specifies the verb ('type') and resource ('text'), making it distinct from siblings like orgo_click or orgo_key. However, it doesn't explicitly differentiate from similar text-input tools (e.g., orgo_prompt might also involve text input), so it falls short of a perfect 5.
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 for usage: 'Click on an input field first, then use this to type text.' This gives practical guidance on when to use the tool. However, it doesn't specify when NOT to use it or name alternatives among siblings (e.g., orgo_key for single keystrokes vs. orgo_type for text strings), so it's not a full 5.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false. The description adds valuable behavioral context beyond annotations: it specifies the computer must be running, restricts exports to '/home/user', and notes the download URL expires in 1 hour. No contradiction with annotations.
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 well-structured with clear sections: purpose, constraints, return info, and parameter details. It's front-loaded with the main purpose. Some redundancy exists (e.g., path example repeated in schema), but overall efficient and readable.
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 the tool's moderate complexity (export with constraints), annotations cover safety (read-only, non-destructive), and an output schema exists (returns str), the description is fairly complete. It adds operational constraints and parameter semantics, though could better differentiate from siblings.
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 description coverage is 0%, but the description includes an 'Args' section that explains parameters: 'computer_id (str): Computer ID' and 'path (str): Path to file (e.g., 'Desktop/results.txt')'. This adds meaning beyond the schema, though it doesn't fully detail path constraints or examples beyond the schema's minimal info.
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 the tool's purpose: 'Export a file from the computer's filesystem.' It specifies the verb ('export') and resource ('file'), but doesn't explicitly differentiate from sibling tools like 'orgo_download_file' or 'orgo_upload_file', which prevents a perfect score.
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 provides some context: 'The computer must be running. Files can only be exported from /home/user.' This implies when to use (computer running, file in /home/user) but doesn't explicitly state when NOT to use or name alternatives like 'orgo_download_file' for comparison, leaving usage guidance incomplete.
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?
Annotations provide strong hints: readOnlyHint=true, destructiveHint=false, idempotentHint=true, openWorldHint=true. The description adds value by specifying the return format ('JSON with stream status') and the possible status values ('active, idle, or terminated'), which aren't covered by annotations. It doesn't contradict annotations—the 'Get' action aligns with readOnlyHint.
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 well-structured and front-loaded: it starts with the core purpose, then details the check, followed by Args and Returns sections. Every sentence adds value—no wasted words. It's appropriately sized for a simple status-check tool.
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?
Given the tool's low complexity (1 parameter), rich annotations (covering safety and behavior), and the presence of an output schema (implied by 'Returns: str: JSON with stream status'), the description is complete enough. It explains what the tool does, the parameter meaning, and the return format, addressing key context without redundancy.
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 description coverage is 0%, but the description compensates by explaining the parameter structure: 'Input containing: - computer_id (str): Computer ID'. It adds meaning beyond the schema by noting the computer_id comes from 'orgo_list_computers'. However, it doesn't detail the ComputerIdInput object beyond this, leaving some semantics implicit.
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 the tool's purpose: 'Get the current streaming status of a computer' and 'Check if a stream is active, idle, or terminated.' This specifies the verb ('Get', 'Check'), resource ('streaming status of a computer'), and outcome (status values). It doesn't explicitly differentiate from siblings like 'orgo_start_stream' or 'orgo_stop_stream', but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a computer ID from 'orgo_list_computers'), nor does it contrast with related tools like 'orgo_start_stream' or 'orgo_stop_stream'. Usage is implied by the purpose but lacks explicit context or exclusions.
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?
Annotations already declare readOnlyHint=false, destructiveHint=false, etc., indicating this is a non-destructive action. The description adds minimal behavioral context by mentioning it's 'useful for drag-and-drop operations' and returns a confirmation string, but doesn't elaborate on side effects, permissions needed, or error conditions beyond what annotations provide.
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 well-structured with clear sections (purpose, usage examples, Args, Returns). It's appropriately sized for a tool with multiple parameters, though the 'useful for' examples could be more concise. Every sentence adds value, and information 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?
Given the tool's moderate complexity (6 parameters, no annotations contradiction, has output schema), the description is mostly complete. It explains the purpose, parameters, and return value. The output schema exists, so the description doesn't need to detail return values further. Minor gaps include lack of error handling or performance considerations.
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 provides comprehensive parameter details in the Args section, including all six parameters with their types, descriptions, and default values. Since schema description coverage is 0%, the description fully compensates by documenting what each parameter means, adding significant value beyond the bare schema.
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 the tool performs drag operations ('Drag from one position to another'), which is a specific verb+resource combination. However, it doesn't distinguish this from sibling tools like 'orgo_click' or 'orgo_double_click' in terms of when to use drag versus other mouse interactions.
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 provides some implied usage context by mentioning 'drag-and-drop operations, selecting text, or resizing windows,' which gives general scenarios. However, it lacks explicit guidance on when to use this tool versus alternatives like 'orgo_click' or 'orgo_scroll,' and doesn't specify prerequisites or exclusions.
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?
The description adds useful context about the tool's purpose (recovery/reset) that goes beyond what annotations provide. Annotations already indicate this is a non-destructive, idempotent, open-world operation, so the description doesn't need to repeat those safety aspects. It doesn't mention rate limits, authentication needs, or detailed behavioral traits beyond the basic purpose.
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 well-structured and appropriately sized. It starts with the core purpose, provides usage context, then documents parameters and return value in a clear format. Every sentence earns its place with no wasted 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?
Given this is a relatively simple operation with good annotations (non-destructive, idempotent) and an output schema that documents the return type, the description provides adequate context. It explains the purpose, when to use it, and documents the single parameter. For a restart operation, this is reasonably complete.
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 description coverage is 0%, but the description includes an 'Args' section that documents the single parameter and its purpose. This compensates somewhat for the lack of schema descriptions, though it doesn't provide format details beyond what's implied. With only one parameter, the baseline would be 4, but the description adds marginal value beyond the schema structure.
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 the verb ('Restart') and resource ('a computer'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'orgo_stop_computer' or 'orgo_start_computer' beyond the restart action.
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 about when to use this tool ('recovering from unresponsive states or resetting to a clean environment'), which is helpful for an agent. However, it doesn't explicitly mention when NOT to use it or name specific alternatives among the sibling 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?
Annotations indicate this is a non-read-only, non-destructive operation (readOnlyHint: false, destructiveHint: false), which the description aligns with by describing a 'start' action that initiates streaming. The description adds useful context about the one-stream-per-computer constraint and computer state requirement, but does not detail authentication needs, rate limits, or error behaviors beyond what annotations provide.
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 well-structured with a clear purpose statement, usage constraints, parameter list, return info, and an example. It is appropriately sized, but the 'Args' section could be more concise by integrating with the schema details, and some sentences (e.g., the example) are slightly redundant.
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 the tool's complexity (initiating a stream with multiple parameters), the description is mostly complete. It covers purpose, constraints, parameters, returns, and an example. With annotations providing safety context and an output schema indicating JSON return, the description adequately supplements structured data, though it could add more on error handling or stream management.
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?
The input schema has 100% description coverage (all parameters are documented in schema), so the baseline is 3. The description's 'Args' section lists parameters with brief explanations and defaults, but adds minimal semantic value beyond the schema. It provides a practical example for 'rtmp_url' but does not significantly enhance understanding of parameter purposes or interactions.
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 specific action ('Start RTMP streaming') and resource ('from a computer'), distinguishing it from sibling tools like 'orgo_stop_stream' and 'orgo_stream_status'. It explicitly mentions streaming to platforms like Twitch and YouTube, providing a concrete use case.
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 for when to use this tool ('Computer must be running. Only one stream per computer at a time.'), but does not explicitly mention when not to use it or name alternatives. It implies usage for starting streams versus stopping or checking status, but lacks explicit exclusions.
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?
Annotations provide basic hints (readOnlyHint=false, destructiveHint=false, etc.), but the description adds minimal behavioral context beyond confirming it's a double-click action. It mentions the return value ('Confirmation of double-click action'), which is useful but doesn't elaborate on side effects, error conditions, or interaction specifics. No contradiction with annotations exists.
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 front-loaded with the core action, followed by usage guidelines and parameter details in a structured format. Every sentence adds value without redundancy, and it efficiently covers purpose, usage, and parameters in a compact form.
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 the tool's moderate complexity (GUI interaction), annotations cover safety hints, and an output schema exists (returns str), the description is reasonably complete. It explains the action, usage, and parameters, though it could enhance context with more behavioral details (e.g., coordinate reference, error handling).
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 description coverage is 0%, so the description carries the burden. It lists parameters (computer_id, x, y) and their types, adding meaning beyond the schema's minimal titles. However, it doesn't explain parameter interactions (e.g., coordinate system origin) or constraints (e.g., valid computer_id formats), leaving some semantics implicit.
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 specific action ('Double-click at (x, y) coordinates') and distinguishes it from siblings like 'orgo_click' (single click) and 'orgo_drag' (drag operation). It provides concrete use cases ('opening files/apps on desktop or selecting text'), making the purpose unambiguous and differentiated.
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 includes explicit usage context ('Use for opening files/apps on desktop or selecting text'), which helps the agent understand when to apply this tool. However, it does not specify when NOT to use it or mention alternatives like 'orgo_click' for single clicks, leaving some guidance gaps.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which fully describe the tool's safety profile. The description adds context about typical use cases but does not reveal additional behavioral traits beyond what annotations provide. There is no contradiction.
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 starts with a one-line summary, followed by usage examples, then parameter details, and finally return type. 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?
The tool has few parameters, good annotations, and an output schema. The description covers the return value as a confirmation string. It is complete for a simple waiting tool, though it could mention potential error conditions or timeout behavior for a perfect score.
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?
The description restates the parameters and their types (computer_id, seconds) with default and range, which mirrors the input schema. Given that schema description coverage is 0% (the schema itself includes descriptions for parameters), the tool description adds minimal new meaning. A baseline score of 3 is appropriate.
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's function: 'Wait for a specified duration.' It uses a specific verb-resource combination and is unambiguous. Among sibling tools, waiting is a unique action, so it is easily distinguishable.
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 explicit usage guidance: 'Useful for waiting for pages to load, animations to complete, or applications to start.' This tells the agent when to use the tool. However, it does not explicitly state when not to use it or mention alternatives, which is acceptable given the tool's simplicity.
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?
The description adds valuable behavioral context beyond what annotations provide: it explains the error handling behavior ('Returns "Error: Conflict..." if project name already exists'), which isn't covered by annotations. Annotations already indicate this is a non-destructive, non-idempotent creation operation (readOnlyHint=false, destructiveHint=false, idempotentHint=false), and the description complements this with practical error information.
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 well-structured with clear sections (Args, Returns, Examples, Error Handling) and front-loads the core purpose. While comprehensive, some sections could be more concise - the Examples section repeats information already implied by the parameter descriptions, slightly reducing efficiency.
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?
Given the tool's creation purpose, the presence of output schema, and comprehensive annotations, the description provides excellent contextual completeness. It covers purpose, workflow context, parameters, return format, examples, and error handling - everything needed for an agent to understand and use this tool effectively.
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?
With 0% schema description coverage, the description carries the full burden of parameter documentation. It does provide parameter information in the 'Args' section, explaining the 'name' and 'icon_url' parameters with examples. However, it doesn't fully compensate for the complete lack of schema descriptions, as it doesn't mention constraints like the 100-character max length for 'name' that appears in 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 specific action ('Create a new Orgo project') and distinguishes it from sibling tools by explaining that projects are containers for computers, with a direct reference to the complementary 'orgo_create_computer' tool. This provides clear differentiation from other tools like 'orgo_list_projects' or 'orgo_delete_project'.
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 about when to use this tool ('Create a project first, then add computers to it with orgo_create_computer'), establishing a workflow sequence. However, it doesn't explicitly state when NOT to use it or mention alternatives like checking for existing projects first, which prevents a perfect score.
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?
The description adds valuable behavioral context beyond annotations: it includes a 'WARNING' about permanent removal from cloud storage, which reinforces the destructive nature. Annotations already indicate destructiveHint=true and idempotentHint=true, but the description provides specific risk information, enhancing transparency without contradiction.
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 front-loaded with the core purpose and warning, followed by structured Arg/Returns sections. Every sentence adds value: the warning is critical, and the parameter guidance is necessary. No redundant information is present.
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 the tool's complexity (destructive operation with 1 parameter) and rich annotations (destructiveHint, idempotentHint), the description is largely complete. It includes a warning, parameter guidance, and return value note. With an output schema present, it doesn't need to detail return values, but could benefit from more usage context.
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?
With 0% schema description coverage, the description compensates by explaining the parameter structure: it clarifies that params contains file_id and specifies sources for obtaining it (orgo_list_files or orgo_export_file). This adds meaningful semantics beyond the bare schema, though it doesn't detail validation rules.
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 specific action ('Delete') and resource ('a file from storage'), distinguishing it from sibling tools like orgo_download_file or orgo_upload_file. It precisely communicates the tool's function without ambiguity.
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 file deletion but provides no explicit guidance on when to use this tool versus alternatives like orgo_delete_computer or orgo_delete_project. It mentions obtaining the file_id from orgo_list_files or orgo_export_file, which hints at prerequisites but doesn't clarify contextual alternatives.
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?
Annotations already indicate destructiveHint=true (implying side effects) and readOnlyHint=false (implying mutations), which the description aligns with by mentioning 'Execute Python code' and 'data processing, file manipulation'. The description adds context about timeout behavior and output format, but does not disclose additional traits like security implications, environment isolation, or error handling beyond what annotations provide.
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 well-structured and front-loaded with the core purpose, followed by usage context, parameter details, and return information. Every sentence adds value without redundancy, making it efficient and easy to parse.
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 the tool's complexity (executing arbitrary code with destructive potential) and rich annotations/output schema, the description is mostly complete. It covers purpose, usage, parameters, and returns, but could improve by addressing safety warnings, execution environment details, or error scenarios to fully guide an agent in high-stakes contexts.
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?
With 0% schema description coverage, the description fully compensates by detailing all parameters (computer_id, code, timeout) in the Args section, including their purposes and default values. This adds significant meaning beyond the schema, though it could benefit from more context on computer_id usage or code constraints.
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's purpose with a specific verb ('Execute Python code') and resource ('on the computer'), distinguishing it from sibling tools like orgo_bash (for shell commands) and orgo_ai_completion (for AI completions). The title 'Execute Python Code' reinforces this clarity.
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 for usage ('Useful for data processing, file manipulation, and quick scripts'), but does not explicitly state when not to use it or name specific alternatives among siblings (e.g., orgo_bash for non-Python tasks). This gives good guidance but lacks explicit exclusions.
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?
The annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds valuable context beyond annotations: it specifies that the tool returns 'comprehensive information' and includes an access URL for 'direct browser viewing', which helps the agent understand the output's utility. No contradictions with annotations exist.
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 well-structured with clear sections (purpose, Args, Returns, Examples) and front-loaded key information. It is appropriately sized, but some redundancy exists (e.g., repeating 'access URL' in the first two sentences), slightly reducing efficiency. Overall, it earns its place with useful details.
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?
Given the tool's low complexity (1 parameter), rich annotations (covering read-only, idempotent, etc.), and the presence of an output schema (detailed in the Returns section), the description is complete. It explains the purpose, parameters, return values with examples, and behavioral context, leaving no gaps for the agent to understand and invoke the tool correctly.
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?
The input schema has 0% description coverage, but the description compensates by detailing the parameter in the 'Args' section: 'params (ComputerIdInput): Input containing: - computer_id (str): Computer ID'. It adds meaning by explaining the parameter's purpose and referencing orgo_list_computers as a source for the ID. However, it does not fully elaborate on format constraints beyond what the schema's minLength implies, keeping it at baseline 3.
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's purpose: 'Get full details for a computer including access URL' and 'Returns comprehensive information about a computer including its access URL for direct browser viewing.' It specifies the verb ('Get'), resource ('computer'), and scope ('full details' including URL), distinguishing it from siblings like orgo_list_computers (which lists computers) and orgo_get_project (which gets project details).
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 for usage: it's for retrieving details of a specific computer, including its access URL. The examples ('Get details for computer abc123', 'What's the URL for my computer?') illustrate when to use it. However, it does not explicitly state when not to use it or name alternatives (e.g., using orgo_list_computers to find computer IDs first), which prevents a score of 5.
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?
Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, covering safety and idempotency. The description adds valuable context by specifying the types of files included (uploaded and exported) and mentioning pagination behavior, which goes beyond what annotations provide. No contradictions with annotations exist.
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 well-structured with a clear purpose statement, usage guidance, and parameter documentation. It's appropriately sized for the tool's complexity, though the 'Args' and 'Returns' sections could be slightly more concise as they largely repeat schema information. Every sentence serves a purpose.
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?
Given the tool's moderate complexity, rich annotations, and existing output schema, the description provides complete context. It covers purpose, usage, parameter meanings, and return format, making it fully adequate for an AI agent to understand and invoke the tool correctly without needing additional information.
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 description coverage is 0%, but the description includes an 'Args' section that documents all parameters (computer_id, limit, offset, response_format) with clear explanations. However, this information is redundant with the schema's property descriptions, and the description doesn't add significant semantic value beyond what's already in the structured schema fields.
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 specific action ('List all files') and resource ('associated with a computer'), distinguishing it from sibling tools like orgo_download_file and orgo_delete_file. It also specifies the scope by mentioning both uploaded files and exported files, providing precise differentiation.
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 for when to use this tool ('List all files associated with a computer') and mentions related tools (orgo_download_file, orgo_delete_file) for subsequent actions. However, it doesn't explicitly state when NOT to use it or compare it to alternatives like orgo_upload_file, which could provide more comprehensive guidance.
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?
Annotations provide hints (readOnlyHint=false, destructiveHint=false, idempotentHint=true, openWorldHint=true), but the description adds valuable context: it's a batch operation affecting all computers simultaneously, which implies potential downtime or coordination needs. It doesn't contradict annotations and supplements them with operational details.
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 well-structured and front-loaded with the core purpose, followed by sections for Args, Returns, and Examples. Each sentence adds value without redundancy, making it efficient and easy to parse for an AI agent.
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 the tool's complexity (batch restart operation), annotations cover safety and idempotency, and an output schema exists (Returns: str). The description provides purpose, parameter guidance, and an example, but could benefit from more on error conditions or prerequisites. It's largely complete but has minor gaps.
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 description coverage is 0%, but the description includes an Args section explaining that params contains project_id, referencing orgo_list_projects for sourcing. This adds meaning beyond the bare schema, though it doesn't detail format constraints or examples beyond the minimal guidance. With one parameter, it meets baseline expectations.
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 specific action ('Restart all computers') and resource ('in a project'), distinguishing it from sibling tools like orgo_restart_computer (which restarts individual computers) and orgo_start_project/stop_project (which manage project state rather than computer restarts). The title annotation reinforces this purpose.
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 as a 'Batch operation to restart all computers simultaneously,' which implicitly suggests when to use it versus orgo_restart_computer. However, it lacks explicit guidance on when not to use it (e.g., for partial restarts) or direct alternatives, preventing a perfect score.
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?
The description adds valuable behavioral context beyond annotations: it specifies performance characteristics ('Boots in under 500ms'), mentions the need to obtain computer IDs from another tool, and provides example usage. While annotations cover idempotency and non-destructive nature, the description enriches understanding with practical details.
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 well-structured and front-loaded with the core purpose, followed by practical guidance, parameter explanation, and examples. Every sentence adds value with no wasted words, and the information is organized logically for quick comprehension.
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 the tool's moderate complexity (state-changing operation), the description provides good context about prerequisites, performance, and usage. With annotations covering safety aspects and an output schema documenting the return type, the description focuses appropriately on operational guidance rather than repeating structured information.
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?
With 0% schema description coverage, the description partially compensates by explaining the computer_id parameter comes from orgo_list_computers and providing an example. However, it doesn't fully document the parameter's semantics beyond what's implied in the schema structure, leaving some gaps in understanding.
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 specific action ('Start a stopped computer') and identifies the resource ('computer'), distinguishing it from sibling tools like orgo_restart_computer and orgo_stop_computer. It uses precise language that goes beyond just restating the tool name.
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 for when to use this tool ('Start a stopped computer') and explicitly references an alternative tool for finding computer IDs ('Use orgo_list_computers to find computer IDs'). However, it doesn't explicitly state when NOT to use this tool (e.g., vs. orgo_restart_computer for a running computer).
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?
Annotations provide readOnlyHint=false (mutation), openWorldHint=true (may have side effects), idempotentHint=true (safe to retry), and destructiveHint=false (non-destructive). The description adds value by specifying it stops 'RTMP streaming' (a specific protocol) and mentions the return format ('JSON with final stream status'), which isn't covered by annotations. 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 front-loaded with the core purpose in the first sentence, followed by structured Args and Returns sections. Every sentence adds value: the purpose statement, parameter explanation, and return format. No redundant or verbose language is present.
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 the tool's complexity (mutation with one parameter) and rich annotations (covering safety and idempotency), the description is mostly complete. It explains the action, parameter, and return format, and an output schema exists to detail return values. However, it lacks explicit guidance on error conditions or streaming state 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 description coverage is 0%, but the description compensates by documenting the single parameter (params with computer_id) and its purpose ('Computer ID'). It adds context by noting computer_id comes from 'orgo_list_computers', providing usage guidance. However, it doesn't elaborate on the ComputerIdInput structure beyond what's implied, keeping it minimal.
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 specific action ('Stop RTMP streaming') and target resource ('from a computer'), distinguishing it from siblings like orgo_start_stream (starts streaming) and orgo_stream_status (checks status). It uses precise technical terminology (RTMP) and identifies the exact operation.
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 usage context by specifying 'from a computer' and referencing computer_id from orgo_list_computers, suggesting prerequisites. However, it doesn't explicitly state when to use this tool versus alternatives like orgo_stop_computer (which stops the computer entirely) or provide clear exclusions for when streaming isn't active.
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?
The description adds valuable behavioral context beyond annotations: it specifies the return format (JSON with detailed structure), includes error handling for 'Resource not found', and notes that results include 'all computers' (desktops). Annotations cover read-only, open-world, idempotent, and non-destructive traits, so the description complements them without contradiction.
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 well-structured and front-loaded with the core purpose, followed by organized sections (Args, Returns, Examples, Error Handling). Every sentence adds value, such as clarifying the return format and error cases, with no redundant or verbose content.
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?
Given the tool's simplicity (1 parameter), rich annotations (read-only, idempotent, etc.), and the presence of an output schema (implied by the Returns section), the description is complete. It covers purpose, parameters, return values, examples, and error handling, leaving no gaps for the agent to understand and invoke the tool correctly.
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 description coverage is 0%, but the description compensates by explaining the 'name' parameter in the Args section and providing an example. However, it doesn't add meaning beyond what's implied by the parameter name (e.g., format constraints or uniqueness), so it meets the baseline for adequate but not exceptional 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 the tool's purpose with a specific verb ('Get') and resource ('project details by name'), distinguishing it from siblings like 'orgo_list_projects' (which lists multiple projects) and 'orgo_create_project' (which creates rather than retrieves). The title 'Get Project Details' reinforces this clarity.
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 usage context by specifying 'by name' and providing an example, suggesting it's for retrieving details of a specific known project. However, it lacks explicit guidance on when to use this versus alternatives like 'orgo_list_projects' (for browsing) or 'orgo_get_computer' (for computer-specific details), which would be needed for a perfect score.
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?
Annotations already provide readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=true, covering safety and idempotency. The description adds valuable context beyond annotations: it discloses the API key requirement (auth needs), mentions pagination behavior, and specifies the return format options, enhancing behavioral understanding without contradicting annotations.
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 well-structured with clear sections (purpose, returns, args, examples) and front-loaded key information. Every sentence adds value, though the Args section could be slightly more concise by integrating defaults directly rather than repeating schema details.
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 the tool's moderate complexity (1 nested param, no output schema provided in context), the description is quite complete. It covers purpose, prerequisites, parameters, return behavior, and examples. With annotations handling safety aspects and no output schema to explain, the description fills most contextual gaps effectively.
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 description coverage is 0%, so the description must compensate. It provides a structured Args section detailing limit, offset, and response_format with default values and constraints, which adds significant meaning beyond the bare schema. However, it doesn't fully explain the nested params object or ResponseFormat enum semantics, leaving some 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 verb 'List' and resource 'available AI models through OpenRouter', distinguishing it from siblings like orgo_ai_completion (which uses models) and other list tools (computers, files, projects). It specifies the scope (400+ models) and connection to OpenRouter, making the purpose specific and unambiguous.
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?
The description explicitly states when to use this tool: to list models for use with orgo_ai_completion. It also provides prerequisites (requires OpenRouter API key) and includes an example usage pattern ('List available AI models' -> use with defaults), giving clear guidance on context and alternatives.
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?
Annotations provide readOnlyHint=false, destructiveHint=false, idempotentHint=true, and openWorldHint=true. The description adds valuable behavioral context beyond annotations: it specifies this is a batch operation, mentions performance ('Computers boot in under 500ms each'), and indicates it returns a confirmation message. No contradiction with annotations exists.
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 well-structured and front-loaded with the core purpose, followed by behavioral details, parameter explanation, and an example. Every sentence adds value without redundancy, and it efficiently uses bullet points for clarity. No wasted words.
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?
Given the tool's moderate complexity (batch operation with one parameter), rich annotations (covering safety and idempotency), and the presence of an output schema (returns str), the description is complete. It explains the action, performance, parameters, and return value, leaving no gaps for agent understanding.
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 description coverage is 0%, but the description compensates by explaining the single parameter in the Args section: 'params (ProjectIdInput): Input containing: - project_id (str): Project ID'. It adds meaning by specifying the parameter type and structure, though it doesn't detail format constraints beyond what the schema's minLength and title provide.
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 specific action ('Start all computers') and resource ('in a project'), distinguishing it from sibling tools like orgo_start_computer (single computer) and orgo_restart_project (different operation). It provides precise scope with 'all computers simultaneously' and performance detail ('under 500ms each').
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 usage context through 'Batch operation to boot all computers simultaneously' and the example, suggesting it's for bulk operations. However, it doesn't explicitly state when to use this versus alternatives like orgo_start_computer (individual) or orgo_restart_project (restart vs start), nor does it mention prerequisites or exclusions.
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?
The description adds useful context about coordinate system ('pixels from top-left corner') and default button behavior, which goes beyond the annotations. However, it doesn't mention important behavioral aspects like whether this triggers UI events, has latency considerations, or requires specific screen resolution conditions. The annotations already declare non-destructive and non-idempotent, so the description doesn't contradict them.
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 well-structured with clear sections (purpose, usage guidance, coordinate explanation, Args, Returns, Examples). Every sentence adds value: the first states purpose, second provides usage guidance, third explains coordinates, and the structured sections efficiently document parameters and examples 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 click action tool with 1 parameter object containing 4 fields, the description provides good coverage: purpose, usage guidance, coordinate system explanation, parameter details, return value, and examples. The output schema exists (Returns: str), so the description doesn't need to elaborate on return values. It could benefit from mentioning error conditions or coordinate validity ranges.
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?
With 0% schema description coverage, the description carries full burden. It provides clear explanations of all parameters: coordinates are 'in pixels from top-left corner,' computer_id is mentioned in the Args section, and button options with default are explained. The examples further clarify parameter usage, though it could explicitly mention computer_id in examples.
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 specific action ('Click at (x, y) coordinates on the screen') and distinguishes it from siblings like 'orgo_double_click' and 'orgo_drag' by specifying it's a single click operation. The verb 'click' is precise and the resource 'screen coordinates' is well-defined.
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?
The description explicitly states 'Use orgo_screenshot first to see the screen and identify click targets,' providing clear when-to-use guidance and naming a specific alternative tool for prerequisite context. This helps the agent understand the workflow relationship between tools.
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?
The description adds valuable context beyond annotations: it specifies the return format ('JPEG image') and the temporal aspect ('current screen'), which aren't covered by annotations. While annotations already indicate read-only, non-destructive, and idempotent behavior, the description usefully explains the tool's purpose in a workflow context without contradicting annotations.
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 well-structured with clear sections (purpose, returns, usage guidance, args, returns, examples) and every sentence adds value. It's front-loaded with the core functionality and efficiently communicates essential information 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 single-parameter tool with comprehensive annotations (readOnlyHint, idempotentHint, etc.) and no output schema, the description provides sufficient context: it explains what the tool does, when to use it, the parameter meaning, and the return format. The main gap is the lack of output schema documentation, but the description compensates adequately.
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?
With 0% schema description coverage, the description compensates by explaining the parameter's purpose ('Computer ID to screenshot') and providing a source hint ('from orgo_list_computers') in the Args section. However, it doesn't fully document the parameter's format or constraints beyond what's implied, leaving some gaps despite the single parameter.
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 specific action ('Take a screenshot') and resource ('computer's display'), distinguishing it from sibling tools like orgo_click or orgo_type that perform different interactions. It explicitly mentions the output format ('JPEG image'), which further clarifies its unique purpose.
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?
The description provides explicit guidance on when to use this tool ('Use this to see what's on screen before clicking or typing'), offering a clear alternative workflow. It also includes example prompts that reinforce appropriate usage contexts, helping the agent distinguish it from other display-related tools.
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?
The description adds valuable behavioral context beyond annotations: it specifies that the output includes both stdout and stderr combined, which is not covered by annotations. Annotations already indicate destructiveHint=true and readOnlyHint=false, so the description doesn't contradict them. However, it could mention potential risks like command injection or system impacts, though the annotations provide a solid safety profile.
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 well-structured and front-loaded with the core purpose, followed by usage guidelines, parameter details, and examples. Every sentence adds value without redundancy, making it efficient and easy to scan for an AI agent.
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?
Given the tool's complexity (executing arbitrary bash commands with destructive potential) and the presence of annotations and an output schema, the description is complete. It covers purpose, usage, parameters, and return values, and the output schema handles the response format, so no additional details are needed for effective tool invocation.
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?
With schema description coverage at 0%, the description fully compensates by detailing the parameters in the 'Args' section, explaining that 'params' contains 'computer_id' and 'command', and providing examples. This adds significant meaning beyond the bare schema, though it doesn't elaborate on parameter constraints or formats beyond the examples given.
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's purpose with a specific verb ('Execute') and resource ('bash command on the computer'), distinguishing it from siblings like orgo_click or orgo_type. It provides concrete examples of use cases (file operations, installing packages, etc.), making the purpose unambiguous and well-defined.
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 includes a 'Useful for' section that gives clear context on when to use this tool (e.g., file operations, installing packages), which helps differentiate it from other tools. However, it does not explicitly state when not to use it or name specific alternatives among siblings, such as preferring orgo_exec for non-bash commands, leaving some room for improvement.
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?
The description adds valuable behavioral context beyond annotations: it specifies that the computer boots in under 500ms, starts in 'running' status, returns a computer ID for use with action tools, and includes error handling for insufficient credits. Annotations cover readOnlyHint=false, openWorldHint=true, idempotentHint=false, and destructiveHint=false, but the description enhances this with performance details and error scenarios, without contradicting annotations.
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 well-structured and front-loaded: it starts with the core purpose, followed by behavioral details, return value, and organized sections for Args, Returns, Examples, and Error Handling. Each sentence adds value without redundancy, and the bullet-point formatting in later sections improves readability without unnecessary verbosity.
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?
Given the tool's complexity (creation with multiple parameters), the description is complete: it covers purpose, usage, parameters, return values (with output schema details), examples, and error handling. Annotations provide safety and idempotency hints, and the output schema exists, so the description need not explain return values in depth. It addresses all necessary aspects for effective tool invocation.
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 description adds significant meaning beyond the input schema. Schema description coverage is 0%, so the description fully compensates by detailing all parameters (project_name, name, os, ram, cpu) with their purposes, allowed values, and defaults. It provides examples that illustrate parameter usage, such as 'Create Linux computer with 4GB RAM' for ram=4, enhancing understanding beyond the schema's enum and type definitions.
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 specific action ('Create a new virtual computer') and resource ('in a project'), distinguishing it from siblings like orgo_get_computer, orgo_list_computers, orgo_restart_computer, and orgo_delete_computer. It specifies the creation context (project) and outcome (boots in under 500ms, starts in 'running' status), making the purpose unambiguous and differentiated.
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 for when to use this tool: to create a new virtual computer in a project, with the computer ID returned for use with action tools. It implies alternatives by mentioning sibling tools like action tools, but does not explicitly name when to use this versus alternatives like orgo_get_computer or orgo_list_computers, nor does it specify exclusions or prerequisites beyond the required parameters.
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?
The description adds significant behavioral context beyond annotations: it explicitly warns that the operation is 'destructive and cannot be undone' and that 'all data on the computer will be lost.' While annotations already indicate destructiveHint=true, the description elaborates on the irreversible consequences, which is valuable for agent decision-making.
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 well-structured and front-loaded with the core action and warning, followed by parameter and return details. Every sentence earns its place: the first states the purpose, the next two emphasize the risk, and the last two document inputs/outputs without redundancy.
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?
Given the tool's high complexity (destructive deletion), rich annotations (including destructiveHint), and the presence of an output schema (returns a confirmation message), the description is complete enough. It covers the purpose, risks, parameters, and return value, providing all necessary context for safe agent invocation.
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 description coverage is 0%, but the description includes an 'Args' section that documents the single parameter 'computer_id' and references 'ComputerIdInput.' However, it doesn't add meaning beyond what's implied by the parameter name (e.g., format, source like from 'orgo_list_computers' is in the schema). With one parameter, the baseline is 4, but the description only partially compensates 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 the specific action ('permanently delete') and resource ('a computer'), distinguishing it from siblings like 'orgo_restart_computer' or 'orgo_stop_computer' which are non-destructive operations. It precisely communicates the irreversible nature of the 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 provides clear context for when to use this tool (to permanently delete a computer) and implicitly suggests alternatives like 'orgo_stop_computer' or 'orgo_restart_computer' for less destructive actions. However, it doesn't explicitly name these alternatives or specify prerequisites like needing the computer ID from 'orgo_list_computers'.
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?
The description adds valuable behavioral context beyond annotations: it explains the cost-saving purpose, data preservation during shutdown, and restart capability. While annotations cover idempotency and non-destructive nature, the description provides practical implications. No contradiction with annotations exists.
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 perfectly structured with a clear purpose statement, usage guidance, and parameter documentation in three distinct sections. Every sentence earns its place with zero wasted words, and the information is front-loaded appropriately.
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?
Given the tool's moderate complexity, rich annotations (idempotent, non-destructive), and existing output schema, the description provides complete context. It covers purpose, usage alternatives, behavioral implications, and parameter meaning without needing to explain return values (handled by output schema).
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 description coverage is 0%, but the description's Args section documents the single parameter's purpose and source ('Computer ID to stop', 'from orgo_list_computers'). This adds meaningful semantics beyond the bare schema, though it doesn't fully compensate for the complete lack of schema 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 the specific action ('Stop a running computer') and primary benefit ('to save costs'), distinguishing it from sibling tools like orgo_restart_computer or orgo_delete_computer. It uses precise verb+resource language that leaves no ambiguity about the tool's function.
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?
The description explicitly provides when-to-use guidance by stating 'The computer can be restarted later with orgo_start_computer,' naming the alternative tool. It also implies when-not-to-use by noting data preservation, suggesting this is preferable to deletion tools. This gives clear context for tool selection.
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?
The description adds valuable behavioral context beyond annotations: it explains this is a 'batch operation' affecting 'all computers' and mentions the cost-saving purpose. While annotations already indicate it's not read-only, not destructive, idempotent, and open-world, the description provides practical operational context that helps the agent understand the tool's impact and rationale.
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 perfectly structured: purpose statement first, followed by behavioral context, sibling reference, parameter explanation, return value, and concrete examples. Every sentence adds value with zero redundancy, and the information is front-loaded for quick comprehension.
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?
Given the tool's moderate complexity (batch operation with cost implications), the description provides complete context: purpose, behavioral traits, sibling relationships, parameter usage, return values, and examples. With annotations covering safety aspects and an output schema present, the description focuses exactly on the value-added information an agent needs.
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?
With 0% schema description coverage, the description partially compensates by showing the parameter structure in the Examples section ('params with project_id="proj_123"'), but doesn't fully explain the ProjectIdInput wrapper or provide additional semantic context beyond what's implied by the tool name. The baseline is 3 since the schema itself has good descriptions for the nested project_id parameter.
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 specific action ('Stop all computers') and resource ('in a project'), distinguishing it from sibling tools like orgo_stop_computer (which stops individual computers) and orgo_restart_project (which restarts instead of stops). The verb+resource combination is precise and unambiguous.
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?
The description explicitly states when to use this tool ('Batch operation to stop all computers and save costs') and provides a clear alternative ('Computers can be restarted later with orgo_start_project'), naming the specific sibling tool. This gives complete guidance on both the primary use case and the complementary operation.
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?
The description adds valuable behavioral context beyond annotations: it specifies the Desktop location, syncing behavior across project computers, and a 10MB file size limit. While annotations cover basic safety (destructiveHint: false), the description provides practical constraints that help the agent understand operational boundaries.
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 perfectly structured: purpose statement first, followed by key behavioral constraints, then parameter details, and finally return value. Every sentence earns its place with zero wasted words, making it easy for an agent to parse quickly.
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?
Given this is a mutation tool with annotations, the description provides excellent completeness: clear purpose, behavioral constraints, parameter explanations, and output information. With an output schema present, the description appropriately focuses on operational context rather than return value details.
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?
With 0% schema description coverage, the description fully compensates by providing a clear parameter breakdown with meaningful explanations for each field. It explains what computer_id, filename, content_base64, and content_type represent, adding substantial value beyond the bare 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 specific action ('Upload a file') and target resource ('to the computer's Desktop'), distinguishing it from siblings like orgo_download_file (download) and orgo_delete_file (delete). It provides additional context about syncing behavior that further clarifies its purpose.
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 about when to use this tool (uploading files to Desktop with syncing across project computers) and includes a maximum file size constraint. However, it doesn't explicitly state when NOT to use it or name specific alternatives like orgo_export_file for different file operations.
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?
The description adds valuable behavioral context beyond annotations: it discloses the requirement for an OpenRouter key (authentication need), mentions the unified API aspect, and provides an example of typical usage. While annotations cover basic hints (not read-only, open world, etc.), the description enhances understanding of the tool's operational requirements.
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 well-structured and appropriately sized, with clear sections (purpose, requirements, args, returns, examples) and zero wasted sentences. Each element serves a distinct purpose: the opening establishes context, the Args section provides essential details, and the example illustrates practical application.
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?
Given the tool's complexity (AI completion with multiple parameters), the description is complete: it covers purpose, authentication requirements, parameter details with examples, return values, and usage examples. With an output schema present, the description appropriately focuses on operational context rather than return format details.
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?
Despite 0% schema description coverage, the description provides comprehensive parameter semantics through the Args section, detailing each field (model, prompt, system, max_tokens, temperature) with examples, defaults, and constraints. This fully compensates for the lack of schema descriptions and adds practical usage guidance.
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's purpose with specific verbs ('Run an AI completion') and resources ('using OpenRouter's 400+ models'), distinguishing it from sibling tools that handle file operations, computer management, or UI interactions. It explicitly mentions the unified API access to multiple model providers.
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 about when to use this tool ('Run an AI completion') and mentions prerequisites ('Requires OpenRouter key in your Orgo account settings'), but doesn't explicitly state when not to use it or name alternatives among sibling tools. The example helps illustrate usage scenarios.
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?
Annotations indicate non-read-only, non-destructive, non-idempotent, and closed-world behavior, which the description aligns with by implying a state-changing action (pressing keys). It adds valuable context beyond annotations by detailing supported key types and combinations, though it lacks explicit rate limits or error handling details.
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 well-structured and front-loaded with the core purpose, followed by clear sections for args, returns, and examples. Every sentence earns its place by providing essential information without redundancy, making it efficient and easy to parse.
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?
Given the tool's moderate complexity, the description is complete: it covers purpose, usage, parameters with examples, and return values. With an output schema present, it appropriately avoids re-explaining returns, and the annotations provide safety context, leaving no significant gaps for agent invocation.
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 compensates by explaining the 'params' input, including the 'computer_id' and 'key' fields with specific examples of valid keys and combos. This adds crucial meaning beyond the bare schema, ensuring the agent understands how to format inputs correctly.
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's purpose with a specific verb ('Press') and resource ('keyboard key or combination'), distinguishing it from sibling tools like orgo_type (typing text) or orgo_click (mouse actions). The title 'Press Keyboard Key' reinforces this, making the function unambiguous.
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 on when to use this tool by specifying it handles single keys and modifier combinations, with examples like 'Press Enter' or 'Press Ctrl+C'. However, it does not explicitly state when not to use it (e.g., vs. orgo_type for text input) or name alternatives, keeping it from a perfect score.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds valuable behavioral context: pagination details, error handling for missing projects or empty results, and output format specifics (markdown vs JSON). This goes beyond annotations but doesn't mention rate limits or authentication needs.
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?
Well-structured with clear sections (Args, Returns, Examples, Error Handling) and front-loaded purpose. Some redundancy exists (e.g., repeating parameter details in schema-like format), but most sentences add value. Could be slightly tighter by integrating parameter details more seamlessly.
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?
Given the tool's complexity (listing with pagination and formatting), annotations cover safety, and the description thoroughly explains parameters, usage, output formats, errors, and examples. The output schema is present, so return values are adequately documented. No significant gaps remain for agent understanding.
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 description coverage is 0%, so the description carries full burden. It documents all 4 parameters (project_name, limit, offset, response_format) with semantics, defaults, and constraints. However, it doesn't explain the ResponseFormat enum values beyond listing them, leaving some 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 specific action ('List all computers in a project') and resource ('computers'), distinguishing it from siblings like orgo_get_computer (single computer) and orgo_create_computer (creation tool). The title 'List Computers in Project' reinforces this purpose.
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?
Explicit guidance is provided: 'Use computer_id with action tools like orgo_screenshot, orgo_click, orgo_bash, etc.' This tells the agent when to use this tool (as a prerequisite for those actions) and distinguishes it from filtering alternatives (e.g., 'Show running VMs' requires listing then filtering).
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?
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond what annotations provide. While annotations already indicate destructiveHint=true, the description elaborates with specific warnings ('Permanently delete', 'cannot be undone', 'All computers and their data will be lost'), mentions idempotent behavior through error handling examples, and provides concrete error messages. This gives the agent crucial operational context not captured in annotations alone.
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 perfectly structured and front-loaded: it starts with the core action and warning, then provides necessary details in organized sections (Args, Returns, Examples, Error Handling). Every sentence earns its place, with no redundant information or fluff.
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 destructive operation with 1 parameter and an output schema, the description is complete: it explains the action, consequences, parameter usage, return format, examples, and error handling. The presence of an output schema means the description doesn't need to detail return values, and it provides all necessary context for safe and correct usage.
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?
With 0% schema description coverage (the schema only has generic descriptions), the description compensates well by explaining that params contains project_id, specifying it comes from orgo_list_projects, and providing a concrete example. However, it doesn't fully document the ProjectIdInput structure beyond project_id, leaving some schema elements unexplained.
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 specific action ('Permanently delete') and resource ('a project and ALL its computers'), distinguishing it from sibling tools like orgo_delete_computer (which deletes individual computers) and orgo_delete_file (which deletes files). The scope is explicitly defined as including all computers in the project.
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 for when to use this tool (to delete entire projects with their computers) and includes a warning about its destructive nature. However, it doesn't explicitly mention when NOT to use it or name specific alternatives like orgo_delete_computer for deleting individual computers instead of entire projects.
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?
The description adds valuable behavioral context beyond annotations: it discloses that 'The URL expires after 1 hour,' which is not covered by annotations (which only indicate read-only, non-destructive, and idempotent operations). However, it doesn't mention rate limits or authentication needs, leaving some gaps. No contradiction with annotations exists.
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 front-loaded with the core purpose, followed by key behavioral details and usage guidelines in a structured format with 'Args:' and 'Returns:' sections. Every sentence adds value without redundancy, making it efficient and easy to parse.
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?
Given the tool's simplicity (1 parameter, read-only, non-destructive), the description is complete: it covers purpose, usage, behavioral traits (expiry), parameter semantics, and return values. With an output schema present, it doesn't need to detail return format further, and annotations handle safety aspects adequately.
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?
With 0% schema description coverage, the description compensates well by explaining the parameter semantics: it specifies that 'params' contains 'file_id' and notes 'File ID (from orgo_list_files or orgo_export_file)' in the schema, adding meaning about the source of the ID. This clarifies usage beyond the bare 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 specific action ('Get a signed download URL for a file') and distinguishes it from siblings like 'orgo_list_files' (used to find file IDs) and 'orgo_export_file' (another file operation). It uses precise verbs and identifies the resource (file).
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?
The description explicitly provides usage guidance: 'Use orgo_list_files to find file IDs' specifies a prerequisite, and it distinguishes this tool from alternatives by focusing on download URLs rather than other file operations like deletion or export. This helps the agent know when to use this tool versus others.
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?
Annotations already provide readOnlyHint=true, destructiveHint=false, openWorldHint=true, and idempotentHint=true. The description adds valuable behavioral context beyond annotations: it explains pagination support, error handling (e.g., invalid API key, no projects), and the two response formats (markdown and JSON), which are not covered by annotations.
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 well-structured with clear sections (Args, Returns, Examples, Error Handling) and front-loaded purpose. It is appropriately sized but could be slightly more concise by integrating some details more tightly, though all sentences add 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?
Given the tool's complexity (pagination, multiple formats), the description is complete: it covers purpose, usage, parameters, return values (including both markdown and JSON formats), examples, and error handling. With annotations and a detailed description, no gaps remain for effective tool use.
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 schema description coverage at 0%, the description fully compensates by detailing all parameters (limit, offset, response_format) with their meanings, constraints (e.g., limit 1-100), defaults, and enum values. It provides clear semantics that the schema lacks, making parameters understandable.
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's purpose with specific verb ('List') and resource ('all Orgo projects in your account'), distinguishing it from siblings like orgo_get_project (singular) and orgo_create_project (creation). It immediately communicates the scope and action.
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?
The description provides explicit guidance on when to use this tool versus alternatives: it mentions using project names with orgo_list_computers or orgo_create_computer to manage computers, and includes examples like 'List my Orgo projects' and 'Show next page of projects' that clarify typical use cases.
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:

[![orgo-mcp MCP server](https://glama.ai/mcp/servers/nickvasilescu/orgo-mcp/badges/card.svg)](https://glama.ai/mcp/servers/nickvasilescu/orgo-mcp)

Score Badge

Copy to your README.md:

[![orgo-mcp MCP server](https://glama.ai/mcp/servers/nickvasilescu/orgo-mcp/badges/score.svg)](https://glama.ai/mcp/servers/nickvasilescu/orgo-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/nickvasilescu/orgo-mcp'

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