Skip to main content
Glama

GateCheck Readiness

check_agent_tool_readiness
Read-onlyIdempotent

GateCheck readiness: check whether an x402/agent-facing tool is ready for agent routing, marketplace listing, and paid-path monitoring, including public agent discovery surfaces (/llms.txt, /agents.txt, /.well-known/mcp.json, /mcp). Pass target plus optional tier, marketplace_url, expected_resources, and paid_path; deep/report tiers add unpaid 402 probing when paid_path is supplied. Tiers: quick $1, deep $5, report $10.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tierNoReadiness depth. quick=$1, deep=$5, report=$10. Defaults to quick.
methodNoSafe unpaid probe method when paid_path is supplied. Defaults to GET.
targetYesTarget API/provider base URL to scan.
expectedNoOptional expected x402 network/asset/price metadata for paid_path probes.
paid_pathNoOptional specific paid endpoint to probe without payment for deep/report tiers.
marketplace_urlNoOptional marketplace/listing URL to compare against public metadata.
expected_resourcesNoOptional expected resource count.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
scanNo
tierYes
readyYes
scoreYes
checksYes
issuesYes
reportNo
targetYes
productYes
priceUsdYes
healthProbeNo
recommendedFixesYes

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. Description adds that 'deep/report tiers add unpaid 402 probing' and lists the public discovery surfaces scanned, giving extra behavioral context without contradicting the annotations.

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?

Three sentences with no filler; the most important action and scope are in the first sentence, and costs/tier behavior are succinctly stated in the following sentences.

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?

Given 7 params and an output schema, the description covers purpose, tiers, key parameters, and probe behavior. It omits method/expected details but those are already in the schema; output schema exists so return values don't need description.

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 schema already describes all 7 parameters (100% coverage), so baseline is 3. Description adds value by grouping optional parameters, linking paid_path to deep/report tiers, and giving per-tier costs, which is semantic context beyond the schema.

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?

Description opens with 'GateCheck readiness' and states the tool 'check whether an x402/agent-facing tool is ready for agent routing, marketplace listing, and paid-path monitoring', naming concrete discovery surfaces like /llms.txt and /mcp. This clearly distinguishes it from sibling scanners/probers by framing it as a readiness gate rather than a direct scan or probe.

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 tells the user to 'Pass target plus optional tier, marketplace_url, expected_resources, and paid_path' and defines three tiers with costs. It implies the deep/report tiers are needed when paid-path probing is desired, but it does not explicitly contrast with sibling tools like probe_x402_paid_path or state when not to use it.

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.

TDQS

A4.2/5.0
Disambiguation4/5

Most tools have distinct purposes, but there is some conceptual overlap: 'check_agent_tool_readiness' and 'scan_x402_resource' both evaluate readiness, while 'boundary_guard_check' and 'generate_trust_receipt' both produce receipts. Descriptions clarify the differences, so ambiguity is low.

Naming Consistency4/5

All names use snake_case, and most follow a verb_noun pattern (check_, generate_, probe_, scan_). 'boundary_guard_check' deviates by being a noun-noun compound, but it's the only outlier and remains readable.

Tool Count5/5

With 6 tools, the count is well-scoped for an x402/MCP utility server. Each tool covers a distinct aspect (pre-action guard, readiness, receipts, launch pack, probing, scanning) without unnecessary bloat.

Completeness4/5

The set covers the core lifecycle of x402 validation and seller readiness: pre-action checks, readiness assessment, trust receipts, launch assets, and endpoint probing/scanning. Minor gaps exist (e.g., no tool to update or delete launch packs), but they are not critical to the server's purpose.