scout-mcp-server

by stemado

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v1.8.1
Disambiguation5/5
Each tool has a clearly distinct purpose, from session management (launch/close) to interaction (click/type), page reconnaissance, network monitoring, downloads, video recording, scheduling, and security. No two tools overlap in function; even similar actions like browse and scout_page_tool operate in different contexts (standalone vs. session).
Naming Consistency4/5
Most tools follow a verb_noun pattern (e.g., allow_navigation, check_extension, execute_javascript). However, a few deviate: the schedule tools use noun_verb (schedule_create), and some tools have a 'tool' suffix (execute_action_tool, inspect_element_tool) while others do not. This minor inconsistency prevents a perfect score but does not hinder readability.
Tool Count5/5
With 21 tools, the server strikes an excellent balance between comprehensive capabilities and manageable scope. Each tool addresses a specific need in web automation, and the count feels well-calibrated for a tool server that handles sessions, interactions, media, scheduling, and security.
Completeness5/5
The tool surface covers the full lifecycle of web automation: session control, navigation, element interaction, JavaScript execution, page analysis, screenshots, video recording, network monitoring, download processing, 2FA, security auditing, and scheduling. There are no obvious gaps; agents can accomplish complex workflows without resorting to workarounds.
Average 4.2/5 across 21 of 21 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- Last stable release on March 24, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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?
The description mentions OS coverage (Windows, macOS, Linux) and namespace, but lacks details on return format, performance, permissions, or error conditions. Since no annotations are provided, the description should carry more behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and contains no extraneous words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's scope and OS support, but lacks output format details. Since there is no output schema, the description should at least hint at what a task object contains (e.g., name, trigger).
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?
Tool has no parameters (0 params, 100% schema coverage), so baseline is 4. The description does not need to add parameter details, but it could mention that no arguments are required.
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 specifies 'List all SCOUT scheduled tasks on this machine', clearly stating the verb (list), resource (SCOUT scheduled tasks), and scope (on this machine). It also distinguishes from siblings schedule_create and schedule_delete by focusing on listing only.
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 this tool is for viewing existing tasks, and siblings are for create/delete. However, it does not explicitly state when to use this tool versus alternatives, leaving it implicit.
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 burden. It describes the return value but does not explicitly state that the tool is read-only or has no side effects. Mention of 'installation instructions' hints at non-modifying behavior, but it could be more transparent about safety and prerequisites.
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 with no fluff. Each sentence adds value: the first states the purpose, the second details the return information. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters, no output schema, and no annotations, the description is fairly complete. It covers what the tool does and what it returns. However, it could mention prerequisites (e.g., the extension must be installed) or error conditions for slightly better completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to add parameter info. According to guidelines, baseline for 0 parameters is 4, which is appropriate here as the description adds no parameter semantics but doesn't need to.
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 and specifically states the tool checks the status of the Scout Chrome extension connection, and lists what it returns (relay server status, connection status, installation instructions). It is distinct from sibling tools which focus on browsing and automation tasks.
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 does not explicitly state when to use this tool versus alternatives. While it is implied that it should be used to verify extension connectivity before other actions, no explicit usage context or exclusions are provided. This is adequate but lacks guidance.
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 that the tool returns events but does not mention whether it is read-only, any side effects, authentication requirements, rate limits, or data freshness. The description is minimal and lacks transparency into the tool's behavior beyond the basic return.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: three short sentences plus a structured 'Args' section. Every sentence adds value (purpose, usage guidance, parameter details). There is no redundant or extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema, the description should describe the return value format or structure. It only says 'Return recent security events' without specifying what fields or structure each event has. For a simple tool, this is adequate but not fully complete. The parameter documentation is good, but the return type is underspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, meaning none of the parameters have descriptions in the schema itself. The tool's description compensates fully by documenting all three parameters (session_id, severity, limit) with their semantics, valid values, and defaults. This provides essential meaning that the schema alone does not convey.
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 returns recent security events from the Scout security log, which is a specific verb and resource. It also provides a concrete use case (auditing sessions before workflow export), distinguishing it from sibling tools like 'get_session_history' which likely return different data.
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 explicit guidance on when to use the tool: for auditing a session before exporting a workflow, especially if there are injection attempts. This tells the agent the context of use. However, it does not indicate when not to use it or mention alternative tools, so it is not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must cover behavioral traits. It describes the output contents in detail but does not disclose whether the tool is read-only, requires authentication, or has side effects. The name implies retrieval, but explicit behavioral traits are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a minimal args line. Front-loaded with purpose; every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one required parameter and no output schema, the description adequately explains the output contents. It could hint at the data format (e.g., JSON), but the listed contents provide enough 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?
Schema has 0% description coverage, but the description adds meaning: 'Session ID (active or recently closed).' This clarifies the parameter's scope beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Return' with a clear resource 'complete structured history of a browser session.' It lists detailed contents (actions, scout reports, network events, URLs), distinguishing it from sibling tools like close_session or launch_session.
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?
States a specific use case: 'Use this data to compose botasaurus-driver scripts.' However, it does not mention when to avoid using this tool or provide alternatives among 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, the description carries the full burden of behavioral transparency. It correctly states that the tool deletes the schedule but leaves workflow files untouched. However, it omits details on required permissions, side effects, or error handling, which limits transparency for a deletion 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 remarkably concise and well-structured. It starts with a clear verb+resource statement, then breaks into specific OS support and a crucial caveat, followed by a simple parameter listing. Every sentence serves a purpose without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, no output schema, no annotations), the description covers the essential aspects: purpose, scope, and what it does not do. It lacks details on return values or error states, but for a straightforward deletion tool, it is mostly 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 has 0% schema description coverage for the 'name' parameter. The description's Args section adds minimal value by restating 'Name of the scheduled task to delete.' While this clarifies the parameter's purpose, it does not provide additional semantics like format, constraints, or examples, resulting in a 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 tool's purpose: 'Delete a scheduled task from the OS task scheduler.' It specifies the OS-specific schedulers (Windows Task Scheduler, macOS launchd, Linux cron) and emphasizes it does not delete workflow files, distinguishing it from related sibling tools like schedule_create and schedule_list.
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 context on when to use the tool by clarifying that it only removes the schedule, not the workflow files. Although it does not explicitly state alternatives or when not to use, the information is clear and adequate for an agent to decide based on the sibling tool names (e.g., schedule_create, schedule_list).
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 reveals critical behaviors: the server reads from .env, types directly into the element, and the secret never appears in parameters or responses. This is good transparency, though it could mention potential failure modes or idempotency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-line summary, a brief mechanism paragraph, and a bulleted parameter list. Every sentence adds value, no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given six parameters and no output schema, the description covers purpose, mechanism, and all parameters adequately. It lacks explicit mention of the return value, but the output is likely a success indicator. Still, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does so by explaining all six parameters in the Args section, including purposes and defaults (e.g., clear_first defaults to true, wait_after defaults to 500 ms). This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: type a secret value from .env into a form field without exposing it in the conversation. It specifies the action (type), resource (form field), and the key privacy feature, distinguishing it from sibling tools like get_2fa_code.
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 explicit guidance on when to use this tool versus alternatives. The description implies usage for securely entering secrets but does not contrast with other tools like execute_javascript or fill_form. Missing when-not criteria.
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 full burden. It implies a non-destructive reconnaissance operation but does not explicitly state it is read-only or safe. It explains the return type and detail levels but lacks disclosure of any side effects or permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear one-line summary followed by bullet points for arguments. It prioritizes the main purpose and provides necessary details without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters and no output schema, the description adequately covers the input parameters and general output (structural overview). It references a sibling tool for specific searches, making it contextually complete for an AI agent to understand when and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, so the description adds significant value by explaining the purpose of each parameter: session_id (from launch_session), focus_frame (optional iframe CSS selector), and detail_level with two enumerated options ('summary' vs 'full') and their implications on response size.
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 ('Perform deep reconnaissance on the current page state') and clearly defines the output (structural overview with metadata, iframe hierarchy, shadow DOM boundaries, element counts). It also distinguishes from sibling 'find_elements' by directing the agent to use that tool for searching specific elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool (for structural overview) and references the alternative 'find_elements' for specific searches. However, it does not discuss when not to use it or mention any prerequisites beyond having a valid session_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses HTTP default with stealth browser fallback, but does not mention rate limits, auth requirements, or handling of dynamic content. Adequate but not comprehensive.
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?
Very concise: two lines for purpose/context, then bulleted arg descriptions. No wasted words, easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and 0% schema coverage, description covers core functionality and parameter usage. Output schema exists to handle return values, so omission of response format is acceptable. Could mention supported content types or limitations, but overall complete for a simple fetch tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description explains all three parameters clearly: url (target), query (filter), max_length (character cap). Adds value beyond schema titles and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Fetch a web page and extract its content as clean markdown.' Differentiates itself from sibling 'scout_page_tool' by calling itself a 'Lightweight alternative to the full Scout session flow.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context for when to use (lightweight single call vs full session) and describes fallback behavior for bot-protected pages. Lacks explicit exclusions but covers key usage scenarios.
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 explains return value behavior (last expression returned, explicit return works) and the frame_context parameter. However, it lacks disclosure about potential side effects, security risks, or error handling for arbitrary script 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 concise: two short paragraphs plus an Args list. It front-loads the purpose and usage, then provides parameter details. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return value (last expression or explicit return). It covers the key parameters and usage context. However, it could mention error handling or prerequisites like a valid session.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% coverage, so the description must compensate. The 'Args' section explains each parameter: session_id (active session ID), script (code to execute with return semantics), and frame_context (iframe selector path). This adds significant meaning beyond the schema's types and required status.
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 executes arbitrary JavaScript in the page context and returns the result. It lists specific use cases (debug click failures, read shadow DOM, etc.) and differentiates from siblings by noting it covers operations not handled by other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: for debugging clicks, reading shadow DOM, etc., and implies it's for operations not covered by other tools. However, it does not name specific sibling alternatives or provide explicit 'when not to use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and does well: it explains the mechanism (CDP screencast), encoding options (MP4/GIF), fallback behavior if ffmpeg is missing, and the effect of each command. However, it omits edge cases like overlapping start/stop calls and does not describe the return value (e.g., status command output).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a summary line, a mechanism paragraph, and an Args list. It is appropriately sized for 7 parameters, but the prerequisites sentence could be integrated more concisely. No wasted words overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers purpose, parameters, and behavior well. It explains encoding details and defaults. However, it lacks return value descriptions for commands like 'status' and does not mention concurrency or error states, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. Each parameter is explained with defaults and additional context (e.g., output_format details 'GIF uses palette-optimized encoding at 10fps/800px width'), adding significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Control video recording for the current browser session' with specific verb 'record' and resource 'video recording'. It distinguishes from sibling tools like take_screenshot_tool by focusing on video rather than static images, and further details the commands (start, stop, status).
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 through the commands and mentions prerequisites (ffmpeg), but lacks explicit guidance on when to use this tool over alternatives (e.g., take_screenshot_tool). It does not provide 'when not to use' or direct comparisons, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses key behaviors: generating platform-specific run scripts, registering with OS schedulers, and parameter formatting rules. It does not detail error conditions or side effects like overwriting, but covers the core behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear purpose statement followed by an Args section. It is slightly verbose but every sentence adds value. Could be more concise, but remains effective.
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?
All 5 parameters are described with usage details. There is no output schema, so the description is adequate. It could mention success/failure behavior, but given the parameter count and complexity, it covers the necessary information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully bears the burden. It explains each parameter's purpose, constraints (e.g., 'weekday names for WEEKLY', 'HH:MM 24-hour format'), and required conditions (days mandatory when schedule=WEEKLY). This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create or update a scheduled task for an exported SCOUT workflow.' It also describes the specific actions (generating a run script, registering with OS scheduler). This distinguishes it from siblings like schedule_delete and schedule_list.
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 parameter constraints (e.g., days required for WEEKLY, time format) but does not explicitly guide when to use this tool versus alternatives. No when-not or comparative usage context is given.
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?
States it releases all resources, implying cleanup and side effects. With no annotations, it adequately conveys the behavioral impact, though could mention irreversibility.
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?
Very concise with a clear structure: action instruction, usage note, and parameter listing. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers action and usage for a simple close operation. Could add details about session persistence but is sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description merely repeats the parameter name and basic purpose from the schema. With 0% schema coverage, no additional context like format or source is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool closes the browser session and releases resources. It distinguishes from sibling tools like 'launch_session' which is the opposite action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to call when automation exploration is complete, providing clear context of use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description itself must cover behavior. It mentions 'single interaction,' scouting, and parameter roles, but does not disclose potential side effects (e.g., page navigation, state changes) or error handling. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: a one-sentence purpose, a crucial usage tip, then a bulleted argument list. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 6 parameters, no output schema, and no annotations, the description covers parameter usage and required conditions well. It lacks return value or error details, but for an action tool, the outcome is observable via scout. Slightly incomplete but acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates. It explains each parameter: session_id, action enum, selector requirement, value meanings, frame_context, and wait_after default. This adds critical meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Perform a single interaction in the live browser session' and lists supported actions (click, type, select, navigate, scroll, wait, etc.), distinguishing it from sibling tools like `scout_page_tool` or `execute_javascript`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises 'Always scout after executing an action to observe the result,' providing explicit post-action guidance. It implies when to use (single interactions) but does not explicitly contrast with alternatives like `fill_secret` or `execute_javascript`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the tool's behavior (search, return matching elements) and parameter details, but does not mention idempotence, performance implications, or lack of side effects. Without annotations, more transparency is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a concise intro paragraph followed by parameter descriptions. Some redundancy (e.g., 'Args' section could be more list-like), but overall efficient and front-loaded.
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?
Covers prerequisite, all parameters with details and defaults, and briefly describes return values. Despite no output schema, the description is sufficient for a tool with 6 parameters and moderate complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description fully compensates by explaining all 6 parameters: session_id required, query (case-insensitive substring match), element_types filter, visible_only default true, frame_context, max_results default 25. Adds meaning beyond types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Search for specific interactive elements on the current page' and lists returned data (selectors, text, attributes). It is specific and distinct from siblings like scout_page_tool and inspect_element_tool.
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?
Explicitly instructs to 'Call scout_page_tool first to cache the page structure, then use this tool to find specific elements', providing clear prerequisite context. However, it lacks explicit 'when not to use' or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must describe behavior. It mentions inspecting visibility, position, shadow DOM, overlays, etc., implying a read-only diagnostic tool, but it does not explicitly state that the tool does not modify the page or have side effects. The description is adequate but could be more transparent about safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two short paragraphs plus a list of parameters. The purpose is front-loaded ('Inspect a single DOM element in detail'), and every sentence adds value. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should hint at return values, but it does not mention what the tool returns (e.g., JSON with element properties). Also, it lacks details on error handling or performance. However, the main use cases and parameters are covered, making it mostly complete for the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description explains all 5 parameters with concise semantics. For example, frame_context: 'Use 'main' or omit for top-level', and defaults for include_listeners and include_children are noted. This helps the AI agent understand parameter usage, though more detail on what include_children returns would improve 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 verb 'Inspect' and the resource 'DOM element', and specifies the scope 'visibility, position, shadow DOM, overlays, and more'. It differentiates from sibling tools like 'find_elements' and 'scout_page_tool' by focusing on single element detailed inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit scenarios: 'diagnose why a click didn't work', 'check if an element is obscured by an overlay', 'verify shadow DOM context', or 'examine element state before interacting'. This gives clear usage guidance without needing to name alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the guard blocks by default and never auto-permits, and that the tool is for a single navigation. It does not mention idempotency or error conditions, but for a simple tool, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence for purpose, followed by a brief explanation. It is well-structured with no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema and 0% schema description coverage, the description covers purpose, usage guidelines, and basic parameter meaning. It lacks return value or error details, but is mostly complete for the 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 description coverage is 0%, so the description must add meaning. It briefly describes parameters: 'Active session ID' and 'The URL to permit navigation to.' This adds minimal semantics beyond the parameter names, but is acceptable for two simple params.
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: 'Permit a single cross-origin navigation that was blocked by the navigation guard.' It specifies the verb (permit), resource (cross-origin navigation), and context (extension mode), distinguishing it from siblings like browse or check_extension.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: 'Only needed in extension mode when allowed_domains is set and the agent navigates to an unlisted domain. The guard never auto-permits — this tool requires explicit agent invocation.' This provides clear context and exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden. It explains that 'wait_for_download' blocks, that 'capture_response_body' adds overhead, and the role of each command. However, it does not mention whether monitoring persists across page navigations or if there are side effects on session state.
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 structured with a two-sentence overview followed by a clear Args block. It is concise but could be slightly more structured (e.g., bullet points) for readability. No redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 params, no output schema) the description covers usage context and parameter meanings well. It explains what 'query' returns ('captured events') and that 'wait_for_download' blocks, but does not detail the structure of returned events. This is adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It provides thorough explanations for all 7 parameters, including defaults (e.g., timeout_ms=30000, capture_response_body=false) and functional descriptions (e.g., url_pattern as an optional regex filter). This adds significant value beyond the schema's type/title info.
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: 'Control network monitoring for the current session.' It explains the four commands (start, stop, query, wait_for_download) and differentiates from sibling tools like 'scout_page_tool' and 'take_screenshot_tool' by focusing on network request capture rather than page inspection or visual capture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Start monitoring before performing actions that trigger API calls or downloads, then query to see what was captured.' This tells the agent when to use the tool, but it does not explicitly state when not to use it or mention alternative tools for related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that screenshots are saved to disk, inline image vs file artifact, token cost (~1,600 tokens), and full_page limitation. Without annotations, this is strong transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a concise first paragraph and detailed but organized Args list. A bit lengthy but each sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers behavior, parameter details, and token trade-offs. Missing explicit return format (file_path) but given no output schema, it's fairly complete for a screenshot tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description includes an Args section explaining each parameter with defaults, usage details, and constraints, fully compensating for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool captures a screenshot of the current page. The verb 'Capture' and resource 'screenshot' are specific, and it distinguishes from siblings like record_video.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on when to set return_image=false to save tokens, and notes full_page may be incomplete with lazy-loaded content. However, no explicit when-not-to-use or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/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 explains format conversion, filename patterns, and directory handling, but does not detail side effects like file overwrite or error handling. Still, it gives adequate behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (about 10 lines) with a clear top-level purpose, a usage instruction, and a well-organized parameter list. Every sentence adds value, and it is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers usage and parameters well, but lacks information about return values or error behavior. For a tool with no output schema, this is a minor gap. Overall, it is fairly complete given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates fully by explaining each parameter in detail: session_id, source_format (with 'auto' and known formats), target_format, target_filename (with token examples), target_directory (UNC paths supported), and guid. This adds significant meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Process a downloaded file: convert format, rename, and move to destination.' It uses specific verbs and resources, distinguishing it from sibling tools which are unrelated (e.g., browse, close_session).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Call this after a download completes,' providing clear context. It does not mention when not to use it or alternatives, but the context is sufficient for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, description fully discloses persistence, anti-detection, profile lifetimes, proxy npm install caveat, allowed_domains scope, and localhost blocking.
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?
Structured with sections and bullet points, but verbose; could be slightly trimmed without losing key information.
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?
Comprehensive for a launch tool with 8 parameters and no output schema; covers lifecycle, security, and parameter interactions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema coverage, each of the 8 parameters is documented with defaults, valid formats, side effects (e.g., profile persistence, proxy warning), and usage 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 tool launches a browser session with anti-detection, and the sibling context includes close_session and browse, making its role distinct.
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?
Explicitly states session persists until close_session, and provides guidance on connection modes and proxy risks. Lacks explicit when-to-avoid scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavior: it polls Twilio API, extracts the code, does not expose credentials, and explains timeout and baseline state. This is comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a bold lead sentence, clear sections, and no fluff. Every sentence adds value, and the length is appropriate for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (polling, Twilio, regex), the description is complete. It covers purpose, parameters, prerequisites, behavior, and return. Output schema exists but description still explains extraction. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so description fully compensates. It explains 'app_keyword' with examples, 'code_pattern' with default and override, 'timeout' with default, and includes required .env entries. Adds significant meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch', the resource '2FA OTP code', and the context 'AFTER clicking Send Code'. It is specific and distinguishes from any sibling tools, none of which handle 2FA.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to call the tool ('AFTER triggering the 2FA send') and explains the polling behavior with Twilio latency. It lacks a 'when not to use' statement or explicit alternatives, but given the specialization, this is minor.
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:

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

Score Badge

Copy to your README.md:

[![scout-mcp MCP server](https://glama.ai/mcp/servers/stemado/scout-mcp/badges/score.svg)](https://glama.ai/mcp/servers/stemado/scout-mcp)

Latest Blog Posts

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

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/stemado/scout-mcp'

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