Clawhard Studio

See which AI bots a website lets in

doorman_check_ai_bot_access

Read-onlyIdempotent

Use when the user asks whether their site (or any public site), or a robots.txt they pasted, blocks ChatGPT, Claude, Google AI, Perplexity or other AI crawlers, whether AI can read or train on their content, or why AI search does not mention their site. Fetches the live robots.txt and reports, for 22 named AI bots in four groups (AI training, AI search, assistants, search engines), which are let in, kept out or partly blocked, plus the site's content-signal preference and fixes. Example: {"url": "example.com"} or {"robots_txt": "User-agent: GPTBot\nDisallow: /"}. Pass robots_txt instead of url to check a draft or pasted file without fetching anything. Read-only.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "doorman_check_ai_bot_access"
  }
}

Input Schema

Name	Required	Description	Default
`url`	No	Website address or domain, e.g. nytimes.com. Send this or robots_txt.
`robots_txt`	No	robots.txt text to check instead of fetching a site (a draft or a pasted file, up to 512 KB). Empty means no robots.txt.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedNov 9, 2026

addedInput schema / properties / robots_txt

Added value: +{
+  "description": "robots.txt text to check instead of fetching a site (a draft or a pasted file, up to 512 KB). Empty means no robots.txt.",
+  "minLength": 0,
+  "type": "string"
+}

changedInput schema / properties / url / description

Previous value: -"Website address or domain, e.g. nytimes.com"New value: +"Website address or domain, e.g. nytimes.com. Send this or robots_txt."

removedInput schema / required
```
Removed value: -[
-  "url"
-]
```

AddedNov 2, 2026

TDQS

A4.1/5.0

Behavior4/5

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

The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the description does not need to restate safety basics. It adds meaningful behavior: it fetches the live robots.txt, checks 22 named bots in four groups, reports allowed/blocked/partly blocked status, includes content-signal preference and fixes, and can check pasted text without fetching anything. It does not discuss failure modes such as unreachable sites or fetch latency, so it is not fully comprehensive.

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?

The description is front-loaded with a clear 'Use when' clause, followed by concrete output details and parameter examples. It is a bit dense and repeats some schema-level details, but every element is relevant to selecting or invoking the tool correctly.

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 an open-world, read-only fetch-and-report tool with no output schema, the description does a good job explaining what is fetched, what is checked, and what the report includes. It could be stronger by mentioning how fetch errors or invalid URLs are handled, but it is complete enough for an agent to call the tool confidently.

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%, so the baseline is 3 even though the description provides examples and usage guidance for both url and robots_txt. The schema already documents the parameters and their meanings, including the 512 KB limit and empty robots_txt meaning no robots.txt. The description largely repeats that guidance rather than adding substantial new semantic detail.

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 states a specific verb and resource: it checks which AI bots a site lets in by fetching robots.txt and reporting access for 22 named AI crawlers. This is precise enough that an agent can distinguish it from unrelated sibling tools like DNS, email, or package checks 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 Guidelines4/5

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

The description gives clear when-to-use conditions: checking a site or pasted robots.txt for AI crawler access, whether AI can read or train on content, and why AI search does not mention a site. It also says to pass robots_txt instead of url for drafts, which is a useful input-mode alternative. It does not explicitly state when not to use the tool or name a competing alternative, so this falls short of a 5.

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

All Clawhard Studio tools Inspect

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

Need Help?