Senses for agents on live sites and media: read, see, hear, drive a flow, verify a claim.
Scored across 7 tools
Most tools have clearly distinct roles (drive for interaction, hear for audio, senses for quota), and the descriptions cross-reference each other to steer selection (read → see, perceive → verify). However, four tools (read, see, perceive, verify) all take a URL and return page information, so an agent may still hesitate between perceive and read or between see and drive on simple pages.
Names are single lowercase words drawn from a coherent perception metaphor (drive, hear, perceive, read, see, verify), which reads predictably. The one deviation is 'senses', a noun among otherwise verb-style names, though it fits the metaphor as the capabilities-listing tool.
Seven tools is well within the ideal range and each maps to a distinct capability (static fetch, rendered view, interaction, audio, health, quota, verification). Nothing feels padded or missing at this layer.
The surface covers the full perception lifecycle: raw fetch, rendered capture, live interaction, audio transcription, claim verification, and quota/health introspection. Minor gaps exist—no persistent session handling (each drive call is stateless), and no PDF/document extraction or multi-page crawl, which some agents would expect from a browser-perception service.
Open a URL in a real browser, run up to 20 steps (60 seconds at most), and return what happened: a timeline, screenshots and the final text. This acts on the live site: clicks and form submits are real. Nothing persists between calls, and typed text is not logged. Steps: {do: goto|click|type|press|wait|waitFor|scrollIntoView|mark, testid? | role+name? | selector?, text?, key?, url?, ms?, label?}. Uses 5 perceptions. Free keys get a monthly allowance.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | screen to load it on (default desktop) | |
| steps | Yes | ||
| target | Yes | http(s) URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, openWorldHint=true and non-idempotent, so the bar is lower, yet the description adds real value: actions hit the live site, nothing persists between calls, typed text is not logged, and there are hard limits of 20 steps / 60 seconds plus a monthly allowance on free keys. It does not cover authentication requirements or what happens when a step fails mid-run, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the core action, then behavior, then the step grammar, which is a sensible ordering and dense with no filler. Minor deductions for cryptic fragments like 'Uses 5 perceptions' and the trailing billing note, which add ambiguity rather than clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description does the work by naming the return payload (timeline, screenshots, final text). Combined with the step grammar, action-safety notes and hard limits, an agent has enough to invoke it correctly; failure/error behavior and per-action required fields remain unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 67% schema coverage, the description compensates by spelling out the step object grammar and, importantly, showing that a locator can be testid OR role+name OR selector — a relationship the schema lists as flat properties without explanation. It also restates the 20-step ceiling. It does not explain ms/key/text semantics per action type, leaving some inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a concrete verb-and-resource statement: open a URL in a real browser, run up to 20 steps, return timeline/screenshots/final text. The step vocabulary (goto|click|type|press|wait|waitFor|scrollIntoView|mark) and the note that clicks and submits are real distinguish it clearly from the passive siblings (see, read, perceive, hear).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the interactive framing ('clicks and form submits are real') and the 20-step/60-second caps, which tell an agent when this tool is too heavy. However, it never names an alternative such as see or perceive for read-only inspection, nor states when not to use it. The agent must infer the boundary with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transcribe speech from an audio or video URL, up to 20 MB: full text, language and timed segments. Uses one perception per started minute of audio. Free keys get a monthly allowance of minutes.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | http(s) URL of an audio or video file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description goes well beyond that by disclosing the cost model ('one perception per started minute of audio'), the free-key monthly minute allowance, and the input size cap — non-obvious operational facts an agent needs before spending quota. It also states the return shape, which the definition otherwise lacks since there is no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, with the core action and size limit front-loaded before the output and cost details. The colon-separated list of return fields is efficient. Nothing here is wasted, though the closing sentence about free keys could be compressed slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with no output schema, the description covers action, input constraint, return contents, and cost/quota — enough to call it correctly and predict the bill. It does not address failure modes (unreachable URL, oversized file, long-running async behavior), which is the only material gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With a single parameter at 100% schema description coverage, the schema already defines 'target' as an http(s) URL of an audio or video file. The description adds only the 20 MB constraint, not URL format, accepted codecs, or timeout behavior. Baseline 3 is appropriate when the schema carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Transcribe speech from an audio or video URL'. It names concrete output artifacts (full text, language, timed segments), so the agent knows precisely what it gets back. It never explicitly routes against siblings like see or read, which is the only thing keeping it from a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is clear by implication: call this with an audio or video URL. The 20 MB ceiling is a practical gating condition the agent can check before calling. There is no explicit when-not-to-use statement or named alternative (e.g., 'for still images use see'), so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Health check with an explanation: is it up, how fast, its security headers, and an excerpt of what it says. Paid keys also get sight, or hearing for media. Its ok covers those readings only and does NOT check any claim about the content: use verify for that.
| Name | Required | Description | Default |
|---|---|---|---|
| intent | No | what it should do; recorded with the percept, not judged | |
| target | Yes | http(s) URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, open-world, non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond that: paid keys unlock extra senses, and the `ok` field has a narrowly scoped meaning that should not be read as content validation. It omits error/timeout behavior and what happens with unpaid keys on media targets.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with the capability list front-loaded and the `verify` caveat at the end. Every clause carries information, though the compressed 'sight, or hearing for media' phrasing is slightly opaque on first read.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description does a good job naming the readings an agent will receive and scoping what `ok` means. The main remaining gap is what the paid-tier 'sight/hearing' output actually looks like and how failures are surfaced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both `intent` and `target` are documented in the schema, including that intent is recorded but not judged. The description adds no parameter-level detail beyond that baseline, which is acceptable when the schema carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description concretely enumerates what the tool returns (up/down, speed, security headers, content excerpt) and notes that paid keys add sight or hearing for media, which implicitly separates it from the see/hear siblings. It also names `verify` as the different tool for content claims. It stops short of explicitly contrasting with `read`, `see`, `hear`, and `senses`, so an agent must infer the boundary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear exclusion: `ok` covers only the readings and does NOT check content claims, so use `verify` instead. That is a real routing rule. It does not say when to prefer perceive over see/hear/read directly, which leaves part of the sibling selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a URL as it is delivered: status, title, text and links, without running JavaScript. Works on every key. If sparse is true the page builds itself in the browser: use see instead.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | http(s) URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real behavioral context beyond them: no JavaScript is executed and the returned surface is status/title/text/links. That tells the agent the result is the raw delivered HTML-derived content, which is the key operational caveat. The opaque phrase "Works on every key" adds no usable information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, front-loaded with what is returned and the no-JS constraint, followed by the escape hatch to `see`. The sentence "Works on every key" is filler with no discernible meaning for an agent and slightly muddies an otherwise disciplined description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly carries the burden of describing the return shape (status, title, text, links) and the silent limitation (no JS execution). The main remaining gap is the dangling `sparse` reference, which an agent cannot resolve from this definition alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter, `target`, and schema coverage is 100% – it is already documented as an http(s) URL. The description adds no additional meaning (no format examples, no redirect/timeout behavior, no notes on what happens with non-HTML targets), so this sits at the high-coverage baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (read) and resource (a URL), and enumerates exactly what comes back: status, title, text and links. It also carves out a clear boundary against the sibling `see` tool, so an agent can discriminate `read` from `see` without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit alternative and the condition that selects it ("If `sparse` is true ... use `see` instead"), which is exactly the routing guidance an agent needs. It loses a point because `sparse` is not a declared parameter of this tool, so the agent has to infer whether that is a return field or something from another tool before the condition is actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Load a URL in a real browser and return a screenshot you can look at plus the rendered text. For a video URL, returns frames from it. Free keys get a monthly allowance: call senses to see what is left.
| Name | Required | Description | Default |
|---|---|---|---|
| view | No | screen to load it on (default desktop) | |
| target | Yes | http(s) URL | |
| full_page | No | capture the whole page, not just the first screen |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, openWorld, non-destructive), so the description's added value is the real-browser rendering behavior, the video-frame special case, and an explicit monthly allowance/rate-limit note for free keys. That is meaningful context beyond the structured fields, though it omits failure behavior (timeouts, blocked pages, auth errors).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, zero filler, with the core behavior front-loaded and the quota pointer placed last where it belongs. Every sentence carries distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly takes on the burden of describing return values (screenshot, rendered text, video frames), which is the key thing an agent needs. It could go slightly further on error/empty-result behavior for a read-only browsing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains `target`, `view`, and `full_page` fully. The description adds no syntax or format detail beyond what the schema provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb+resource: 'Load a URL in a real browser' and it names the two artifacts returned (screenshot + rendered text), plus the video variant. It doesn't explicitly distinguish itself from siblings like `read` (text extraction) or `perceive`, so the differentiation is implied rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives one actionable routing hint (call `senses` to check remaining allowance) and notes the video-URL case, but offers no guidance on when to choose this over `read`/`perceive`/`hear` or what happens for non-HTML targets.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What this key can use right now: its plan, which tools are open, and how many perceptions are left this month. Free to call.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and openWorld, so safety is covered. The description adds genuinely new behavioral context by declaring the call is free (no quota consumed) and by enumerating what is disclosed about the key. It does not discuss caching/freshness of the quota figure or any key-scoping/auth requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the returned content and closing with the cost note; nothing is padded. The opener 'What this key can use right now' is slightly awkward phrasing that takes a beat to parse as 'what capabilities this key currently has'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, no output schema, and annotations carrying the safety profile, the description supplies what is needed: the three returned values and the cost characteristic. It could be fully complete by noting whether the quota figure is real-time and whether the tool list reflects plan entitlements versus enabled integrations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the baseline of 4 applies. The description correctly implies a no-argument call by framing the output only, and nothing about parameterization is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states concretely what the call returns: the key's plan, which tools are open, and the remaining monthly perception quota — enough that an agent knows this is a capability/status introspection call, not a sensory action despite the name 'senses'. It stops short of contrasting itself with siblings like perceive or verify, so an agent must infer that it does not perform those actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: 'right now' and the quota mention hint at checking before spending perceptions, and 'Free to call' hints there is no cost to calling often. There is no explicit when-to-use statement, no prerequisite conditions, and no naming of alternatives among the six siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check a claim about a live page. must_contain, must_not_contain and expect_status are checked exactly. A free-text expectation needs judgment: when Pentasor can't judge it, the verdict is unverified and you get the evidence (text, plus a screenshot on paid keys) to decide yourself. pass means everything asked was checked and held; fail means something checked did not.
| Name | Required | Description | Default |
|---|---|---|---|
| target | Yes | http(s) URL | |
| expectation | No | what should be true, in plain words | |
| must_contain | No | text that must appear (ignores case) | |
| expect_status | No | exact HTTP status expected; otherwise any answer under 400 counts as reachable | |
| must_not_contain | No | text that must not appear (ignores case) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/openWorld/idempotent annotations, the description discloses the verdict taxonomy (pass, fail, unverified), the fallback path when judgment fails, and what is returned as evidence, including the paid-key screenshot caveat. This is exactly the kind of outcome and quota context an agent cannot get from the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four tight sentences, front-loaded with the action, then predicate semantics, then the fallback behavior, then verdict definitions. No filler and no restatement of the tool name or schema types.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and does explain verdict meanings and the shape of returned evidence at a high level. The exact structure of the evidence payload is still only sketched, which is the one remaining gap for a five-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is already 100%, so the baseline is 3, but the description adds a meaningful distinction the schema does not: must_contain, must_not_contain and expect_status are 'checked exactly' while 'expectation' requires judgment. That tells the agent how determinism differs across parameters, which affects how results should be trusted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a concrete verb and object: 'Check a claim about a live page,' and then names the exact predicate parameters it evaluates. It is clearly a page-assertion tool rather than a plain fetch, which separates it from 'read'/'see', but it never explicitly contrasts itself with those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by explaining what each check type does, so an agent can infer when a deterministic containment check is preferable to a free-text expectation. However, there is no explicit statement of when to call 'verify' versus 'read' or 'perceive', and no stated preconditions such as requiring the page to be reachable first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
drivehearperceivereadseesensesverifyLive web checks for AI agents: sitemaps, robots.txt, URL status, broken links, feeds, citations.
Media workflows, research and code for agents. Search sources, compare evidence and collaborate.
Verification and routing for autonomous agents: crawler ID, email, web capture, data routing.
Real-time fact-check, citation verification, and source-freshness for AI agents.
Add one secure layer between your agents and this server.
