Skip to main content
Glama

veya_paid_run

Read your VEYA runs. Private to the account of the apiKey you pass; another key cannot read them. With runId: one run (state, payment, validators, Robinhood record, receipt). Without runId: the runs saved to your VEYA account. With resume=true: retries Solana verification, the 2-of-3 validator check or the Robinhood record for an unfinished run; pass robinhoodPrivateKey to sign the record. Never pays.

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": {
      "apiKey": "<apiKey>"
    },
    "name": "veya_paid_run"
  }
}

Input Schema

NameRequiredDescriptionDefault
runIdNoRun id returned by veya_paid_call. Omit to list your runs.
apiKeyYesYour VEYA product API key (veya_dev_... or veya_live_...) from https://app.veyanet.tech (System -> API Keys). Every run is saved to this key's VEYA account.
resumeNoRetry the unfinished steps of this run. Never pays again.
robinhoodPrivateKeyNoYour own Robinhood Chain wallet private key (0x + 64 hex). It signs the VEYA record (storeCommitment on Veya.sol) and pays its small ETH gas, so the record comes from your address. Used in memory only, never stored, logged or returned.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / properties / apiKey
      Added value: +{
      +  "description": "Your VEYA product API key (veya_dev_... or veya_live_...) from https://app.veyanet.tech (System -> API Keys). Every run is saved to this key's VEYA account.",
      +  "maxLength": 200,
      +  "minLength": 10,
      +  "type": "string"
      +}
    • addedInput schema / properties / resume / description
      Added value: +"Retry the unfinished steps of this run. Never pays again."
    • addedInput schema / properties / robinhoodPrivateKey
      Added value: +{
      +  "description": "Your own Robinhood Chain wallet private key (0x + 64 hex). It signs the VEYA record (storeCommitment on Veya.sol) and pays its small ETH gas, so the record comes from your address. Used in memory only, never stored, logged or returned.",
      +  "maxLength": 100,
      +  "type": "string"
      +}
    • addedInput schema / properties / runId / description
      Added value: +"Run id returned by veya_paid_call. Omit to list your runs."
    • addedInput schema / properties / runId / maxLength
      Added value: +80
    • changedInput schema / required
      Previous value: -[
      -  "runId"
      -]New value: +[
      +  "apiKey"
      +]
  2. Added

TDQS

A4.6/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses account scoping ("another key cannot read them"), that resume retries only specific unfinished steps (Solana verification, 2-of-3 validator check, Robinhood record) and "Never pays" again, and that robinhoodPrivateKey is used in memory only, never stored, logged, or returned. That is precisely the state-change and secret-handling context an agent cannot get from structured fields.

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?

Front-loads the core action, then uses a tight parallel "With X / Without X / With Y" construction with zero filler. Even the parenthetical return-value list is compressed into one clause.

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?

Covers modes, scoping, secret handling, and the shape of the single-run response, which is strong for a 4-parameter tool with no output schema. Minor gap: nothing about the listing mode's volume, ordering, or pagination, which matters when runId is omitted.

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 100%, so the baseline is 3; the description earns above baseline by explaining what resume actually retries and why robinhoodPrivateKey is needed (to sign the VEYA record from the caller's address). It does not add anything on apiKey or runId beyond the schema, which already documents both well.

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 ("Read your VEYA runs") and then enumerates the three operating modes by parameter (with runId = one run, without = list, with resume = retry verification). The "Never pays" clause implicitly separates it from the paying sibling veya_paid_call, which is also named in the runId schema description.

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?

The "With runId / Without runId / With resume=true" structure gives explicit conditions for each mode, which is exactly what an agent needs to pick a call shape. It stops short of naming alternatives (e.g. use veya_paid_call to create runs, this tool only reads/retries) or stating 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.