Skip to main content
Glama
Sign In
olostep-mcp

olostep-mcp

by olostep
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get Crawl Results

get_crawl_results
Read-onlyIdempotent

Retrieve pages from a crawl started with create_crawl using its crawl_id, checking status while it runs and paginating results with items_limit and next_cursor.

Instructions

Use this to get the pages of a crawl started with create_crawl, using its crawl_id. While the crawl is in_progress it returns the status: call again in about 10 seconds. Once completed it returns each page's url, title and content, up to items_limit per call; when has_more is true, pass next_cursor for the rest. Do not start a new crawl to check on one that is still running.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "crawl_id": "<crawl_id>"
    },
    "name": "get_crawl_results"
  }
}

Input Schema

NameRequiredDescriptionDefault
cursorNoPagination cursor for list-pages. Default: 0 (first page).
formatsNoContent formats to retrieve per page. Default: ["markdown"].
crawl_idYesThe crawl_id (or id) returned from create_crawl.
items_limitNoMax number of pages to retrieve content for (1-100). Default: 20.
search_queryNoOptional filter to rank/select pages by relevance to a query.
max_charactersNoMax characters of content per page (default 20000). Longer pages are cut and link to their full text.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.0.21

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, and non-destructive, but the description adds genuinely new behavior: it returns only status while in_progress, requires polling, and paginates via has_more. Minor deduction because it names 'next_cursor' while the schema parameter is 'cursor', which could send an agent looking for a field that does not exist.

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?

Four short sentences, front-loaded with purpose, then lifecycle behavior, then pagination, then a guardrail. Every sentence carries actionable information with no filler.

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 six parameters and no output schema, the description correctly compensates by describing the returned payload (status, url, title, content) and the pagination contract. The only gap is the cursor/next_cursor naming mismatch and no mention of what formats the content comes back in, though the schema covers that.

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 baseline is 3, but the description adds relational meaning the schema cannot express: items_limit is per call, and has_more/next_cursor drive continuation. It does not explain formats, search_query, or max_characters, but those are fully 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 the pages of a crawl') and ties it directly to the sibling that produces the resource ('started with create_crawl, using its crawl_id'), so an agent can distinguish it from create_crawl or get_batch_results 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 Guidelines5/5

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

Gives an explicit when-to-use (after create_crawl), a polling cadence ('call again in about 10 seconds' while in_progress), and an explicit exclusion ('Do not start a new crawl to check on one that is still running'). Nothing is left to inference.

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