Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

rebag_page

Fetch a Rebag static page by handle to return its ID, title, URL, publish/update times, and plain-text content; unknown handles return 404.

Instructions

Get a Rebag static page. Looks up a single Rebag static page by handle, for example welcome-trendlee. The response has the page's id, title, URL, publication and update times, and its content as plain text. Unknown handles return 404. If transport_mode is ssr_embedded, id is left out.

Input Schema

NameRequiredDescriptionDefault
handleYesPage handle

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.5

TDQS

A3.8/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 and does well: it enumerates the response fields (id, title, URL, publication/update times, content as plain text), discloses the 404 failure mode, and notes a conditional case where id is omitted. It omits auth/permission needs and any rate limits, and references a transport_mode value that isn't an exposed parameter.

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?

Three sentences, front-loaded with purpose, then example, then response shape. Tight overall; the trailing transport_mode sentence is slightly orphaned since that field isn't in the input 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?

For a single-param lookup with no output schema and no annotations, the description covers the return fields, the error case, and a conditional output behavior, which is enough for an agent to call it correctly. Minor gap: no mention of auth or how content should be interpreted beyond plain text.

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% (single required 'handle'), so baseline is 3. The description goes beyond the schema by giving a concrete example value and clarifying that the response's content is plain text, adding usable semantic detail.

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?

Specific verb+resource: 'Get a Rebag static page' / 'Looks up a single Rebag static page by handle'. The word 'single' implicitly contrasts with the plural rebag_pages sibling, but that sibling is never named, so differentiation is left to inference.

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

Usage Guidelines3/5

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

Provides an example handle ('welcome-trendlee') and error behavior (unknown handles return 404), which implies the tool is for fetching a known page handle. However there is no explicit when-to-use vs when-to-use-rebag_pages guidance and no prerequisites stated.

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