Skip to main content
Glama
Sign In

Crawlora MCP

by net.crawlora
OverviewDiscussionsAdmin

itchio_browse

Read-only

Browse one native itch.io catalog context through a relative path returned by itchio_browse_options or the tag picker, and return the native classification, page, item count and every visible project card (id, title, canonical URL, description, creator and creator URL, cover image, displayed price and genre). Pass path unchanged (for example /games/top-rated or /tools/newest) and a one-based page defaulting to 1; arbitrary hosts, query strings, fragments, traversal and trailing slashes are rejected, and pagination is passed to the source without an invented page limit or cursor. All nine classifications are supported and a genuine empty page returns an empty items list.

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": {
      "path": "<path>"
    },
    "name": "itchio_browse"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNoOptional one-based native page. Omit it for page 1; pagination is passed to the source without an invented page limit or cursor.
pathYesRequired relative native catalog path returned by itchio_browse_options or the tag picker, e.g. /games/top-rated or /tools/newest. Pass it unchanged: arbitrary hosts, query strings, fragments, traversal and trailing slashes are rejected. All nine classifications are supported.

Output Schema

NameRequiredDescriptionDefault
dataYesThe tool result payload (shape varies per tool; see each tool's docs resource).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior4/5

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

With readOnlyHint and openWorldHint already supplied, the description still adds useful behavior: rejected inputs (arbitrary hosts, query strings, fragments, traversal, trailing slashes), pagination forwarded without invented limits or cursors, and a genuine empty page yielding an empty items list. It does not cover error surfacing or response envelope beyond items.

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?

Front-loaded with the core action and constraints in two dense sentences with no filler. It is slightly redundant, repeating the same validation and pagination rules that appear verbatim in the schema descriptions.

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?

Complete enough for a two-parameter read tool: scope, path provenance, pagination semantics and empty-result behavior are all stated, and an output schema exists. The parenthetical enumeration of returned fields (id, title, canonical URL, cover image, price, genre) duplicates the output schema rather than adding value.

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?

Schema description coverage is 100% and already documents both path and page including the examples and rejection rules, so the description largely restates the schema rather than adding new meaning. Baseline 3 is appropriate here.

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 ("Browse one native itch.io catalog context through a relative path") and explicitly ties it to paths produced by itchio_browse_options or the tag picker, which distinguishes it from those siblings without needing their schemas.

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?

Gives clear context: obtain the path from itchio_browse_options or the tag picker, pass it unchanged, page is one-based and defaults to 1. It stops short of naming an explicit alternative for cases like fetching a single project (itchio_project) or an explicit when-not-to-use.

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

All Crawlora MCP toolsInspect
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