Keytomic

Inspect URLs

inspect_urls

Read-only

Checks up to 50 URLs of the site live on every connected engine, in one call. Google: verdict, coverage, Google and user canonical and last crawl for each URL; a URL that fails has its own error, and after Google rate limits, the remaining URLs return gsc_quota_exceeded. Each URL counts toward Google’s limit of about 2,000 inspections per property per day. Bing allows only a few calls a minute, so only the first 8 URLs of the Bing site are checked live; a Bing call that fails gives the status error, and the other URLs get Keytomic's saved Bing result, or unknown with reason rate_limited when there is none. A URL off the Bing site is unknown with reason site_mismatch. An engine the site has not connected is not_connected, and an engine whose data this connection may not read is scope_missing. A Google failure, also one for the whole call such as a connection that needs a reconnect, is a Google entry with status error and detail.error: the code, the message, retryAfterSeconds when a retry can clear it, and connectUrl when the user must fix the connection. The other engines still answer. Keytomic does not save the results. A call with one URL also gives the full Google URL Inspection result (robots.txt and fetch state, mobile usability, rich results and AMP) in detail.inspection.

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": {
      "projectId": "<projectId>",
      "urls": "<urls>"
    },
    "name": "inspect_urls"
  }
}

Input Schema

Name	Required	Description
`urls`	Yes	URLs of the site. Duplicates are inspected once.
`projectId`	Yes	Site to act on, from list_sites. Its connected Search Console property and Bing Webmaster site are used.
`languageCode`	No	BCP-47 language for Google’s translated issue messages, such as "en-US".

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A4.6/5.0

Behavior5/5

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

Annotations only declare it a safe, open-world read; the description carries the real behavioral load — partial success per engine, per-URL errors, gsc_quota_exceeded after rate limiting, saved Bing fallbacks, not_connected/scope_missing states, and that other engines still answer when Google fails. It also discloses non-persistence and the richer single-URL response, none of which duplicates what the annotations say.

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 purpose and the per-URL cap, and nearly every sentence adds operational information about error states. The downside is a single dense wall of text with no grouping of statuses, forcing the agent to parse per-engine rules out of one paragraph.

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 multi-engine live-inspection tool with no output schema, the description explains the response shape thoroughly: per-engine statuses, reason codes, detail.error fields (code, message, retryAfterSeconds, connectUrl), and the extra inspection block. An agent has enough to call it and interpret results without further documentation.

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?

Schema coverage is 100%, so the baseline is 3 and the description adds real meaning beyond it: URLs are constrained to the site (off-site URLs yield site_mismatch with reason), and a one-URL call returns the full detail.inspection payload. It does not clarify languageCode, but the schema already defines it.

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 with scope: 'Checks up to 50 URLs of the site live on every connected engine, in one call.' The contrast with saved data ('Keytomic does not save the results') implicitly separates it from status-style siblings such as get_indexing_status, so an agent can pick between them without opening a 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?

Gives decision-relevant context rather than a bare when-to-use: live inspection costs Google quota (~2,000 per property per day) and Bing is capped at roughly a few calls a minute with only 8 URLs checked. That lets an agent judge cost and throttling, but no explicit alternative tool or 'use X instead when' exclusion is stated.

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

All Keytomic 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?