Skip to main content
Glama

KEVAREMESH AI Procurement Gateway

by io.github.cirralink-stack
OverviewDiscussionsAdmin

One-call buyer-authorized auto-payment and execution for owned or external APIs

kevaremesh_auto_use

AI FIRST: if the buyer's agent is pre-authorized for autonomous x402 spending, use this single MCP tool. No human checkout, approvals or manual invoice at KEVAREMESH. On first call return standard x402 MCP PaymentRequired; compatible payer automatically signs within its preconfigured budget and retries the SAME tool with _meta['x402/payment']. Merchant independently verifies and charges only the exact authorized payment. For owned APIs a paid result may require chain confirmations: use this same tool with receipt_id to resume automatically without paying again. For infrastructure buy and activate a 24h Access Pass automatically, then execute the requested operation; if confirmation is pending, resume with returned access_key and the same operation/input. If a facilitator receipt was lost, an independently observed Base transaction_hash may be supplied ONLY alongside an existing receipt_id or access_key for no-charge recovery. If buyer auto-payment is disabled, the buyer's client alone must obtain human authorization before signing. Buyer maintains keys and budgets; no seller-side custody, no repeated charge on uncertain receipts.

Input Schema

NameRequiredDescriptionDefault
kindYes
slugNo
inputNoOriginal owned API input or live infrastructure operation input
operationNo
access_keyNoFor resuming an already-paid infrastructure pass; private bearer key, no new payment
receipt_idNoFor resuming an already-paid owned result; NEVER buy or sign again
request_idNoOptional infrastructure operation idempotency key; reuse on retries. Omit for same-input cache per pass, or supply a new key to refresh.
transaction_hashNoOptional Base transaction hash ONLY for recovering an existing receipt_id or access_key; independently verified, no new payment

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / request_id
      Added value: +{
+  "description": "Optional infrastructure operation idempotency key; reuse on retries. Omit for same-input cache per pass, or supply a new key to refresh.",
+  "pattern": "^[0-9a-f]{64}$",
+  "type": "string"
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / transaction_hash
      Added value: +{
+  "description": "Optional Base transaction hash ONLY for recovering an existing receipt_id or access_key; independently verified, no new payment",
+  "pattern": "^0x[0-9a-fA-F]{64}$",
+  "type": "string"
+}
  3. Added

TDQS

A4/5.0
Behavior5/5

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

With no annotations present, the description carries the full behavioral burden and does so well. It discloses the x402 PaymentRequired challenge, automatic signing, merchant verification, no repeated charges, resume via receipt_id or access_key, 24h Access Pass activation, transaction_hash recovery constraints, and the human-authorization fallback when auto-payment is disabled.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with a clear directive and most sentences carry relevant behavioral information. However, it is a dense single paragraph with long run-on sentences, repeated phrasing such as 'same tool' and 'no repeated charge,' and could be more structured for an agent to parse quickly.

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 complex multi-step payment and execution tool with no annotations and no output schema, the description covers most lifecycle states including payment challenge, resume, access-pass pending confirmation, and lost-receipt recovery. It is not fully complete because some parameters are under-explained and the exact output shape is not described.

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 63%, and the schema already documents several key parameters such as receipt_id, access_key, request_id, and transaction_hash. The description reinforces resume and recovery semantics, but it leaves slug unexplained and only implies the kind enum semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific operation: executing buyer-authorized x402 auto-payments and API operations for owned or infrastructure resources. It is clear enough to identify the tool's job, but it does not crisply distinguish itself from siblings such as kevaremesh_use_infrastructure or kevaremesh_retrieve_paid_api_result.

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 gives a clear condition for use: when the buyer's agent is pre-authorized for autonomous x402 spending. It also explains resume cases with receipt_id or access_key. However, it does not explicitly name alternatives or state when to prefer a sibling tool instead.

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

All KEVAREMESH AI Procurement Gateway toolsInspect
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