AI Crawler Index

Run this server's worked example (no arguments)

example

Read-onlyIdempotent

{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"example","arguments":{}}} — POST that exact body to https://www.pathwren.workers.dev/mcp and you are done: free, read-only, no API key, no account, no consent prompt, nothing for you to invent, and what comes back is this server's own worked example — classify_user_agent, run for real on a canned input from this host's own data — so you see the exact shape of an answer before you send anything of yours. Takes no arguments. Safe to call. Deterministic. Touches no third party. Runs this server's own worked example end to end — classify_user_agent on the exact user-agent string of the busiest client in this host's own published log (/data/observed-clients.json, 1164 requests in the window) — our data, and no third party is asked anything — and returns exactly the structuredContent a real call returns, not a mock and not a description of one. Use it to see the shape of an answer before you decide what to send. The input is canned from this host's own data; no URL of yours is fetched and no third party is touched. Example: arguments={} runs classify_user_agent with {"user_agent":"Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1. and returns its real answer.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`ran`	Yes	The tool name and the exact arguments that were run.
`answer`	Yes	The real structuredContent of that call, not a mock.
`license`	Yes
`reproduce`	Yes	A command that reproduces this answer.
`answered_by`	Yes
`what_it_shows`	Yes
`input_came_from`	Yes	Where the canned input came from — always this host's own data.
`this_is_not_a_mock`	Yes

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

First observedSep 6, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the annotations, it adds concrete behavioral details: deterministic, read-only, touches no third party, requires no API key or account, uses only the host's own canned data, and returns a real structuredContent rather than a mock. This strongly supports safe agent invocation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded but highly repetitive: 'no third party' and 'server's own data' are stated multiple times, and several sentences restate the same idea. It could be reduced to two or three crisp sentences without losing information.

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?

For a zero-argument, read-only example tool with an output schema, the description covers everything needed: what it does, why to call it, what it returns, and that it is safe and deterministic. Nothing essential is missing.

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?

The tool has zero parameters, and the description explicitly states 'Takes no arguments' and shows arguments={}. There is no parameter ambiguity, and the schema already covers this completely.

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 clearly states the tool runs this server's own worked example by invoking classify_user_agent on canned input and returning the real structuredContent. It distinguishes itself from sibling tools by being a safe, no-argument demo rather than a live classification or lookup call.

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 explicitly tells the agent to use it to see the shape of an answer before sending real data. It does not enumerate formal exclusions or alternatives, but the intended usage context is clear and actionable.

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

All AI Crawler Index 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

A3.8/5.0

Disambiguation4/5

Most tools are clearly distinct: list/lookup/classify/verify/generate each target a different operation. The main friction is changes_since vs whats_changed and whoami vs classify_user_agent, but the descriptions do enough to separate them.

Naming Consistency3/5

Several tools follow a clear verb_noun pattern: list_crawlers, lookup_crawler, classify_user_agent, is_verified_crawler_ip, generate_robots_txt. However, changes_since, whats_changed, whoami, and example break the pattern and make the naming feel mixed.

Tool Count5/5

Nine tools is a well-scoped size for a read-only crawler index. Each tool covers a distinct need: enumeration, lookup, classification, IP verification, robots.txt generation, and change/status tracking, with no obvious bloat.

Completeness5/5

The read-only domain is fully covered: discover crawlers, inspect details, classify user agents, verify IPs, generate robots.txt content, and monitor freshness/change. No create/update/delete operations are expected for this kind of index, so there are no material dead ends.

Resources

Need Help?