Skip to main content
Glama
Sign In
spidra-io

spidra-mcp-server

Official
by spidra-io
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

spidra_get_job

Read-only

Retrieve the status and result of scrape, search, batch, crawl, parse, or template-run jobs by ID, including failed-item counts and paginated rows. Check running jobs every 10-15 seconds.

Instructions

Get any job's status, and its result once finished. Use it for the ids other tools return when they don't wait to the end.

  • "scrape", "search": a jobId. Readable for about an hour after it finishes (failed ones 24 hours); after that, use spidra_logs.

  • "batch": a batchId. A completed batch can still have failed items; check "failedCount".

  • "crawl": a jobId. Returns the first 100 pages; spidra_crawl_pages reads the rest.

  • "parse": a jobId. "includePages" adds each page's Markdown.

  • "parse_batch": a batchId.

  • "template_run": a runId. Rows come back with the template's columns ("detail": "full" for every field) and page with "offset" and "limit".

Check every 10 to 15 seconds while it runs. Statuses: queued, waiting, active and running are still in progress; completed, partial, failed and cancelled are final.

Input Schema

NameRequiredDescriptionDefault
idYesThe job's id (jobId, batchId or runId)
typeYesWhat kind of job
limitNoRows to return (default 50)
detailNo"columns" (default) returns each row with just the template's table columns; "full" returns every field (Google Maps rows have about 50)
offsetNoRows to skip (default 0)
includePagesNoparse: also return each page's Markdown

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.7.0

TDQS

A4.8/5.0
Behavior5/5

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

Goes well past the readOnlyHint/openWorldHint annotations by disclosing retention windows (about an hour after completion, 24 hours for failures), the full status vocabulary split into in-progress vs final, and the caveat that a completed batch may still contain failed items visible via failedCount. These are exactly the operational details an agent cannot infer from structured fields.

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?

Front-loaded one-line purpose followed by a scannable per-type bullet list and a closing polling/status note. Every line carries routing or behavioral information; nothing is redundant with the schema.

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?

With no output schema, the description does the work of explaining what each type returns (pages, rows, columns, failedCount). It stops short of describing the concrete result shape for scrape/search jobs, which is the main residual gap for a 7-way polymorphic result tool.

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 100%, so the baseline is 3, but the description adds type-to-parameter applicability that the schema cannot express: includePages only matters for parse, detail/offset/limit only for template_run. It does not restate the enum values or defaults already documented in the schema.

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 ("Get any job's status, and its result once finished") and immediately scopes it to ids returned by other tools. The per-type bullet list lets an agent map jobId/batchId/runId to the correct job family without opening any sibling schema.

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

Usage Guidelines5/5

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

Explicitly says when to use it ("for the ids other tools return when they don't wait to the end") and names alternatives with conditions: spidra_logs after the retention window expires, spidra_crawl_pages for crawl results beyond the first 100 pages. It also gives a concrete polling cadence of 10-15 seconds.

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