Hermes Micro-Agent

Run a paid micro-task

execute_task

Idempotent

Run one paid micro-task. Requires a confirmed x402 payment first; forwards to the paid /task endpoint and returns its answer.

Return codes: HTTP 200 executed; HTTP 402 payment missing, unconfirmed, or wrong amount (body carries the x402 challenge - pay and retry); HTTP 400 bad input, no charge; HTTP 500 internal error, no charge.

Behavior: charges once per confirmed payment; reusing the same x_payment hash is safe and will not double-charge. No authentication beyond the payment.

Parameters: the prompt must match the task type; x_payment is the confirmed hash from verify_payment. Unknown tasks are rejected before any charge.

When to use: follow list_tasks, price_task, pay, verify_payment, then this.

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": {
      "task": "<task>",
      "prompt": "<prompt>",
      "x_payment": "<x_payment>"
    },
    "name": "execute_task"
  }
}

Input Schema

Name	Required	Description
`task`	Yes	Name of the micro-task to run, e.g. 'summarize'. Must be a task NAME from the list_tasks tool - not a task ID, specification, or free text. TEXT: summarize, extract, keywords, sentiment, translate, rewrite, proofread. CODE: python_debug, code_lint, code_refactor, code_explain, code_review. DATA: json_minify, json_query, csv_to_json, hash, base64, convert. MEDIA: describe_image, probe_media.
`prompt`	Yes	Input for the task: the text to summarize, the JSON to convert, the code to review, the URL to probe, etc. Format depends on the task type.
`x_payment`	Yes	Base transaction hash (0x-prefixed) of the confirmed USDC payment for this task, from the verify_payment step. Required.

Output Schema

Name	Required	Description
`error`	No
`result`	No	task result on HTTP 200
`job_key`	No	job id for get_job_status
`how_to_pay`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations by mapping each HTTP outcome (200 executed, 402 payment challenge, 400 bad input no charge, 500 internal error no charge) to a concrete consequence. It discloses billing semantics (charges once per confirmed payment) and the retry-safety rule that reusing the same x_payment hash will not double-charge, which is the key risk an agent needs to know for a paid call.

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 core action, then cleanly partitioned into behavior, parameters, and when-to-use labels that are easy to scan. There is some redundancy, since the confirmed-payment requirement appears in the opening line, in the 402 return code, and again in the parameter note, which costs it the top mark.

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?

An output schema exists, so return values need not be described, but the description still covers payment flow, error mapping, idempotency, and authorization model for a multi-step paid tool. Nothing an agent needs in order to invoke it correctly is missing.

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 already 100%, yet the description still adds cross-tool meaning: x_payment is the confirmed hash produced by verify_payment, and prompt must match the task type. The note that unknown task names are rejected before charging adds behavioral weight to the task parameter rather than just restating its 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?

States a specific verb and resource ('Run one paid micro-task') plus the concrete effect: forwards to the paid /task endpoint and returns its answer. It also positions itself in the sibling workflow by naming list_tasks, price_task, and verify_payment, so an agent can place it precisely against the other tools.

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 'When to use' line gives an explicit ordered prerequisite chain: list_tasks, price_task, pay, verify_payment, then this tool. It also states the blocking precondition ('Requires a confirmed x402 payment first') and that unknown tasks are rejected before any charge, so the agent knows both entry conditions and failure outcomes.

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

All Hermes Micro-Agent 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?