electric-cherry

Server Quality Checklist

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

Latest release: v0.1.1
Disambiguation3/5
Some tools overlap in purpose (electron_connect vs v8_connect vs chrome, renderer_evaluate vs evaluate), and generic names like 'target' and 'step' could be ambiguous. However, most tools have clear, distinct roles when read with descriptions, so the ambiguity is moderate.
Naming Consistency3/5
Many tools follow a context_action pattern (v8_connect, chrome_switch_connection), but there are also bare nouns (target, breakpoint, execution) and verbs (navigate, evaluate). The mixed conventions are readable but lack a single consistent pattern.
Tool Count2/5
With 31 tools, the surface is notably large, spanning connections, debugging, navigation, network, and evaluation. While each group covers a niche, the total feels excessive for typical agent workflows, and could be consolidated (e.g., merging v8_connect with electron_connect).
Completeness4/5
The tool set covers the core lifecycle of Electron debugging: setup, connect, navigate, interact, inspect, debug, and evaluate. Minor gaps exist such as no explicit wait-for-element or page source retrieval, but agents can work around these with evaluate.
Average 3.3/5 across 31 of 31 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

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 merely states the action; it does not mention side effects, reversibility, error behavior, or what happens to the connection or ongoing operations. This is a significant gap for a state-changing tool.
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 sentence with no filler, making it concise and front-loaded. However, its brevity borders on under-specification, though for a simple tool it remains appropriately sized.
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 simple schema and absence of annotations and output schema, the description should provide more context about when and why to disconnect, and what the impact is. Its minimalism leaves the tool's operational context unclear, especially within the Chrome management suite.
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 fully describes the only parameter (connection_id) with 100% coverage, so the description need not repeat it. The description adds no parameter-level detail, but the baseline of 3 applies because the schema handles the semantics.
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 'Disconnect from a Chrome instance' clearly states the action (disconnect) and the target (a Chrome instance), distinguishing it from sibling tools like chrome_connect or chrome_list_connections. It is not a tautology, though it lacks any additional scope or nuance.
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 vs alternatives like chrome_switch_connection or chrome_list_connections. No prerequisites, consequences, or exclusions are mentioned, leaving the agent without decision-making 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, the description carries full responsibility for behavioral disclosure. It states the action but does not explain side effects (e.g., whether clearing is permanent, whether it affects all traffic or only the specified connection), or any error conditions. The destructive nature is implied but not explicitly 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, concise sentence that conveys the core function without any fluff. It is front-loaded and every word contributes to meaning.
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 annotations and output schema, the description must provide more context. It does not mention what happens after clearing, whether the operation is scoped to the connection_id, or any preconditions. For a mutation tool, this is insufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with a description for 'connection_id', so the baseline is 3. The tool description adds no additional meaning beyond the schema, but the schema is sufficient for understanding the single parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Clear') and target resource ('captured network requests'). It is specific and unambiguous, though it does not explicitly differentiate from siblings like get_network_requests, which is acceptable given the clear semantic distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It lacks context such as prerequisites (e.g., network must be enabled) or typical scenarios (e.g., after a debugging session). Users must 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?
With no annotations provided, the description carries the full burden of disclosing behavior. However, it only states the verb 'resume or pause' without explaining side effects (e.g., what pausing does to the running script, whether resume continues to the next breakpoint or completes execution). This lack of detail is a significant gap for a debugger control tool.
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, front-loaded sentence that directly conveys the core function. It is efficient with no wasted words. However, given the tool's role in a debugger toolset, slightly more structural context (e.g., a parenthetical about what 'execution' refers to) would improve scannability without adding bulk.
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 two parameters and no output schema, this description is too thin to be fully self-sufficient. It does not explain the effect of pause/resume on the execution flow, when to use it within a debugging session, or how 'connection_id' influences behavior. The sibling tools provide some context, but the description alone is inadequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for both parameters, with the 'action' enum clearly described as '"resume" or "pause"' and 'connection_id' described as 'Chrome connection to use'. The tool description adds no additional 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Resume or pause execution.' This is a specific verb+resource pair that conveys the core functionality. However, it does not explicitly differentiate from sibling tools like 'step' or 'breakpoint', which are also related to execution control in a debugger context.
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. There is no mention of scenarios where this is preferred over 'step', 'breakpoint', or 'pause_on_exceptions'. The description simply states what it does without offering context for selection, leaving the agent to infer usage solely from the tool name and siblings.
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 full responsibility for behavioral disclosure. It does not mention whether logs are cleared, how filtering works by default, ordering (most recent), or side effects. This is a significant gap for a tool that interacts with 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 concise sentence with no redundant wording. It is front-loaded and each word contributes to 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?
Given the lack of an output schema and annotations, the description is insufficiently complete. It does not explain the return format, the role of connection_id, or any prerequisites like an active browser connection, making it inadequate for a tool in a complex browser automation context.
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?
All three parameters have schema descriptions, achieving 100% coverage. The tool description itself adds no further meaning about parameter interactions or usage, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves console log messages from the browser, using a specific verb and resource. However, it does not explicitly distinguish it from sibling tools like get_network_requests, which also retrieve browser data.
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 network request retrieval or DOM inspection. The description provides no context about prerequisites, connection requirements, or selection criteria.
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 offers no behavioral details beyond the basic action. With no annotations, the agent is unaware of side effects, return format, or defaults; even the output (image data) is unstated.
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 sentence with no redundant words, making it concise and easy to parse. It could be more informative, but the brevity is not harmful.
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 description is minimal, omitting key context such as return value, default format (png), and the fact that full_page defaults to false. Since no output schema exists, the agent has no way to know what the tool returns, making the description incomplete for effective use.
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?
All three parameters are already fully described in the schema (format, full_page, connection_id), so the description adds no extra semantic meaning. The baseline of 3 applies because the schema carries the full responsibility.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('capture') and resource ('screenshot of current page'), establishing a specific purpose. However, it doesn't mention the full_page parameter capability or contrast with any sibling tool, though no screenshot-specific sibling exists.
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 simply states the action without contextual decisions, exclusions, or references to other 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 full behavioral responsibility. It only states the evaluation mechanism but does not disclose side effects, return values, error handling, whether evaluation is synchronous, or any connection requirements. This lacks transparency for a potentially mutating 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, focused sentence with no fluff. It efficiently communicates the core purpose and is appropriately sized for the tool's simplicity.
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?
Although the tool has only two parameters and no output schema, the description lacks usage guidance and behavioral transparency. An agent would not know when to choose this tool or what consequences to expect, leaving the description incomplete for confident 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?
The schema provides full descriptions for both parameters (100% coverage), so the tool description does not need to add parameter details. It adds no extra semantic meaning beyond what the schema already provides, warranting the baseline score of 3.
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 evaluates JavaScript in the Electron main process via V8 Inspector, specifying the resource and mechanism. It distinguishes from renderer-side evaluation but does not explicitly contrast with sibling tools like renderer_evaluate or evaluate.
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 renderer_evaluate or evaluate. There is no mention of appropriate contexts, prerequisites, 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 full burden but only states the action without disclosing side effects, requirements (e.g., connection_id), or what happens when a breakpoint is set or removed. It does not contradict annotations, but provides minimal 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. However, it is under-specified in content, though concise in structure.
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 tool's 7-parameter complexity and lack of annotations/output schema, the description is insufficient to understand prerequisites (connection_id), return behavior, or how breakpoints integrate with script execution. It does not explain the set/remove lifecycle.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter descriptions, so baseline is 3. The description does not add any parameter-level meaning beyond what the schema already provides; the action enum is self-explanatory from the description.
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 'Set or remove' with the resource 'breakpoints', clearly identifying the tool's dual operation. It distinguishes from sibling debugging tools like 'step', 'evaluate', and 'call_stack'.
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 'set' vs 'remove', or how this tool relates to other debugging tools like 'pause_on_exceptions'. The description lacks any usage context or 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state side effects, such as whether switching disconnects the previous active connection or whether it requires an existing connection. The description essentially restates the tool's name without adding meaningful 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?
One sentence with zero redundancy. It is concise and directly states the action, making it 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?
Given the tool's simplicity (one parameter, no output schema), the description is minimally sufficient. However, it lacks context about its relationship with chrome_list_connections and chrome_disconnect, and does not clarify that connection_id must reference an existing connection.
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 parameter (connection_id) with a clear description. The tool description does not add any additional parameter semantics beyond the schema, 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 uses a specific verb ('switch') on a specific resource ('active Chrome connection'), which distinguishes it from sibling tools like chrome_connect and chrome_disconnect. However, it does not explicitly mention the role of connection_id in the switching action, slightly limiting full 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?
The description provides no guidance on when to use this tool versus alternatives like chrome_connect or chrome_list_connections. It omits prerequisites, such as the need to have an existing connection or how this differs from connecting/disconnecting.
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 disclosing effects. It only states what the tool does, omitting important details like whether the setting persists, how it affects the debugging session, or that it may pause execution. The connection_id parameter is not mentioned at all.
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 redundancy. It immediately conveys the tool's purpose and earns its place, though it is minimal.
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 configuration tool, the description plus schema provides adequate functional detail. However, it lacks context on when to use the tool relative to other debugging tools and does not explain the effect of each state value beyond the enum names, making it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents the state enum and connection_id. The description adds no additional meaning beyond the schema, 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 uses a specific verb ('Configure') and names the resource ('whether to pause when exceptions are thrown'), clearly stating the tool's function. It distinguishes itself from sibling debugging tools like breakpoint and step, though it does not explicitly mention alternatives.
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. The description lacks context about prerequisites (e.g., needing an active Chrome connection) or scenarios where adjusting exception pause behavior is appropriate.
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 only states the action without revealing any behavioral traits such as persistence, side effects, permissions, or scope. For a tool that modifies visibility state, this lack of detail is a notable 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, concise sentence that conveys the essential purpose without unnecessary verbosity. It is appropriately sized for the tool's simplicity, with the parenthetical 'restore' adding clarity.
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 simple nature of the tool and the schema's full parameter coverage, the description provides the minimal necessary context. However, it lacks any mention of return values, additional behavior, or how it interacts with hide_tools, making it only minimally complete for an agent with no other context.
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 both parameters (all and tools) with clear descriptions. The description adds no additional parameter semantics, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: showing or restoring hidden tools. The verb 'show/restore' and resource 'hidden tools' are specific. It implicitly differentiates from the sibling 'hide_tools' as the inverse operation, though it does not explicitly name the 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 usage guidance is provided. The description does not state when to use this tool vs. hide_tools or any other sibling, nor does it mention any prerequisites or exclusions. The agent is left to infer context from the name and description.
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 the key behavior of launching or connecting with remote debugging, but it does not mention side effects like starting a new process, the meaning of connection_id, or what happens after a successful connection. It adds some context but lacks depth.
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, immediately front-loaded with the verb 'Connect/launch', and contains no filler. Every word contributes to the core purpose, 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?
Given the tool's role as a gateway to other operations (query_elements, navigate, etc.), the description is incomplete. It does not explain that this establishes a debugging session used by sibling tools, nor how connection_id relates to future tool calls. The absence of output schema and annotations increases the burden, and the minimal description leaves critical context unstated.
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 parameters, so the baseline is 3. The description does not add significant parameter-level detail beyond what the schema already provides, though it does align with the 'action' parameter. It doesn't explain the role of connection_id or action-specific restrictions beyond what schema descriptions already state.
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 it connects to existing Chrome/Electron or launches a new instance with remote debugging, using specific verbs and a resource. It distinguishes itself from sibling tools like 'chrome_list_connections' by being the entry point, though it does not explicitly differentiate from 'electron_connect' or 'electron_setup'.
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 'electron_connect' or 'chrome_list_connections'. It simply states what it does without mentioning exclusions, prerequisites, or alternative scenarios, leaving the agent without decision 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?
No annotations are present, so the description must carry the full behavioral burden. It mentions that the app must be 'running' and that it connects to both ports, but it doesn't disclose potential side effects, whether it requires configuration, or what happens on failure. It lacks detail on connection lifecycle.
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 directly states the tool's purpose without wasted words. It is appropriately front-loaded.
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 that establishes a connection, the description is sparse. It doesn't mention what the connection is used for, how it interacts with later commands, or what output to expect. Given the complex sibling ecosystem (v8, chrome, connection managers), more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with clear parameter descriptions, and the tool description adds no additional semantic information beyond what the schema provides. 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 clearly states the verb 'Connect' and identifies the resource as a running Electron app on both CDP and V8 Inspector ports. This distinguishes it from sibling tools like v8_connect (which only handles V8) and chrome (which handles Chrome).
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 v8_connect or chrome. It doesn't mention that it should be used after electron_setup or that it combines both CDP and V8 connections into one step.
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 full burden. It discloses the primary action ('start capturing') but omits behavioral traits such as idempotency, side effects on existing captures, reversibility, or what happens if no connection is active. The description is not misleading but is too sparse.
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 clearly states the core action. Every word earns its place, with no unnecessary filler or repetition of the name.
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 state-changing tool with no annotations and no output schema, the description is incomplete. It does not explain prerequisites (active connection), effects on prior captures, or how to retrieve what is captured. The sibling tools hint at a workflow, but this description does not connect to it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for the single parameter (connection_id described as 'Chrome connection to use'). The description adds no extra parameter meaning and even introduces potential ambiguity by saying 'current connection' instead of referencing the parameter, but the schema itself is clear, 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 action ('Start capturing network requests') with a clear resource ('network requests') and scope ('for the current connection'). This clearly distinguishes it from siblings like get_network_requests (retrieval) and clear_network_requests (clearing).
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 explicit guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The intended usage is implied by the name/action, but there is no mention of needing an active connection or that captured data can be retrieved via get_network_requests.
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 only mentions the paused requirement, omitting crucial details such as potential side effects of arbitrary JavaScript execution, error behavior, or what happens if not paused. This is insufficient for a code-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?
The description is two sentences, front-loaded with the core action and the critical paused constraint. Every word earns its place, with no redundancy or unnecessary detail.
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 three parameters, no output schema, and no annotations. The description is minimal and leaves gaps around return format, the role of connection_id, and how it differs from sibling evaluation tools like renderer_evaluate and v8_evaluate. This is incomplete for an agent to select and invoke the tool correctly in context.
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 with descriptions for all three parameters (expression, call_frame_id, connection_id), so the schema already carries the parameter documentation. The description adds no extra semantic value beyond referencing 'specific call frame,' which is already captured in the call_frame_id parameter description. 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 evaluates JavaScript in a call frame, using a specific verb and resource. It also notes the paused requirement, which adds specificity. However, it does not explicitly differentiate from sibling tools like renderer_evaluate or v8_evaluate, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a key usage condition ('Only works when paused') but offers no guidance on when to select this tool over alternatives such as renderer_evaluate or v8_evaluate. The usage context is implied through the call frame and paused requirement, but explicit exclusions or alternative recommendations are absent.
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 carry the behavioral disclosure burden, but it only states the literal filler action. It does not clarify whether existing text is replaced, whether input events are triggered, how indexing works (though schema explains), or any side effects. 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, front-loaded sentence with no unnecessary words. It directly opens with the verb and includes the key selector concept, making it highly efficient and scannable.
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 tool has 5 parameters including index, submit, and connection_id, and no output schema, the description is too thin. It ignores the richer behavioral context (e.g., pressing Enter, multiple matches) and provides no guidance for how to use the tool effectively in automation scenarios.
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%, so the baseline is 3. The description itself adds no parameter semantics beyond what the schema already documents — it merely restates the 'text' parameter. Since it does not introduce additional meaning, a 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 action ('Fill text'), the target ('an input element'), and the locating mechanism ('matching the CSS selector'). It distinguishes from siblings like click_element by specifying the fill action, making the purpose 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?
No usage guidance is provided — the description does not mention when to prefer this tool over query_elements, click_element, or other interaction tools. It lacks any context about prerequisites, typical workflows, or alternatives, leaving the agent to infer 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?
With no annotations, the description carries the full burden of behavioral disclosure. It only states what the tool does, without describing return format, non-destructive nature, or the source of captured requests. This is a significant transparency gap for a network inspection 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, front-loaded sentence with zero unnecessary words. It effectively communicates the core action and a key feature (filtering) in a highly concise manner.
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 annotations and no output schema, placing the burden on the description. It omits important context like when to use it, prerequisites, and what the returned data looks like. This makes it under-specified for reliable tool selection and 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%, so all parameters are documented. The description's 'optional filtering' is a general summary that adds little beyond the schema, such as details about limit behavior or connection_id semantics. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('List') and resource ('captured network requests'), and adds 'optional filtering' to hint at parameters. This distinguishes it from sibling tools like enable_network and clear_network_requests.
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 or how it relates to alternatives. There's no mention of prerequisites (e.g., enabling network capture) or contrasts with sibling tools like clear_network_requests, leaving the agent to infer usage 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 the full burden, but it is minimal. It does not disclose whether hiding is reversible, how patterns are matched (regex vs glob), what happens if both 'tools' and 'pattern' are provided, if at least one parameter is required, or what the outcome of hiding is (e.g., session-only, affecting agent's visible tools). This lack of detail prevents the agent from understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that clearly conveys the core purpose without redundant words. It is appropriately short for a simple tool 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?
The description is incomplete for an agent to use the tool correctly. It does not specify intended usage constraints, such as whether at least one of 'tools' or 'pattern' must be provided, how pattern matching is evaluated, or any side effects. Given the absence of an output schema and annotations, the description should provide more operational context, but it does not.
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 descriptions for 'tools' and 'pattern' are explicit ('Specific tool names to hide' and 'Pattern to match tool names'), so schema coverage is 100%. The overall description adds no additional meaning beyond what the schema already provides, but it does not omit any parameter details either, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'hide' with the resource 'tools' and the two methods: 'by pattern or specific names.' This distinguishes it from sibling tools like 'show_tools' and other unrelated tools in the list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention the sibling tool 'show_tools' as a counterpart, nor does it explain any context or prerequisites for hiding tools. The usage is only implied by the tool's 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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the core actions and does not mention side effects (e.g., switching the active target affects subsequent commands), output format, or any requirements like an active Chrome connection. This is a significant gap for a tool that can mutate 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 sentence with no filler or redundant wording. It is front-loaded with the key verbs and resource, making it quick to parse. Every word earns its place.
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 tool has 5 parameters, no annotations, and no output schema, the description is too brief to be contextually complete. It does not explain return values, how to choose between list and switch, or any dependencies (e.g., needing a prior connection). The high-level overview leaves significant gaps for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, meaning all parameters are already documented in the input schema. The description does not add any additional parameter-level context, such as how 'url', 'index', and 'title' interact for the 'switch' action. It meets the baseline but does not exceed it.
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: 'List or switch browser targets (pages, workers).' It uses specific verbs (list, switch) and identifies the resource (browser targets), with a parenthetical that clarifies the scope (pages, workers). This distinguishes it from sibling tools like 'navigate' or 'query_elements' which target different aspects of browser interaction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It simply lists the two actions without explaining contexts, prerequisites, or exclusions. For example, it doesn't mention that switching requires an existing connection or how this tool relates to sibling tools like 'chrome_switch_connection'.
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 disclosing side effects and prerequisites. It only states the core action without mentioning that this establishes a persistent connection, requires the target to have --inspect enabled, or how multiple connections are managed using connection_id.
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 gets straight to the point with no redundant words. It is front-loaded with the verb and clearly states the target.
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 output schema and annotations, the description is incomplete for a connection tool. It does not explain the connection lifecycle, the role of connection_id, or how this connects to sibling tools like v8_evaluate and v8_disconnect, leaving the agent without necessary operational context.
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 having clear descriptions in the schema. The tool description adds no additional parameter context, so the baseline 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 ('Connect') and the specific resource ('V8 Inspector endpoint on a running Electron main process'). This distinguishes it from sibling tools like v8_disconnect or chrome_list_connections, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as electron_connect or the chrome_* family. There are no explicit prerequisites, exclusions, or reference to related tools, so the agent must infer usage from 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, the description bears full responsibility for disclosing behavior. It only states 'click an element' without revealing what happens if no element matches, whether it waits for the element, or if it throws an error. This lack of detail is a significant gap for a state-changing action.
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 concise and front-loaded with the action. It contains no unnecessary words or repetition.
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 click operation, the core purpose is sufficiently conveyed. However, the lack of usage guidance and behavioral details (e.g., error handling, waiting behavior) leaves gaps that a more complete description could fill, especially given the absence of annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides full descriptions for all three parameters, including the default for index. The description adds no extra parameter semantics 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 clearly states the action ('Click') and the resource ('an element matching the CSS selector'), which is specific and distinct from sibling tools like fill_element and query_elements. It accurately captures the tool's core functionality.
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. It does not mention prerequisites, such as having an active Chrome connection, or when to prefer query_elements or fill_element instead. The description only states what it does, not when to use 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 only states the action without revealing side effects, return behavior, or whether the disconnect is destructive to other connections. This leaves the agent without critical safety context for a mutating 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, front-loaded sentence with zero superfluous words. It conveys the core purpose efficiently and is well-structured for quick agent parsing.
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 (one required parameter, no output schema), the description is minimally viable. However, it lacks usage guidance and behavioral consequences, leaving gaps that could affect correct selection and invocation in broader workflows. It is 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 fully describes the single parameter connection_id with the description 'V8 connection to disconnect', achieving 100% schema 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Disconnect a V8 Inspector connection' clearly states the action and resource, distinguishing it from sibling tools like v8_connect and v8_list_connections. The verb 'disconnect' and resource 'V8 connection' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 chrome_disconnect or v8_list_connections. There are no prerequisites, no mention of cleanup workflows, and no 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?
No annotations are provided, and the description does not disclose any behavioral details such as side effects, prerequisites beyond 'paused', or behavior for each direction value. It is very minimal and leaves the agent without information about what happens if not paused or how the direction affects execution.
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 short sentence, seven words, with no filler or redundant information. Every word adds value, making it 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?
The description is extremely minimal for a tool with a required enum parameter and optional connection_id, no output schema, and no annotations. It does not explain the meaning of direction values or when connection_id should be provided, leaving significant gaps for 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?
Schema description coverage is 100% (both direction and connection_id have descriptions), so the schema carries the parameter semantics. The tool 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.
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: stepping through code execution specifically when paused. The verb 'step' and resource 'code execution' are specific, and the condition 'when paused' adds context. It distinguishes well from sibling tools like breakpoint, call_stack, and evaluate.
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 paused, which is a clear context, but it does not explicitly mention when to use this tool vs alternatives. No exclusions or alternative tool references are provided.
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 must disclose behavioral traits on its own. It does mention that the tool waits for page load, which is useful, but it omits important details such as whether an existing connection is required, the effect of navigation on the current page, timeout behavior, or error handling. This leaves significant behavioral ambiguity 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 that is front-loaded with the action and includes a relevant detail about waiting for page load. There is no filler, redundant information, or unnecessary length.
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 simple nature of the tool (two parameters, no output schema), the description covers the core purpose and a key behavior, but it omits references to connection handling, possible return values, or failure modes. While the schema covers parameters, the description is still minimal and could benefit from mentioning prerequisites or side effects.
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 covers both parameters (url and connection_id) with 100% description coverage, so the schema already provides full parameter semantics. The tool description adds no additional meaning beyond stating the action, thus the baseline 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 uses the specific action 'Navigate to a URL' and adds a key behavioral detail 'wait for page load,' which clearly differentiates it from sibling tools like click_element or evaluate. It is precise about the resource (a URL) and the operation.
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 implicitly says this is for loading a URL and waiting, but it does not explicitly state when to prefer it over other tools (e.g., when to use a connection or how to handle multiple connections). No alternatives or exclusions are mentioned, so usage guidance is implied rather than explicit.
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 present, and the description does not disclose any behavioral traits such as whether it requires an active connection, what format the results take, or whether it has side effects. It merely restates the function name's meaning.
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?
It is a single, concise sentence that directly states the action with no wasted words.
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 trivial listing tool with no parameters and no output schema, the description is minimal but not entirely insufficient; however, it fails to mention what the returned connection details include or any operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (0 parameters), so the schema provides complete coverage; the description adds no parameter semantics since there are none to describe.
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 'list' and identifies the resource as 'V8 Inspector connections', clearly distinguishing it from sibling tools like chrome_list_connections due to the V8 prefix.
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; it only states what it does, with no mention of prerequisites or distinguishing use cases.
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. It mentions the key trait 'Does not require debugger pause' but fails to disclose potential side effects, safety implications of arbitrary code execution, return value structure, or prerequisite connections. This is a significant gap for a code 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?
The description consists of two concise sentences that are immediately informative and free of unnecessary words or repetition. It earns its place without wasting space.
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 moderate complexity of an arbitrary JavaScript evaluation tool, the description is too sparse. It lacks information about return values, error handling, side effects, and prerequisites beyond what the schema provides. No output schema or annotations compensate for this shortfall, leaving the tool under-specified for an AI 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 covers both parameters with descriptions, and the description adds the context that the expression runs in the renderer process, which enriches the meaning of the 'expression' parameter. However, it does not add further detail about 'connection_id' or the exact evaluation semantics, so baseline 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 evaluates JavaScript in the renderer process, which is a specific verb+resource combination. The phrase 'Does not require debugger pause' differentiates it from sibling evaluate tools, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this tool for evaluating JavaScript in the renderer process, and it explicitly notes that no debugger pause is required. However, it does not mention alternative tools by name or provide explicit when-not-to-use scenarios, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It indicates a read-only operation ('List') and specifies the scope ('active') and output ('status'), but it doesn't elaborate on side effects, prerequisites, or the nature of the returned data. This is minimal but not misleading.
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 states the action and scope without any redundancy or fluff.
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?
There is no output schema, so the description should explain the return structure (what 'status' looks like, how connections are identified). It doesn't, leaving some ambiguity. For a zero-param list tool, it's adequate for selection but incomplete for full invocation understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema fully covers all parameters. The description doesn't need to add parameter context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'active Chrome connections with their status'. This uniquely identifies the tool and differentiates it from sibling tools like v8_list_connections and chrome_disconnect.
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. It simply states what it does, leaving the agent to infer usage context from sibling tool names alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates the call stack is only available when paused, implying a safe read operation, but doesn't disclose behavior when execution is not paused or potential errors. For a simple getter, this is adequate but not rich.
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 with no wasted words. It front-loads the verb and object, then adds a necessary context clause.
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 read tool with one parameter and no output schema, the description covers the essential purpose and condition. It could mention the return format or error behavior, but the tool's simplicity means the description is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the single parameter 'connection_id' has a description), so the description doesn't need to add parameter detail. It does not mention the parameter, but the schema fully documents it.
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 ('Get') and resource ('current call stack'), plus the context ('when execution is paused'). This distinguishes it from siblings like 'evaluate' or 'step'.
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 gives clear context for when to use this tool — when execution is paused — without explicitly naming alternatives or exclusions. It implies usage alongside pause/step commands but doesn't explicitly contrast with siblings.
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 burden of disclosing behavior. It adds the ordering requirement (must be called before breakpoints/stepping), which is useful behavioral context beyond the tool's name. However, it does not explain side effects, idempotency, or connection requirements, leaving significant gaps for a state-changing tool. The added disclosure is minimal but present.
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 two clauses: it states the primary action and the key prerequisite. Every word earns its place; there is no redundancy or fluff. It is front-loaded with the verb and resource, making it highly scannable.
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 (one optional parameter, no output schema), the description covers the essential purpose and the critical usage ordering. It does not explain what happens when the debugger is enabled or whether a connection is required, but the schema covers the parameter, and sibling tools suggest a connection context. It is reasonably complete for a low-complexity tool, but lacks some contextual detail that would make it fully self-contained.
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 documents the only parameter, connection_id, with the description 'Chrome connection to use.' The tool description itself adds no additional parameter semantics. Since schema coverage is 100%, 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 clearly states the tool's function: 'Enable JavaScript debugger.' This uses a specific verb and resource, and the added note 'Must be called before breakpoints or stepping' distinguishes it from sibling debugging tools like breakpoint and step by establishing its role as a prerequisite. This 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context by stating 'Must be called before breakpoints or stepping,' which tells the agent when this tool should be used relative to other debugging actions. It does not explicitly name alternatives, but the prerequisite relationship is strong and actionable. It lacks exclusions or alternative tool references, so it's a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly states that it finds an app, generates a command, and returns the exact command to run, implying it does not launch the app itself. It also specifies the search location (/Applications), which is a useful behavioral constraint. However, it does not mention potential side effects or error behavior, keeping it from a perfect score.
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 that are direct and informative. The first sentence states the primary action and purpose, and the second clarifies the output. There is no redundant or fluff content, and it is appropriately front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three parameters, no output schema, and no annotations, the description adequately covers the tool's purpose, its input context, and the nature of its return value ('exact command to run'). It does not specify the format of the returned command or what happens if the app is not found, but these are relatively minor gaps given its simplicity. With no output schema, the description's mention of the return value helps fill that void.
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 all three parameters (app_name, v8_port, cdp_port) having descriptive text. The description itself does not add additional meaning about the parameters, such as how they map to the debugging flags or how the ports are used, but it does state the overall purpose of generating a command with debugging flags. The baseline for high schema coverage is 3, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: find an Electron app in /Applications and generate a launch command with debugging flags. It uses specific verbs ('Find', 'generate') and identifies the resource (Electron app) and the outcome (launch command with debugging flags). This distinguishes it from siblings like electron_connect which likely attaches to a running app, and chrome which handles Chrome specifically.
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 its usage: when you need to set up an Electron app for debugging by generating a launch command. It clearly indicates the context (finding the app in /Applications) and that it returns the command rather than executing it. However, it does not explicitly state when not to use it or name alternatives like electron_connect, leaving room for a higher score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It indicates a read-only operation via 'Find' and 'Returns,' and specifies the output fields (tag, text, id, classes, visibility). It does not mention error cases or connection specifics, but the core read behavior is clear.
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 concise sentences: one for purpose and one for return values. It is front-loaded with the primary action and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple query tool with a well-covered schema, the description provides sufficient information about what the tool does and what it returns. It lacks explicit read-only confirmation and edge-case behavior, but is adequate given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% parameter coverage, so the baseline is 3. The description adds slight context by mentioning 'DOM depth filtering,' which aligns with max_depth, but doesn't elaborate on limit or connection_id beyond what the schema already provides.
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: 'Find elements by CSS selector with DOM depth filtering.' This specifies a verb ('Find'), a resource ('elements'), and a method (CSS selector), distinguishing it from mutation tools like click_element and fill_element.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that the tool is for querying elements, as opposed to interacting with them. It doesn't explicitly name alternatives or exclusions, but the purpose is evident from the phrasing.
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 full behavioral burden. It reveals an informational/read-only nature via the verb 'Show', but it does not specify the output format or whether it returns a list vs prints instructions. No contradictions exist, and the behavior is straightforward for a help 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 one sentence, front-loaded with the verb and resource, and contains zero unnecessary words. It is immediately understandable and stays within a compact length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a trivial help tool with no parameters and no output schema, the description fully covers what the tool does. It explains the subject (Electric Cherry) and the scope (across different tools), leaving no significant gaps for an agent to select and invoke it 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 has zero parameters, so there is nothing to document. The baseline for 0-parameter tools is 4, and the description adds no parameter-related noise, making it 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 ('Show'), names the resource ('install instructions for Electric Cherry'), and clarifies scope ('across different tools'). It clearly distinguishes this from sibling setup/debug tools by indicating it provides instructions rather than performing operations.
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 the tool should be used when install instructions are needed, but it does not explicitly contrast with any sibling tool or state when not to use it. Since no other help/instruction tool exists among the siblings, the context is clear but lacks explicit alternatives.
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:

[![electric-cherry MCP server](https://glama.ai/mcp/servers/brandon-fryslie/electric-cherry/badges/card.svg)](https://glama.ai/mcp/servers/brandon-fryslie/electric-cherry)

Score Badge

Copy to your README.md:

[![electric-cherry MCP server](https://glama.ai/mcp/servers/brandon-fryslie/electric-cherry/badges/score.svg)](https://glama.ai/mcp/servers/brandon-fryslie/electric-cherry)

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/brandon-fryslie/electric-cherry'

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