Skip to main content
Glama
brunoboto96

SceneScout

by brunoboto96
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

scout_press

Presses a keyboard key such as Escape, Tab, or Enter to close modals and test keyboard navigation in a live web app, so agents can verify focus order and dismiss overlays.

Instructions

Press a keyboard key (e.g. Escape, Tab, Enter) — useful for closing modals and testing keyboard navigation.

Input Schema

NameRequiredDescriptionDefault
keyYes
taskNoWhat you are DOING right now, in a few words: the action, not the acceptance criteria. "Filtering the documents register by status", "Filling the deviation form with invalid dates", "Signing in as QA_Team" — NOT "§2.4 filtering narrows the set and the filter is reflected in the URL", which is what you are CHECKING, not what you are doing. Naming the item you are on is fine ("§2.4: filtering the documents register"); keep the rest to what a colleague would see over your shoulder. It stays set until you pass a different one, so a batch costs a few words, not one per call. Required on the tools that act unless a journey or an earlier call already set one.
sessionNoTarget this session directly instead of the active one — pass it explicitly when dispatching to MULTIPLE sessions in one turn (e.g. two scout_click calls with different `session`), which then run CONCURRENTLY rather than queueing. Omit for single-session sequential use.
objectiveNoOld name for `task` (2.0). Prefer `task`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.31.0
    • removedInput schema / additionalProperties
      Removed value: -false
  2. Changed2 schema fields changedv3.4.0
    • addedInput schema / properties / objective
      Added value: +{
+  "description": "Old name for `task` (2.0). Prefer `task`.",
+  "maxLength": 120,
+  "type": "string"
+}
    • addedInput schema / properties / task
      Added value: +{
+  "description": "What you are DOING right now, in a few words: the action, not the acceptance criteria. \"Filtering the documents register by status\", \"Filling the deviation form with invalid dates\", \"Signing in as QA_Team\" — NOT \"§2.4 filtering narrows the set and the filter is reflected in the URL\", which is what you are CHECKING, not what you are doing. Naming the item you are on is fine (\"§2.4: filtering the documents register\"); keep the rest to what a colleague would see over your shoulder. It stays set until you pass a different one, so a batch costs a few words, not one per call. Required on the tools that act unless a journey or an earlier call already set one.",
+  "maxLength": 120,
+  "type": "string"
+}
  3. Addedv1.1.0

TDQS

B3.3/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose the observable effect (dismisses modals) and example key values. It says nothing about whether the target element must have focus first, whether modifier combos are supported, or what happens if the key is invalid, which are real failure modes for a keypress 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?

One front-loaded sentence with the action first, examples second, and rationale last. No filler, though the modal example and the navigational example are slightly redundant for such a small tool.

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

Completeness2/5

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

For a four-parameter tool with no annotations and no output schema, the description is thin: it omits focus requirements, whether the press is dispatched to the page or a specific element, and what the tool returns or reports. The schema covers the harness parameters, but the actual behavioral contract of pressing a key is underspecified.

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 75% and the richly documented task/session/objective parameters are already fully explained in the schema. The description's only added parameter value is clarifying that `key` expects a named key such as Escape/Tab/Enter, which is useful since that field has no schema description, but it never addresses multi-key sequences or modifiers.

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?

States a concrete verb and resource (press a keyboard key) and supplies representative values (Escape, Tab, Enter) so an agent immediately knows the operation. It does not distinguish itself from the nearest sibling, scout_type, which also sends keyboard input, so the boundary is left implicit.

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?

Gives two concrete situations where this is the right call: closing modals and testing keyboard navigation. It never says when NOT to use it or names scout_type/scout_click as alternatives, so the agent must infer that typing text belongs elsewhere.

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

Deploy Server

Other Tools