SeaWeb

research_status

Read-onlyIdempotent

Poll surface for a research job.

Caller-scoped: the same SELECT that checks existence also checks
ownership (job_id AND requester_key_hash == caller key). A mismatch
and a missing job therefore produce the SAME 404-shaped error with
identical timing — both paths do one SELECT, no existence oracle.

Requires SEAWEB_LIVE=1 and an authenticated caller. Rate limited
under "research_status" (30/min). Anonymous callers are refused.

Returns the job's status/throttled_reason/budget_ms_used/created_at/
updated_at plus estimated_wait_ms derived from the heartbeat row
(heartbeat.budget_ms_used, frozen when now - heartbeat_at >120s).
When status is "completed", also returns results[] (url/fetched_at/
expires_at/source live rows) and a live meta block, same row shape
as research() and search_web's live rows.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`job_id`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint, idempotentHint, destructiveHint false), the description discloses critical behavioral details: identical 404-shaped errors for missing vs. unauthorized jobs (no existence oracle), rate limiting at 30/min, refusal of anonymous callers, heartbeat staleness handling (120s freeze), and conditional results when status is 'completed'. This goes well beyond what annotations provide and contradicts none.

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 effectively structured: a one-sentence purpose, followed by security/behavioral constraints, then return value details. Every sentence carries unique information—no filler or repetition of annotations. It is detailed but each element earns its place, and the purpose is 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?

Given the tool's complexity (security nuances, heartbeat-derived wait time, conditional result set), the description covers all essential aspects: purpose, authorization requirements, rate limits, ownership behavior, return fields, heartbeat staleness, conditional results when completed, and row shape consistency with sibling tools. It is sufficiently complete for an agent to invoke and interpret results correctly.

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?

There is only one parameter, job_id, and the input schema provides only a title, no description (0% schema description coverage). The description mentions job_id in the context of ownership checks, implying it is the identifier of a research job, but does not explicitly state how it is obtained (e.g., returned from research()) or its format. This adds some meaning but does not fully compensate for the lack of schema documentation.

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 opens with 'Poll surface for a research job'—a specific verb ('poll') and resource ('research job'). It clearly differentiates from sibling tools by focusing on status retrieval rather than initiating research or other actions, and further distinguishes itself by describing the caller-scoped ownership check and result shape.

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 clear context for when to use the tool: polling a research job's status, with prerequisites (SEAWEB_LIVE=1, authenticated caller) and rate limits. It does not explicitly name an alternative tool for starting research, but the mention of 'same row shape as research() and search_web' implicitly distinguishes it. It lacks an explicit 'use this instead of X' but the context is sufficient.

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

All SeaWeb tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.4/5.0

Disambiguation3/5

There is notable overlap among search, search_web, search_restaurants, and search_salons, as well as between filter_restaurants/filter_salons and search with constraints. However, descriptions clarify the intended vertical or corpus, and entity getters are distinct. The overlap is manageable but could cause misselection.

Naming Consistency4/5

Names mostly follow a get_/list_/search_/register_/delete_/submit_/vote_ pattern in snake_case. Minor deviations like 'recall', 'remember', 'research', and 'travel_health' are less predictable but still readable. Overall consistent and clear.

Tool Count2/5

38 tools is on the heavy side for a single MCP server, exceeding the typical well-scoped range. While the server covers multiple subdomains (search, travel disruptions, memory, feedback, research), the sheer number may overwhelm agents and suggests potential consolidation.

Completeness4/5

The tool surface covers core workflows: search and entity retrieval for restaurants/salons, disruption monitoring with standing queries and webhooks (register/list/delete), research submission/polling, and memory/feedback mechanisms. Minor gaps exist (e.g., no cancel for research jobs, no explicit entity list endpoint), but these are workable and do not break typical agent tasks.

Resources

Need Help?