Enpitech

Check Agent Readiness

agent_ready

Read-only

Opens Enpitech's AgentReady scanner as a view in the conversation. Inside the view the scanner fetches the site's public pages and runs 21 checks across five weighted categories (Discovery & Access, Readable for Agents, Structured Data, Actions & MCP, Trust & Safety), then shows a 0-100 agent-readiness score, the per-category breakdown, and the fixes ranked by the points each would recover. Use it when the user asks how ready a website is for AI agents, their own or any site they name: how readable, accessible or usable it is to AI, to agents or to AI crawlers; whether ChatGPT or Claude can read or use it; how to show up in AI answers; or for an audit of llms.txt, robots.txt, schema.org markup or MCP support. url is optional: with no URL the scanner opens with an empty input for the user to fill in. This tool returns only the URL it was opened with; the scan runs inside the view, via agentready_scan.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`url`	No	The site to scan, as the user gave it. A bare hostname like stripe.com is fine; the scanner normalizes it. Omit when the user has not named a site, and they will be asked for one.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`url`	Yes	The site the scanner opened with, or an empty string when the user will type one in the view.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 26, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "url": {
+      "description": "The site the scanner opened with, or an empty string when the user will type one in the view.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "url"
+  ],
+  "type": "object"
+}

First observedSep 26, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare this as a read-only, non-destructive operation, and the description adds meaningful context beyond that: it returns only the URL, does not return scan results, and the scan executes asynchronously inside the view via agentready_scan. It does not discuss failure modes or permission-related behavior, but for a non-destructive view-opening tool this is solid transparency.

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 somewhat long, but every sentence earns its place: mechanics, usage triggers, optional parameter behavior, and return-value limitation. The trigger-phrase list is slightly redundant but still useful. It is front-loaded with the core behavior before moving to usage guidance.

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 tool with one optional parameter, clear annotations, an output schema, and a named sibling for the actual scan, this description is complete. It explains what the tool does, what the user may ask, how the optional parameter behaves, and what the tool does not return. An agent has enough context to invoke it correctly and to route the user to agentready_scan for results.

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?

There is only one parameter and the schema already documents it fully, including that a bare hostname is fine and that the parameter should be omitted when no site is named. The description adds a minor behavioral detail about the empty input field, but the schema already conveys the essential omission behavior. Since schema coverage is 100%, the baseline of 3 is appropriate.

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 names a specific action and resource: it opens Enpitech's AgentReady scanner as a view)Skip with a scan capability. It also clearly distinguishes itself from the sibling agentready_scan by explaining that this tool only opens the view while the scan happens inside it. This level of specificity lets an agent know exactly what to expect.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

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

The description explicitly says 'Use it when the user asks how ready a website is for AI agents' and enumerates many concrete trigger phrasings. It also differentiates this tool from the sibling agentready_scan by noting the scan runs inside the view via that tool and that this tool returns only the opened URL. This is strong routing guidance with no reliance on inference.

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

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