Skip to main content
Glama
Akxan
by Akxan

robots.txt check

robots_check
Read-onlyIdempotent

Fetch and parse robots.txt to display rules and sitemaps, then test URL crawlability for a specified user agent using Google's matching logic.

Instructions

Fetch a site's robots.txt, show its groups and sitemap lines, and test whether specific URLs are crawlable for a given user agent (default Googlebot) using Google's longest-match rules.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
urlsYesURLs to test. robots.txt is fetched from the first URL's origin.
userAgentNoGooglebot

Schema Changelog

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

  1. First observedv0.3.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already cover readOnly, idempotent, and non-destructive behavior, so the description does not need to repeat those. It adds valuable behavioral detail: the tool fetches robots.txt, shows groups and sitemap lines, and applies Google's longest-match rules for crawlability testing. This goes beyond the annotations and clarifies the operation's logic.

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 description is a single, well-structured sentence that front-loads the primary action and includes all essential elements without fluff. Every phrase adds value: fetching, showing groups/sitemaps, testing with a user agent, and the rule engine. It is concise and informative.

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 read-only tool with two simple parameters and no output schema, the description is sufficiently complete. It explains the tool's core outputs (groups, sitemap lines, crawlability results) and the key behavioral rule. It does not detail edge cases or error handling, but those are not critical for a tool of this complexity given the annotations.

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 50%; the schema already explains that robots.txt is fetched from the first URL's origin and that userAgent has a default. The description reinforces the purpose of URLs (test crawlability) and mentions the default Googlebot, but adds little beyond what the schema states. The mention of 'Google's longest-match rules' adds context for the userAgent, but it is not directly tied to a specific parameter's semantics.

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 (fetch, show, test) and a clear resource (robots.txt) with a well-defined scope: fetching, displaying groups/sitemap lines, and testing crawlability. It clearly distinguishes from siblings like sitemap_check and ai_crawler_access by focusing on robots.txt rules and Googlebot behavior.

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 provides clear context for when to use the tool: to inspect robots.txt and test URL crawlability for a specific user agent. It mentions the default Googlebot and Google's longest-match rules, which implies typical usage. However, it does not explicitly state when not to use it or mention alternatives, so it stops short of an explicit when/when-not.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Akxan/google-seo-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server