Skip to main content
Glama

Can this AI bot use this site? (paid yes/no, signed)

can_ai_use
Read-onlyIdempotent

Fast yes/no verdict for one domain, one AI bot and one use (train, rag or search), from robots.txt, IETF AIPREF, W3C TDMRep, noai directives and RSL licenses, with the reasons and a signed receipt. Use it in a crawler or RAG pipeline before fetching each new domain. Costs 0.001 USD on Base (0.002 on Solana) via x402. Invalid domain or unknown bot is never charged.

Input Schema

NameRequiredDescriptionDefault
botYesAI user-agent token (e.g. GPTBot, ClaudeBot, Google-Extended, CCBot, PerplexityBot)
useNotrain
domainYesDomain to check, without scheme or path (e.g. nytimes.com)

Output Schema

NameRequiredDescriptionDefault
botNo
useNo
pagoNo
domainNo
allowedNo
reasonsNo
decisionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the annotations, the description discloses the per-call cost on Base and Solana, the x402 payment mechanism, that invalid domains or unknown bots are never charged, and that the response includes reasons and a signed receipt. These details materially help an agent understand cost and failure behavior.

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?

The verdict and evidence sources are front-loaded, followed by usage, billing, and failure terms. The text is compact and each sentence adds operational value.

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 an output schema and rich annotations already present, the description is largely complete for invocation. It could mention the verify_receipt sibling for the signed receipt, but nothing critical for calling the tool 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 description reinforces the three input dimensions: one domain, one AI bot, and one use limited to train, rag, or search. The schema already describes domain and bot fields, and the description adds useful meaning for the use parameter, though it does not document every enum nuance.

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?

The description specifies a fast yes/no verdict for one domain, one AI bot, and one use, and names the evidence sources and signed receipt. It is clear what the tool does, but it does not explicitly distinguish itself from sibling tools such as check_ai_consent or ai_consent_score.

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?

It gives a concrete usage context: call it in a crawler or RAG pipeline before fetching each new domain. It also clarifies billing and failure behavior, but does not name exclusions or alternatives among sibling tools.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources