Hook Detector

get_run

A research run: its status, progress, charge and every hook it produced.

wait_seconds 0 to 50: wait up to that long for the run to finish, returning the
moment it is done or failed. Use wait_seconds=50 and call again while status is
"queued" or "running"; a fresh run needs about 3 or 4 such calls. progress has
stage, message and updated_at, plus counts once the research reports them and preview
(hooks written so far) while a running run holds one. Pass since with the last
progress.updated_at to return on change or completion. It must be an ISO timestamp
with a timezone (422 invalid_request otherwise). Hooks include transcript_kind:
speech, music, none, other, or null when unknown. conversation_id names the chat conversation the run
belongs to (null outside one). A done run with fewer hooks than asked for, or none,
has outcome: why in one plain paragraph, what to try next, and whether it was free
(stats.rejections holds the counts); a full run's outcome is null, or one sentence
when some hooks are under the view floor because the country filter set clips aside.
Free: reading a run costs no credits.

Input Schema

TableJSON Schema

Name	Required	Description
`since`	No
`run_id`	Yes
`api_key`	No
`wait_seconds`	No	0 to 50: seconds to wait for the run to finish; 0 returns at once

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 25, 2026

TDQS

A3.6/5.0

Behavior4/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It thoroughly explains the polling behavior, the significance of since, the outcome field for incomplete runs, the transcript_kind values, conversation_id, and that it is free. It also mentions a specific error case (422 for invalid since timestamp). This is robust, though it doesn't cover potential rate limits or other side effects.

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 long but every sentence provides actionable detail. It is front-loaded with the definition, then flows into usage, edge cases, and output semantics. No fluff; the length is justified by the tool's complexity. It is well-paragraphed and readable.

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, the description covers polling, error handling, output nuances, and free cost. An output schema exists, so return values need not be enumerated. It lacks some prerequisites (e.g., how to obtain run_id), but that is often implied. Overall, it is sufficiently complete for an agent to call correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is low (25%), so the description compensates significantly. It explains wait_seconds (0-50, polling strategy, repeated calls), since (ISO timestamp with timezone, use with progress.updated_at for change/completion), and implicitly run_id (the run to retrieve). It does not detail api_key, but that is a standard parameter. The description adds substantial context beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it retrieves a research run's status, progress, charge, and hooks. It is specific and uses a clear verb-resource structure. However, it does not explicitly differentiate from sibling tools like list_runs or get_hook, so it lacks the additional distinction that would merit a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides detailed instructions on how to use wait_seconds and since for polling, but it does not indicate when to use get_run versus alternative tools (e.g., list_runs for listing runs, get_hook for specific hooks, export_run for exports). No guidance on tool selection is given.

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

All Hook Detector tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?