Agent payment readiness and AI visibility checks, $1 per call over MPP or prepaid credits.
Scored across 3 tools
The three tools target completely different actions: a payment-readiness classification, a page-level AI/search visibility audit, and a free catalog listing of paid services. There is no plausible scenario where an agent would confuse which one to call. The descriptions reinforce the boundary, particularly the explicit statement that the assessment verifies nothing independently.
All three names use consistent snake_case with no casing drift, which is the most important factor. However, the structural convention is mixed: list_paid_services is verb_noun while agent_payment_readiness_assessment and ai_visibility_check are long noun phrases, so the pattern isn't fully predictable from one tool to the next.
Three tools is on the lean side but defensible: one catalog/discovery tool plus two distinct paid services that each do substantive work. Nothing feels redundant or padded. A slightly larger surface (e.g. account/credit status) would round it out, but the current count is not a mismatch for the scope.
The surface covers discovery (list_paid_services) and the two advertised paid checks, and the descriptions explain payment paths and failure handling. Minor gaps exist around account-side operations — there is no tool to check prepaid credit balance or retrieve a past receipt/result — but agents can work around these via the listed HTTP endpoints.
Paid: $1.00 per call over the Machine Payments Protocol, or one prepaid SET Agent Credits call (Authorization: Bearer on the MCP request). Classifies what you declare about ten capabilities of a payment workflow (discovery, payment challenge and receipt, idempotency, webhook verification, fulfillment, authentication, wallet ownership, on-ramp handoff, delivery evidence, recovery) and returns the blocking controls and the order to fix them. It verifies nothing independently and authorizes no payment.
| Name | Required | Description | Default |
|---|---|---|---|
| workflow | Yes | ||
| capabilities | Yes | ||
| idempotencyKey | No | Optional. Reuse it on a retry to get the paid result again without paying twice. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and closed-world, so the safety profile is covered. The description adds genuinely non-derivable behavior: the $1.00-per-call charge, the prepaid Agent Credits alternative with the 'Authorization: Bearer <key>' header, and an explicit scope disclaimer. It stops short of any rate-limit or latency detail, but the billing/auth disclosure is substantial value beyond 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each doing work: cost/access, what is classified, what is returned plus scope limits. Front-loading the price is defensible for a paid tool an agent may call speculatively. Minor density cost in the long parenthetical enumeration, but no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly steps in to say the response contains blocking controls and a remediation order. Cost, auth mechanism and scope boundaries are all present for a read-only assessment tool. The remaining gap is the undocumented 'workflow' parameter and the status/evidence value semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% and the schema is heavily nested, so the description carries more of the burden. It does enumerate the ten capability keys that populate the required 'capabilities' object, which adds real meaning, but it says nothing about the 'workflow' object (name, intendedUsers, targetEnvironment) or the status/evidence structure. Partial compensation only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: it 'classifies what you declare about ten capabilities of a payment workflow' and names those ten capabilities explicitly. The stated return ('the blocking controls and the order to fix them') makes the output shape concrete, and it is unmistakably distinct from siblings ai_visibility_check and list_paid_services.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It establishes a useful negative boundary — 'It verifies nothing independently and authorizes no payment' — which tells the agent not to expect verification or payment execution. However, it never states when to reach for this tool versus the siblings, nor any prerequisite (e.g., that the workflow must already be declared), so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paid: $1.00 per call over the Machine Payments Protocol, or one prepaid SET Agent Credits call (Authorization: Bearer on the MCP request). Audits one public page from public fetches only: which of 15 search and AI crawlers its robots.txt allows (each with the deciding rule and the vendor's documentation), its indexing and snippet directives, title, meta description, canonical, JSON-LD, Open Graph, lang, h1 and server-rendered text, plus site signals (redirects, HTTPS, time to first byte, sitemap, llms.txt, llms-full.txt). Returns a 0-100 readiness score against a published rubric and prioritized findings, each with what was observed, why it matters and the fix. It implies no ranking, traffic or citation outcome. The page is checked before payment is taken; a failed check is not charged.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | A public page address, e.g. example.com/pricing. | |
| idempotencyKey | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the annotations: it discloses the payment model ($1.00 per call over the Machine Payments Protocol or a prepaid credit via Bearer auth), that the page is validated before payment is taken, and that a failed check is not charged. Annotations only cover read-only/open-world/idempotent, so these cost and billing semantics are genuinely additive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense paragraph with no filler sentences; each clause carries real information (crawler rules, directives, site signals, scoring, billing). It is slightly front-loaded on payment terms before the core purpose, which weakens the leading position.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return burden and does so: a 0-100 score against a published rubric plus prioritized findings, each with observation, rationale, and fix. Scope, payment, and return format are all present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% and the description adds nothing about parameters. The `idempotencyKey` property has no description in either the schema or the description, so its role in retry/payment safety is entirely undocumented; the `url` example comes from the schema, not this text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: it audits one public page for AI/search crawler visibility, listing exactly what is inspected (robots.txt rules, directives, meta, JSON-LD, server-rendered text, site signals). This is unmistakably distinct from the payment/listing siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Scoping is clear: it works on 'one public page from public fetches only' and explicitly disclaims any ranking/traffic/citation outcome, so the agent knows the boundaries of the result. It does not name alternative tools or the exact condition for choosing a different sibling, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Free. Lists SET's paid agent services, their prices, how to pay (Machine Payments Protocol or prepaid SET Agent Credits) and the HTTP endpoints behind each tool.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and openWorldHint=false, so safety is covered by structured fields. The description adds non-obvious behavioral context beyond the schema: the call is cost-free ('Free') and it exposes payment-method details (Machine Payments Protocol or prepaid SET Agent Credits) that an agent needs to plan follow-up actions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single compact sentence with the cost cue front-loaded ('Free.') followed by the resource and the returned contents. No filler or repetition; every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and no output schema, the description carries the burden of describing the return payload, and it does so by naming prices, payment methods, and per-tool HTTP endpoints. It stops short of describing list format or ordering, a minor gap for a simple read-only listing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so the schema has nothing to document and the baseline for this dimension is 4. Nothing in the description misrepresents the (empty) input contract.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource ('Lists SET's paid agent services') and enumerates the payload (prices, payment methods, HTTP endpoints), so an agent immediately knows what it returns. It does not explicitly contrast itself with the sibling tools, but those siblings (payment readiness, AI visibility) are clearly different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent infers it should call this to discover payable services and how to pay. There is no explicit when-to-use or when-not-to-use statement, and no routing to or away from siblings. The 'Free' prefix hints it is a safe discovery call but is not framed as guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
agent_payment_readiness_assessmentai_visibility_checklist_paid_servicesPre-payment verification for AI agents.
Pay-per-call TRON fee, payment, and address checks. Agents pay USDT or USDC.
Paid EU AI Act compliance reports for agents. $1.50 per call via x402 (USDC on Base) or Stripe.
Prepaid inference for agents over hosted MCP. Chat, image, and video.
Add one secure layer between your agents and this server.
