Skip to main content
Glama
brunoboto96

SceneScout

by brunoboto96
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

scout_request

Send requests to the app's own API as the current session to verify server-side authorization and prove that hidden or disabled controls are truly refused.

Instructions

Call the app's own API as this session, with the UI bypassed — the check that turns a hidden or disabled control into a proven refusal. A button that is not shown proves nothing; the same action refused by the server does. The fetch runs IN the page, so it carries the session's cookies and replays the Authorization header the app itself last sent, and it passes through the same interception the write policy is enforced on: in safe-write a mutation on a record this session did not create is refused here exactly as it would be for a click, and that refusal is the engine's safety net, not a finding. Returns the status line, the timing, the headers that decide whether two responses are truly identical (content-type, location, www-authenticate, retry-after, cache-control), and the body — its first 2000 characters, or the part named by select (one JSON value by path) or offset/limit (a window of characters). Unlike a shell call, every request is recorded in the run's trail and its signature is what a finding should quote. Paths are fenced to the attached origin: use another session to reach another host.

Input Schema

NameRequiredDescriptionDefault
bodyNoRequest body, sent as application/json unless a content-type header is given
pathYesPath on the attached origin, e.g. /api/things/12, or a full URL on that same origin
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.
limitNoHow many characters to return with offset or select. Default 2000, or 8000 for a select with no offset.
methodNoDefault GET
offsetNoReturn the body (or the selected value) from this character on. The body is cut at 2000 characters by default; the result names the next offset.
selectNoReturn one value of a JSON response body by its dotted path, e.g. "stats.open" or "items.0.name", pretty-printed and up to 8000 characters. A path that is not there says which keys are.
headersNoExtra headers. One given here wins over the app's own, which is how a session tests a different or absent credential. A method override (X-HTTP-Method-Override, X-HTTP-Method, X-Method-Override, or _method in the path's query or the body) is judged by the write policy as the method it names.
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. Changed2 schema fields changedv3.31.0
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / headers / propertyNames
      Added value: +{
+  "type": "string"
+}
  2. Changed1 schema field changedv3.25.0
    • changedInput schema / properties / headers / description
      Previous value: -"Extra headers. One given here wins over the app's own, which is how a session tests a different or absent credential."New value: +"Extra headers. One given here wins over the app's own, which is how a session tests a different or absent credential. A method override (X-HTTP-Method-Override, X-HTTP-Method, X-Method-Override, or _method in the path's query or the body) is judged by the write policy as the method it names."
  3. Changed3 schema fields changedv3.17.0
    • addedInput schema / properties / limit
      Added value: +{
+  "description": "How many characters to return with offset or select. Default 2000, or 8000 for a select with no offset.",
+  "maximum": 8000,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / offset
      Added value: +{
+  "description": "Return the body (or the selected value) from this character on. The body is cut at 2000 characters by default; the result names the next offset.",
+  "maximum": 1000000,
+  "minimum": 0,
+  "type": "integer"
+}
    • addedInput schema / properties / select
      Added value: +{
+  "description": "Return one value of a JSON response body by its dotted path, e.g. \"stats.open\" or \"items.0.name\", pretty-printed and up to 8000 characters. A path that is not there says which keys are.",
+  "maxLength": 500,
+  "type": "string"
+}
  4. Addedv3.4.0

TDQS

A4.4/5.0
Behavior5/5

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

No annotations exist, and the description carries the whole load: cookies and the app's last Authorization header ride along, requests pass through the same interception the write policy enforces, safe-write may refuse a mutation on a record the session did not create, and that refusal is explicitly labeled a safety net rather than a finding. Side effects (recorded in the run trail, signature quotable by a finding) and edge behavior (paths fenced to the origin) are all disclosed.

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?

Front-loaded with the core action and scope in the first clause, and nearly every sentence adds information. The aphorism 'A button that is not shown proves nothing; the same action refused by the server does' is justification-flavored prose in an otherwise dense single paragraph.

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 10-parameter tool with no annotations and no output schema, the description still covers what comes back — status line, timing, the specific comparison-deciding headers, body truncation at 2000 characters with select/offset alternatives, and the next-offset hint. Nothing an agent needs to call it correctly or interpret the result is missing.

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 every parameter is already documented — including select paths, offset/limit windows, headers overriding the app's own, and method-override policy. The description restates the body-window behavior and header precedence but adds essentially no semantics the schema does not already carry, so 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?

States a specific verb and resource — call the app's own API as this session — and immediately fixes the scope: UI bypassed, run in-page, fenced to the attached origin. An agent can distinguish it from scout_click (UI actuation) and from a shell call without opening the schema.

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?

Gives the decisive selection criterion — a hidden/disabled control proves nothing, a server refusal does — and the host-fencing exclusion ('use another session to reach another host'). It never names scout_click or scout_navigate explicitly as the alternative for normal interaction, so routing is inferred rather than stated.

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