octo-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Most tools have distinct purposes, especially the browser automation ones. However, the profile management tools like list_profiles, search_profiles, find_profile_by_name, and get_profile are similar and could cause confusion, as could start_profile and start_profile_by_name.
Naming Consistency3/5
The tool names follow a snake_case format but mix two prefixes (octo_ and browser_) and inconsistent verb choices within the octo_ group (list, get, search, find, start, stop, delete). Some names deviate from verb_noun patterns, like octo_health_check and browser_query_selector_all, making the set readable but not fully predictable.
Tool Count2/5
With 37 tools, this is well above the 25-tool threshold for a heavy set. While the browser automation tools are numerous and justified, the profile management tools include several redundant lookups and start methods that could be consolidated to reduce the count.
Completeness3/5
The browser automation surface is fairly complete with navigation, interaction, content extraction, and tab management. However, the profile management is incomplete: there is no create, update, or delete for persistent profiles, and extensions, tags, and proxies only support limited read/delete operations.
Average 3.5/5 across 37 of 37 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but 'Scroll the page.' reveals nothing about how scrolling behaves (e.g., viewport vs element, default amount, smoothness) or any side effects. It is nearly a tautology of the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) and front-loaded, but it is under-specified—it provides no additional value beyond the tool name. It is not verbose, but it doesn't earn its place by adding meaningful context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, and the presence of three parameters including an optional selector and direction, a one-sentence description is insufficient. It doesn't clarify the return value, edge cases, or usage context, leaving the agent under-informed for correct 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 coverage is 100% as all three parameters (amount, selector, direction) have descriptions in the input schema. The description adds no parameter-level information, so the baseline of 3 applies.
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 'Scroll the page.' clearly states the action and resource, using the verb 'scroll' and object 'page'. It is distinct enough among the sibling browser tools, though it doesn't mention that it can scroll a specific element via selector, so it doesn't fully distinguish from a potential viewport-only scroll.
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 gives no guidance on when to use this tool versus alternatives, no mention of the optional selector for element-specific scrolling, and no context about direction or amount. It simply states the action without any usage scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the action without revealing side effects on the active tab, behavior for invalid indices, or dependencies like an active browser connection. This is a significant gap for a tool that mutates browser state.
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 a single, direct sentence that is perfectly concise and front-loaded. It contains no extraneous words or repetition, making it highly efficient for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though the tool is simple with one parameter and no output schema, the description is incomplete for practical use. It omits usage guidance, error handling, and any mention of how to determine valid tab indices. While the schema covers the parameter, the overall context is under-specified.
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 fully describes the sole parameter 'index' with type and semantic meaning ('Tab index starting from 0'), so the baseline of 3 applies. The description itself adds no additional parameter-specific information, but the schema already provides adequate coverage.
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 'Switch to another tab.' clearly identifies both the action (switching) and the resource (tab), which distinguishes it from sibling tools like browser_new_tab, browser_close_tab, and browser_list_tabs. However, it does not explicitly state that the switch changes the active tab, which leaves a slight ambiguity.
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, such as listing tabs first via browser_list_tabs or noting that it is distinct from navigation. There is no mention of prerequisites, exclusions, or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior, but it only states the action. It doesn't mention whether typing replaces existing text, whether a selector is required for element targeting, or how it interacts with focus for page typing. Important behavioral traits are entirely absent.
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 a single, tight sentence with zero waste. It is appropriately front-loaded, but could be slightly more informative without losing conciseness; still, it avoids fluff and is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a browser automation tool with no annotations and no output schema, the description is too sparse. It doesn't clarify when typing on a page vs. into an element is appropriate, or what happens after the text is typed. Sibling tools like browser_press_key are not differentiated, leaving the agent without enough context to select this tool confidently.
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 fully describes all three parameters (100% coverage), so the baseline is 3. The description adds no additional semantic meaning beyond the schema, such as typical use cases for delay or the optional selector, but the schema already provides adequate parameter documentation.
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 uses the specific verb 'type' and identifies the resource as text into an element or page, which clearly distinguishes it from clicking or pressing keys. However, it doesn't explicitly name alternative tools for comparison or further clarify the target element behavior.
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?
No guidance is provided about when to use this tool versus alternatives like browser_press_key or browser_evaluate, nor any prerequisites such as needing an element focused. The purpose is the only implied usage signal, and there are no explicit exclusions or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It discloses the auth requirement (OCTO_API_TOKEN) and Cloud API usage, but does not state whether the operation is read-only, how results are returned (e.g., pagination, summary vs. full profiles), or any side effects. The term 'search' implies read-only but not explicitly stated.
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 two sentences and efficiently front-loads the core purpose. 'Uses Cloud API' is slightly redundant but not harmful. The auth requirement is useful. Overall, concise and structured well.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 optional parameters and no output schema, the description is incomplete. It does not explain how parameters interact (e.g., AND/OR for tags, how status/ordering affect results), what the return value looks like, or that it is a read-only search. The description leaves significant gaps for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (all 5 parameters have descriptions). The description adds no additional parameter semantics beyond the schema; it only mentions 'partial name or tags' which is already captured by the 'search' and 'tags' parameter descriptions. Baseline 3 is appropriate.
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 searches profiles by partial name or tags, which is a specific verb+resource+method. However, it does not mention the additional filtering capabilities (status, ordering) that are part of the tool's purpose, making it slightly incomplete for full purpose clarity.
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?
No guidance is given on when to use this tool versus alternatives like octo_find_profile_by_name (exact match) or octo_list_profiles (list all). The description implies a search use case but does not explicitly explain exclusions or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action and does not mention what happens if the element is not found, whether the element must be visible, or if any state changes occur. This is a significant gap for a tool that manipulates UI state.
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 a single, focused sentence ('Hover over an element.') that is immediately clear and front-loaded. Every word earns its place, and there is no wasted content.
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?
For a simple one-parameter tool, the description is minimally adequate, but it lacks contextual details such as whether the page must be loaded, what happens on failure, or how hover interacts with other browser states. Given no output schema and no annotations, it could do a bit more to fully equip the agent.
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 already describes the 'selector' parameter as 'CSS selector of the element' with 100% coverage. The description adds no additional meaning beyond the schema, so the baseline score of 3 applies.
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 identifies the action ('Hover') and the target ('an element'), which distinguishes it from sibling tools like browser_click or browser_type. However, it lacks explicit scope (e.g., 'on the current page'), so it stops short of being fully specific.
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 like browser_click or browser_wait_for_selector. There is no mention of prerequisites, use cases, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits itself. It only states the action without specifying return behavior (e.g., value vs null), error handling for missing elements, or whether it waits for the element. This is a significant gap for a tool with no structured safety hints.
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 consists of a single, clear sentence with no unnecessary words. It is well-structured and immediately communicates the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should clarify what the tool returns, but it does not. It also lacks information about error scenarios or edge cases. For a read-only getter with two straightforward parameters, the description is too sparse to be fully actionable.
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?
Both parameters (selector and attribute) are fully described in the schema, including types and descriptions. The tool description adds no additional meaning beyond the schema, so the 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 'Get an attribute of an element' clearly states the tool's function: retrieving a specific attribute from a DOM element. This is distinct from sibling tools like browser_get_text (text content) and browser_get_html (HTML markup), so the resource type 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 over alternatives such as browser_get_text or browser_query_selector_all. No context is given about use cases, prerequisites, or when to avoid it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention what happens if the element is not found, whether multiple matches are handled, or whether the return value is trimmed/includes hidden text. This is a significant gap for a simple getter.
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 a single clear sentence with no filler or redundant content. It is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description needs to explain more about the return value and error behavior. It does not, leaving the agent unsure whether the result is a string, null, or an error. This is insufficient even for a simple tool.
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 schema already provides 100% coverage for the single parameter (selector) with a description. The tool description adds no extra semantic meaning beyond the schema, so the baseline 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 uses a specific verb ('get') and resource ('text content of an element'), which clearly distinguishes it from sibling tools like browser_get_html (HTML content) and browser_get_attribute (attribute value). It is concise 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as browser_get_html or browser_get_attribute. The description only states what the tool does without any context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only says 'navigate' without disclosing behavior such as whether it waits for page load (though wait_until is in schema), whether it throws errors on invalid URLs, or how it affects the current tab's history. This is minimal.
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?
One sentence with zero wasted words. It is appropriately sized for a simple navigation tool and front-loads the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should cover basic expectations. It fails to mention return values, error behavior, or interaction with page load states. The wait_until parameter is not explained in the description, leaving the agent under-informed.
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 100%, so baseline is 3. The description adds nothing beyond 'specified URL' which is redundant with the schema property. It does not elaborate on wait_until or URL format.
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 and resource: 'Navigate to the specified URL in the browser.' This is specific and distinguishes the tool from siblings like browser_go_back, browser_reload, and browser_new_tab.
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?
No guidance is provided about when to use this tool vs alternatives. It does not mention relationships to browser_new_tab, browser_switch_tab, or how navigation differs from loading URLs in a new tab.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral transparency burden. However, it adds nothing beyond the schema's parameter description, failing to disclose where the key press is sent, side effects, or expected response. This is minimal and lacks substantive context.
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 a single, well-structured sentence that front-loads the action and includes relevant examples. There is no redundant or unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a browser automation tool with no annotations or output schema, this description is too sparse. It omits crucial context such as where the key press occurs (active element, webpage), when to use it, and potential side effects, leaving the agent guessing about the tool's behavior.
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 fully describes the 'key' parameter with examples (Enter, Tab, Escape, etc.), achieving 100% coverage. The description itself adds no additional meaning, so the baseline score of 3 applies.
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 action ('Press a keyboard key') and provides examples of valid keys, distinguishing it from sibling tools like browser_click and browser_type. It is specific and communicates the tool's primary purpose effectively.
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?
There is no guidance on when to use this tool versus alternatives such as browser_click or browser_type, nor any mention of prerequisites or contextual use cases. The description only states the action itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. As a destructive delete operation, it fails to mention permanence, irreversibility, or any consequences (e.g., whether deletion cascades to associated data). The minimal statement provides no behavioral context beyond the action itself.
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 a single, concise sentence with no filler or repetition. It efficiently communicates the core action and target resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the destructive nature and absence of annotations or output schema, the description is incomplete. It does not warn about permanence, explain the team context, or describe expected outcomes. A more complete description would include at least an irreversibility warning and clarify the scope.
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 schema covers 100% of the parameter 'uuids' with a description ('List of extension UUIDs to delete'). The tool description adds 'by UUID', which is redundant with the schema. No additional semantic value is provided beyond what the schema already offers.
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 'Delete' and the resource 'team extensions', with the scoping criterion 'by UUID'. It distinguishes itself from siblings like octo_get_extensions (retrieval) and octo_get_tags (tag management) by being explicitly a deletion operation.
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?
No guidance is provided on when to use this tool versus alternatives, or any prerequisites or context. The description simply states the action without specifying scenarios, exclusions, or relationships to other extension-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the action without detailing side effects like tab focus, return values, or behavior when no URL is provided. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero wasted words, directly front-loading the action verb. It is exceptionally concise.
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?
For a simple tool with one optional parameter and no output schema, the description provides the core action but omits any return value, usage context, or behavior variations. It is minimally adequate but not rich.
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 provides 100% coverage for the single optional 'url' parameter with a clear description ('URL to open (optional)'). The tool description adds no extra parameter semantics, so the baseline 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 states a specific verb and resource ('Open a new tab') that clearly distinguishes it from sibling tools like browser_close_tab, browser_switch_tab, and browser_list_tabs. It is unambiguous about the tool's primary function.
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 like browser_navigate or browser_list_tabs. It does not mention the optional URL parameter or any conditions or exclusions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the action without mentioning side effects, error handling, waiting behavior, or event triggering. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately sized for a simple action and easy to scan.
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?
The description is adequate for a straightforward action, but it omits behavioral details such as return values, failure modes, or whether it waits for the options to load. Given the absence of an output schema, a bit more context would be helpful.
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 provides clear descriptions for both parameters (selector and value) with 100% coverage. The description adds no additional parameter meaning beyond what the schema already conveys.
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 uses a specific verb 'select' and resource 'select element', clearly distinguishing it from sibling browser actions like click, type, or press_key. It is unambiguous and directly conveys 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as browser_click or browser_type. No context is provided about prerequisites, limitations, or when this is the preferred choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Uses Cloud API' and 'Requires OCTO_API_TOKEN', which are useful operational constraints. However, it does not disclose behavior on no-match, exact vs partial matching (though the schema covers exact_match), or what is returned. The read-only nature is implied by 'Find' but not explicitly stated.
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 three short sentences totaling 18 words, front-loaded with purpose, followed by prerequisites. Every sentence adds necessary context, with no redundancy or filler.
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?
The description plus well-covered schema provides a basic understanding of the tool. However, with no output schema, no annotations, and no explicit usage guidance, it leaves gaps around return value format and when to choose this over similar sibling tools. It is adequate but not comprehensive.
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 schema covers both parameters (name and exact_match) with descriptions, providing 100% coverage. The description adds no extra parameter-level detail beyond what is in the schema, so the baseline of 3 is appropriate.
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 'Find' and the resource 'Octo Browser profile', and specifies the lookup criterion ('by name (title)'). This is a specific and actionable purpose, though it does not explicitly distinguish from sibling tools like octo_search_profiles or octo_get_profile.
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 explicit guidance on when to use this tool versus alternatives. It mentions prerequisites (Cloud API and token) but does not state in which scenarios this should be preferred over octo_search_profiles or octo_get_profile. Usage context is only implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the burden of behavioral disclosure. It merely says 'Stop' without explaining consequences (e.g., whether it kills the process, loses unsaved state, or is reversible). The force parameter is not explained, and no return behavior is disclosed.
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 a single, front-loaded sentence with no superfluous words. It earns its place and is easy to parse.
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?
For a simple stop action with two parameters, the description is minimally adequate but incomplete. It omits the purpose of the force parameter, success/failure indicators, and any side effects. More context would help the agent invoke it correctly in edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both uuid and force. The description adds minimal context ('by UUID') but does not elaborate on the force flag, so the baseline 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 uses a specific verb 'Stop' with a clear resource 'Octo Browser profile' and method 'by UUID'. This clearly distinguishes it from sibling tools like octo_start_profile and octo_start_one_time_profile.
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?
No guidance is given on when to use this tool versus alternatives, nor any mention of prerequisites (e.g., profile must be running) or the force parameter. The description simply states what it does, leaving usage context to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely states execution and result return, without mentioning important behaviors such as scripts running in page context, potential to modify page state or cause navigation, error handling, or result serialization. This is a significant transparency gap for a powerful execution tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, front-loaded sentence that conveys the core action and outcome without any filler. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having only one parameter, the tool executes arbitrary JavaScript, which introduces moderate complexity. There is no output schema, so the description should explain the return format or behavior (e.g., promises, errors, serialization), but it only says 'return the result'. This leaves significant gaps in understanding the tool's full behavior.
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 fully covers the single parameter 'script' with a clear description. The description text adds no additional insight beyond the schema, so the baseline score of 3 applies, as the schema does the heavy lifting.
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 uses a specific verb ('Execute') and resource ('JavaScript code on the page') and clearly states the output ('return the result'). This distinguishes it from sibling tools that perform specific browser actions like clicking, navigating, or reading attributes, making the purpose distinctly clear.
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?
No explicit guidance on when to use this tool versus alternatives, but the description implies it is for running arbitrary JavaScript on the page. Since there is no discussion of when not to use it or alternatives, it falls at the 'implied usage' level rather than providing full context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only says 'return their information,' leaving unspecified what fields are returned (text, attributes, HTML), whether the result is an array, error handling for no matches, or any waiting behavior. This is a significant gap for a browser automation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words. It is direct and front-loaded, stating the verb and resource immediately. It could be more informative, but that is a matter of completeness, not conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description must explain return values. 'Return their information' is vague and incomplete, providing no detail on what 'information' includes or how it is structured. Given the low complexity, a short but more explicit description (e.g., 'returns array of objects with text, attributes, and HTML') would be expected.
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 schema already fully describes the sole parameter 'selector' as 'CSS selector' (100% coverage). The description adds 'all elements' but does not provide additional syntax or format details beyond the schema. Baseline of 3 is appropriate because the schema handles the parameter meaning adequately.
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 action: 'Find all elements by selector' and the result: 'return their information.' This is specific and distinguishes it from sibling tools like browser_get_text or browser_get_html, which focus on particular data types. It also implies multiple results via 'all elements.'
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: use this tool when you need to retrieve all elements matching a CSS selector and get their info. However, it offers no explicit comparisons or exclusions relative to sibling tools, such as browser_get_text for single-element text or browser_wait_for_selector for waiting. Usage context is only implicitly suggested by the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only says 'wait for an element to appear' and does not disclose timeout behavior, supported states (visible, hidden, attached, detached), or what happens on timeout (throw vs return). This leaves significant behavioral ambiguity.
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 a single, concise sentence that directly states the tool's purpose without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description lacks important context like return value or error behavior. It also doesn't explain the 'state' parameter despite schema having it. The minimal description leaves gaps for an AI agent, though the schema provides some parameter details.
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 100% with each parameter clearly described (selector, state, timeout). The description adds no additional parameter information, so it meets the baseline for full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb (wait) and resource (element) and clearly differentiates from sibling tools like browser_query_selector_all or browser_click by describing a waiting behavior rather than querying or interacting.
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 the tool should be used when needing to wait for an element to appear, but it provides no explicit guidance on when to use it versus alternatives or any preconditions. It is clear but not fully directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. It only states the action and targeting options, but omits important traits such as whether the tool scrolls the element into view, waits for the element, what happens if both selector and coordinates are provided, or that clicking may trigger navigation or other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two brief sentences, front-loaded with the primary action ('Click on an element'). Every word earns its place, with no redundancy or filler.
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?
The schema covers all parameters, so no parameter documentation gaps exist. However, the description lacks context on edge cases like missing elements, coordinate system assumptions, or interaction with page state, which are relevant for a browser click tool. Given the tool's apparent simplicity, it is minimally complete but not rich.
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 100%, so each parameter is already documented. The description adds a small semantic layer by clarifying that selector and coordinates are alternatives ('or'), but it does not specify precedence or conditional requirements, leaving the baseline at 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 uses a specific verb ('Click') and resource ('element'), clearly distinguishing this from sibling tools like browser_hover or browser_type. It also states the two targeting methods (CSS selector or coordinates), making the tool's scope explicit.
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 usage is somewhat implied by the action word 'click' and the sibling tool names, but there is no explicit guidance on when to use this tool over browser_hover, browser_select, or others. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the action. It does not disclose whether the tool returns a string, raises errors if no page is loaded, or has side effects. This leaves the agent without important context for a simple get operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, fully readable and front-loaded.
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?
The tool is simple, but the description lacks any information about return format, error behavior, or assumptions (e.g., active tab). Given no output schema, an agent might not know exactly what to expect, though the name itself strongly implies the URL string. Overall, it is minimally adequate.
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 zero parameters, and the description adds no additional parameter semantics. The baseline score of 4 applies as there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: retrieving the current page URL. It uses a specific verb ('Get') and a precise resource ('current page URL'), which distinguishes it from sibling tools like browser_get_text or browser_get_html.
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?
No guidance is provided on when to use this tool instead of alternatives. It does not mention prerequisites, such as needing an active tab, nor does it compare with related tools like browser_navigate or browser_get_text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention what happens when there is no forward history, whether the tool waits for page load, or whether it returns any status or error. The description is too sparse to convey important behavioral traits.
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 a single, highly concise sentence that immediately conveys the action. Every word earns its place, and there is no wasted verbiage.
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?
For a tool with no parameters and no output schema, the description is minimally viable but lacks context about browser history behavior, failure modes, or relation to sibling navigation tools. It is complete enough for a trivial action, but omits edge-case behavior that could surprise an agent.
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?
This tool has zero parameters, so the schema provides no parameter semantics. Per the rubric baseline, a zero-parameter tool receives a 4, and there is no additional parameter information needed or provided.
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 'Go forward to the next page' clearly identifies the action (go forward) and the target resource (next page). It distinguishes this tool from its sibling browser_go_back, which would be the natural alternative.
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?
No guidance is provided on when to use this tool versus alternatives like browser_go_back or browser_navigate. The description implies navigation through browser history, but it never explicitly states the prerequisite of having previously navigated back or that it only works within the current tab's history stack.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose all behavioral details, but it only says 'Reload the current page.' It does not mention potential side effects (e.g., losing unsaved form data), whether the reload waits for the page to fully load, or error behavior for unresponsive pages.
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 a single, short sentence with every word providing value. There is no redundancy or filler, and the structure is optimally front-loaded with the action and target.
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?
For a simple tool with no parameters and no output schema, this is minimally viable but not fully complete. It conveys the basic function but lacks behavioral context and usage guidance, making it adequate rather than comprehensive.
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 tool has zero parameters, so the empty input schema already fully documents the expected inputs. The description correctly does not attempt to add parameter meaning, and the baseline score of 4 applies for parameterless tools.
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 action ('Reload') and the target ('current page'), distinguishing it from sibling navigation tools like browser_navigate, browser_go_back, and browser_go_forward. It is specific, unambiguous, and immediately understandable.
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 such as browser_go_back or browser_navigate, nor any exclusions or prerequisites. This is a missed opportunity to help the agent select the correct action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions 'Uses Cloud API' and lists returned fields, but does not explicitly confirm read-only behavior, error handling, auth prerequisites, or side effects. This is a notable gap for a tool in a context with mutating siblings.
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 a single front-loaded sentence that immediately states the action and target, then compactly lists the returned fields and API context. Every word earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 1-parameter tool with no output schema, the description adequately conveys the return contents by naming specific fields. It lacks error-case or pagination details, but these are less critical given the tool's low complexity and full schema coverage.
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 already provides 100% coverage for the single uuid parameter with 'Profile UUID'. The description merely restates 'by UUID' without adding format constraints or additional detail, so it adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb+resource ('Get full profile data by UUID') and enumerates the included fields (fingerprint, proxy, extensions, description, tags). This distinguishes it from sibling tools like octo_get_extensions or octo_get_tags by establishing it as the comprehensive profile getter.
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 retrieving a complete profile but does not explicitly state when to use this tool instead of siblings like octo_get_extensions, octo_get_tags, or octo_get_proxies. It lacks clear when-not guidance or named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The verb 'Get' implies a read-only operation, but it does not explicitly confirm that, nor does it mention error handling, return format, or what happens with an invalid selector. This leaves important behavioral context undisclosed.
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 a single short sentence that directly states the tool's function. No filler or repetitive information, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter tool, the description gives the core purpose and the two modes (page or element). However, it lacks return format details, edge-case behavior (e.g., selector not found), and explicit confirmation of read-only nature. Given no annotations and no output schema, these gaps limit completeness, though the tool is simple enough to still be usable.
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 100%, so parameters are already well-documented. The description adds meaning by clarifying that omitting the selector returns the entire page HTML, while providing a selector targets an element. This goes beyond the schema, which only says 'optional'.
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 uses the specific verb 'Get' with a clear resource ('HTML content') and scope ('page or an element'). It clearly distinguishes from sibling tools like browser_get_text and browser_get_attribute by naming the exact data type returned.
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 retrieving HTML rather than text or attributes, but it does not explicitly state when to use this tool over siblings. There is no exclusions or alternative guidance, but the purpose is clear enough for an agent to infer basic usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Get list of open tabs' is the bare minimum and does not disclose what the list contains (e.g., tab IDs, titles, URLs), ordering, or whether it includes all tabs across windows. Without an output schema, this lack of detail is a significant gap.
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 a single, clear sentence with zero redundancy. It is front-loaded and appropriately sized for the tool's trivial input schema.
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?
The tool is very simple (no params, no schema), but no output schema exists, so the description should clarify what the returned list contains. It does not, making the description somewhat incomplete. However, the low complexity prevents a lower score.
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 tool has zero parameters, so the baseline is 4. There is no parameter information needed, and the description does not need to explain any.
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 uses a specific verb ('Get') and resource ('list of open tabs'), clearly distinguishing it from sibling tools like browser_get_url (gets current URL) and browser_switch_tab. The purpose is immediately understandable and unique among the listed tools.
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 (when you need to enumerate tabs), but provides no explicit when-to-use or alternatives. With several browser sibling tools, some guidance would be helpful, but the simple self-explanatory nature of the tool keeps this at a minimum viable level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the ordering prerequisite but omits other behavioral traits such as side effects, error conditions, connection lifecycle, or cleanup requirements. Since no annotations are provided, the description carries the full burden, which is only partially met.
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 a single, front-loaded sentence with no redundant text. Every word contributes to purpose and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter connect tool with no output schema, the description covers purpose and a key prerequisite. It lacks explicit information about return values or post-connect behavior, but sibling tools like browser_navigate suggest the next steps, keeping this adequate.
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 schema already provides 100% coverage for the single parameter, describing the WebSocket endpoint and its source. The description adds no new parameter-specific meaning beyond the stated prerequisite, which is not directly about the parameter's format or usage.
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 identifies a specific action ('Connect') and resource ('running Octo Browser profile via CDP'), clearly distinguishing it from sibling tools like browser_disconnect and octo_start_profile.
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 explicitly states a prerequisite: 'Must be called after octo_start_profile.' This provides clear contextual guidance, though it does not mention alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It clearly states the action but does not mention edge cases like empty history, page-load waiting, or reversibility. It is not misleading, but lacks deeper behavioral context.
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 a single concise sentence that directly conveys the purpose. It is front-loaded and contains no filler or redundant content.
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 zero-parameter navigation command with no output schema, the description is mostly complete. It lacks details on return values or failure modes, but given the simplicity, it sufficiently covers what the tool does.
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 tool has zero parameters, and the empty schema confirms this. The description adds no parameter information, but none is needed; the baseline for zero-parameter tools is appropriately 4.
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 navigates back to the previous page, using the specific verb 'go back' and resource 'previous page'. This distinguishes it from browser_go_forward, browser_navigate, and browser_reload.
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?
No guidance is provided on when to use this tool versus alternatives. The description only restates the core action without context or exclusions, offering no additional usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It adds the output type ('Returns an image') but does not disclose potential side effects, limitations (e.g., element visibility, viewport vs. full page), or whether the operation is read-only. The description provides basic behavioral context but is not thorough.
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, two sentences, and places the action verb first. Every word adds value, with no fluff or repetition of 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?
The tool is relatively simple, with only two parameters and full schema descriptions. The description's mention of 'Returns an image' provides sufficient high-level output information. However, it could be more complete by noting that without full_page, only the visible viewport is captured, though this is already implied by the schema's full_page description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters (selector, full_page) having clear descriptions in the schema. The tool description does not add meaning beyond the schema, apart from reinforcing that a full page or element can be targeted. Baseline of 3 applies because the schema handles the semantic burden adequately.
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 with a specific verb ('Take a screenshot') and resource ('page or an element'). It distinguishes itself from sibling tools like browser_get_text and browser_get_html by focusing on visual capture rather than text or DOM extraction.
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 capturing visual representations of a page or element, but it does not explicitly state when to prefer this over alternatives or provide exclusion criteria. It lacks clear 'when to use' or 'when not to use' guidance, leaving the agent to infer from the sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. The verb 'Get' strongly implies a read-only operation with no side effects, and the description adds the output fields shown. However, it does not explicitly state that no changes are made, nor does it mention any potential errors, authorization requirements, or pagination behavior. This is acceptable for a simple list tool but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences that immediately state the action and the output fields. There is zero filler content, and the most important information is front-loaded in the first sentence.
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 zero-parameter list tool, the description is sufficiently complete. It specifies the resource (team extensions) and the fields shown (name, version, uuid), which is especially valuable given the lack of an output schema. It could have added a note about when to use it, but the low complexity makes this a minor omission.
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 tool has zero parameters and the input schema is empty, so the description does not need to explain parameter semantics. The baseline for 0-parameter tools is 4, and the description appropriately focuses on the output rather than parameters, adding no unnecessary detail.
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 identifies the operation as 'Get list of team extensions' with a specific verb and resource, and distinguishes it from sibling tools like octo_delete_extensions by focusing on listing rather than modifying. It also specifies the output fields (name, version, uuid), leaving no ambiguity about what the tool returns.
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 explicit guidance on when to use this tool versus alternatives such as octo_get_tags, octo_get_proxies, or octo_get_profile. It implies a read-only listing use case but does not state prerequisites, exclusions, or scenarios where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description itself must convey behavioral traits. It indicates a read-only operation via 'Get list' and describes return fields, but does not mention potential side effects, permissions, or error conditions. For a simple list operation, this is adequate though not exhaustive.
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 a single concise sentence that delivers the essential information without padding. It is front-loaded and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description sufficiently covers the return values. It does not mention pagination or ordering, but these are unlikely to be critical for such a simple list operation. The description is complete enough for the tool's complexity.
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 tool has zero parameters, so the description need not explain parameter syntax. The baseline of 4 applies, and the description does not interfere with parameter 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 tool lists all tags and specifies the fields returned (name, color, uuid). This distinguishes it from sibling tools that deal with profiles or browser actions, as no other sibling targets tags.
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?
No guidance is provided on when to use this tool versus alternatives. While the name implies the purpose, there is no explicit context or exclusionary notes relative to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits on its own. It only states the action without mentioning what happens if it's the last tab, whether it requires an active connection, or any side effects like losing unsaved state. This lack of behavioral detail is a significant gap.
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 a single short sentence that directly states the action. Every word earns its place; there is no redundant information.
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 simplicity (zero parameters, no output schema), the description covers the basic action, but it omits important contextual behavior such as handling the last tab or connection requirements. For a tool this simple, the basics are present but edge cases are unexplored, making it adequate yet not fully complete.
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 tool takes zero parameters, so the schema is entirely self-explanatory. The baseline score for no-parameter tools is 4, and the description adds no unnecessary parameter information.
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 uses a specific verb ('close') and resource ('tab'), clearly distinguishing it from sibling tools like browser_new_tab, browser_list_tabs, and browser_switch_tab which perform different operations. It is unambiguous about the action performed.
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 tool's purpose is self-evident; there are no sibling tools for closing a tab, so no exclusions are needed. However, it doesn't explicitly state when to use it (e.g., before navigating away), but the context is clear and there are no competing 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It accurately implies a read-only operation and specifies the output fields, which is useful. However, it does not mention edge cases like empty lists, ordering, or any connection prerequisites, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with no filler, front-loading the core action and resource. Every word adds value, making it well-structured 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?
For a simple zero-parameter list tool, the description is largely complete: it explains the purpose and the output format. The only minor gap is the lack of behavior when no profiles are running, but given the low complexity, the context is sufficient.
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?
This tool has zero parameters, so the schema description coverage is 100% and there is little to explain. The description adds value by detailing the returned fields, which is relevant even though there are no parameters to define.
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 action ('Get list') and the resource ('Octo Browser profiles') with a specific scope ('active (running)'). It also lists the output fields (UUID, name, ws_endpoint), which distinguishes it from broader siblings like octo_search_profiles.
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 usage context is implied by 'active (running)', which tells the agent this is for currently running profiles. However, there is no explicit mention of when not to use it or alternatives, so the guidance remains implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds valuable behavioral context: the tool returns a ws_endpoint for CDP connection and is idempotent ('If already running, returns existing data'). However, it does not disclose potential side effects like launching a GUI or needing authentication, yet the core behavior is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action. Every sentence earns its place: the first states the purpose and method, the second describes the return and idempotency behavior. 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?
The tool is moderately complex (starts a browser profile) with no output schema or annotations. The description covers the essential behavior: what it does, how to invoke it, what it returns, and idempotency. It lacks details about error handling or prerequisites, but for an agent selecting and invoking the tool, the information is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both parameters (uuid and headless) described in the schema. The description adds no extra parameter semantics beyond what the schema already provides. Baseline 3 is appropriate since the schema does the heavy lifting.
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 uses a specific verb ('Start') and resource ('Octo Browser profile') with the method 'by UUID'. It also distinguishes from siblings like octo_start_profile_by_name and octo_start_one_time_profile by specifying the UUID key. The return value ('ws_endpoint for CDP connection') adds further clarity.
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 clearly implies this tool is used to start a profile by UUID, but it does not explicitly state when to use it over alternatives like octo_start_profile_by_name or octo_start_one_time_profile. No exclusions or alternative recommendations are provided, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses a key prerequisite ('Requires OCTO_API_TOKEN'), which is helpful. However, it omits other behavioral details like error handling or return value, and it does not explicitly describe the side effect of starting a 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?
Two short sentences convey the core functionality, the combined nature, and a prerequisite. There is no redundant information or fluff.
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 tool with only 2 params and no output schema, the description adequately explains what it does and a required condition. It could mention failure behavior (e.g., profile not found), but the description is largely sufficient for this simple operation.
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 100%, with both parameters already documented (name and headless). The description adds no extra parameter semantics, so 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 finds a profile by name and starts it, with the explicit note 'Combines find + start' distinguishing it from sibling tools like octo_find_profile_by_name and octo_start_profile.
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 phrase 'Combines find + start' implicitly tells the agent when to use this tool (when both operations are needed). It lacks an explicit exclusion or comparison, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully discloses that the Octo profile is not stopped, but it does not explain other behavioral aspects, such as whether the browser connection is closed gracefully, any side effects on active sessions, or return/error 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 a single sentence that is succinct and front-loaded. It conveys the core action and a key caveat without any wasted words, earning a perfect score.
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 simplicity (no parameters, no output schema), the description adequately covers its purpose and the most important context (not stopping the profile). It could mention return values or disconnect confirmation, but for a straightforward action, the current description is sufficiently complete for an agent to use correctly.
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 tool takes zero parameters, so there is nothing for the description to add beyond the input schema, which is already complete. The baseline of 4 is appropriate because no parameter semantics are needed.
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 action ('Disconnect from browser') and the resource (browser). The parenthetical 'does not stop the Octo profile' effectively distinguishes it from the sibling tool octo_stop_profile, eliminating ambiguity about its scope.
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 clearly implies when this tool is appropriate: when you want to disconnect from a browser while keeping the Octo profile running. The exclusion of stopping the profile provides guidance against confusing it with profile-stop tools, though it does not explicitly name 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?
No annotations are provided, so the description carries full responsibility. It discloses the output fields, which is useful, and 'Get list' implies a read-only operation. However, it omits details like pagination, potential errors, or authentication requirements, leaving some behavioral aspects ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core purpose and followed by a concise enumeration of output fields. Every word contributes, with no redundancy or filler.
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 simplicity (0 params, no output schema), the description adequately covers its functionality and output. It could mention whether the list is paginated or if any filters apply, but these are minor omissions for a straightforward read-only list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty (100% coverage). Per the rubric, 0 params merits a baseline of 4; the description does not need to explain any parameter semantics, and it does not introduce any confusion.
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 uses a specific verb 'Get list' and identifies the resource 'all proxies', while enumerating the output fields (type, host, port, uuid). This clearly distinguishes it from sibling tools like octo_list_profiles or octo_health_check, which serve different resources.
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 when proxy information is needed, and since no sibling tool provides proxy data, the context is clear. However, it lacks explicit exclusions or mention of alternative tools, but given its unique purpose, the absence is not critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently reveals the key destructive behavior (profile is deleted after stopping) and notes performance and use-case characteristics. However, it omits details like prerequisites (e.g., Octo installed) or return values, but the most critical trait is disclosed.
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 exceptionally concise: two sentences that front-load the purpose and immediately state the key differentiator (temporary/deleted). Every word adds value, with no redundancy or extraneous detail.
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 simple parameter set and lack of output schema, the description covers the essential facts: what it does, key behavioral consequence, and a use case. It does not explain how the started profile connects to browser tools, but that's implicit from the sibling context. It is reasonably complete for the tool's complexity.
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 already provides complete descriptions for both parameters (os and headless) with 100% coverage. The tool description adds no additional parameter-related meaning, so the baseline score of 3 is appropriate; it does not need to compensate for schema gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Create and start') and resource ('one-time (temporary) Octo Browser profile'), while distinguishing it from the regular start profile by highlighting its temporary nature and deletion after stopping. This sets it apart from sibling tools like octo_start_profile.
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 usage context: it's ideal for scraping and emphasizes the temporary lifecycle ('deleted after stopping'). This implies when to use it, though it does not explicitly state exclusions or when to prefer a regular profile. Sibling tool names help, but the description itself gives sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of disclosing behavior. It states the core activity (checking API availability) but does not clarify what the output indicates (e.g., success/failure format) or whether any side effects exist. For a simple health check, this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences that state the purpose and provide a usage directive. Every word earns its place, with no unnecessary detail.
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 is simple with no parameters and no output schema, so the description is largely sufficient for an agent to invoke it correctly. It could be enhanced by specifying what 'availability' means (e.g., returns a boolean or throws an error), but the current level is adequate for a connectivity check.
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 tool has zero parameters, so the description does not need to elaborate on parameter semantics. The schema already covers everything with 100% coverage, and a baseline of 4 is appropriate for a no-parameter tool.
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 and resource: 'Check Octo Browser API availability.' It is distinct from all sibling tools, which focus on profiles or browser automation, none of which are connectivity checks.
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 usage guidance: 'Call this first to verify connectivity.' This clearly tells the agent when to use this tool relative to other operations, even though it doesn't name alternatives, because the role of a health check is unique and this instruction is unambiguous.
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:

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

Score Badge

Copy to your README.md:

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

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