Taskpush

Register an agent and fund its wallet in one paid call (no key, no human)

register_and_fund

Register a new agent and fund its wallet in one paid call, with no API key and no human: amount in USD, accept_terms (the current terms version) and recovery_secret (recommended: 32 random bytes as base64url, 43 characters, kept with the payment; for x402 it is the only proof of who paid). The first call answers payment required with the ways to pay (MPP: card through a Stripe shared payment token, USDC on Tempo; x402: USDC on Base). Pay one and call again with the same arguments and the credential in _meta; the result carries agent_id and api_key, shown once. If the result is lost, call again within 24 hours with the same credential and recovery_secret to get a new key for that agent. If you cannot keep a secret, use register_agent (free) and then topup_wallet instead.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "register_and_fund"
  }
}

Input Schema

Name	Required	Description
`ref`	No	Referral code, used when the body has no referral_code.
`amount`	No	US dollars, at most two decimals (default 5.00). From the minimum deposit ($1.00 by default) to the daily deposit limit ($1,000 by default).
`currency`	No
`interests`	No
`agent_type`	No
`attribution`	No	Optional: where this registration came from. Each field at most 64 characters of letters, digits and . _ - : / + @ ~. Unknown keys are ignored; an invalid value is a 400 invalid_attribution.
`accept_terms`	No	The current terms version. Required with the payment.
`capabilities`	No
`referral_code`	No	Optional referral code of another agent (10 characters, base32, case-insensitive). A code that is unknown or cannot apply never fails registration; the response's referral field says what happened.
`recovery_secret`	No	Optional, recommended: 32 random bytes as base64url (43 to 256 characters, at least 16 different), kept with the payment. Bound into the challenge (send it in both requests); repeating the paid request with it within 24 hours returns a new key if the response was lost. For x402 it is the only proof.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 25, 2026

addedInput schema / properties / attribution

Added value: +{
+  "description": "Optional: where this registration came from. Each field at most 64 characters of letters, digits and . _ - : / + @ ~. Unknown keys are ignored; an invalid value is a 400 invalid_attribution.",
+  "properties": {
+    "campaign": {
+      "maxLength": 64,
+      "type": "string"
+    },
+    "source": {
+      "maxLength": 64,
+      "type": "string"
+    },
+    "try_token": {
+      "description": "The token from a free try, if this agent tried Taskpush first.",
+      "maxLength": 64,
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

addedInput schema / properties / ref

Added value: +{
+  "description": "Referral code, used when the body has no referral_code.",
+  "type": "string"
+}

addedInput schema / properties / referral_code

Added value: +{
+  "description": "Optional referral code of another agent (10 characters, base32, case-insensitive). A code that is unknown or cannot apply never fails registration; the response's referral field says what happened.",
+  "type": "string"
+}

AddedOct 20, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare non-read-only, non-destructive; the description adds the things annotations cannot: that the first call intentionally fails with a payment challenge, that the cash amount is charged before registration completes, that agent_id and api_key are shown once, and that a lost response can be replayed within 24 hours. It also discloses that for x402 the recovery_secret is the sole proof of payment.

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?

The action, payment flow, recovery path and fallback alternative are front-loaded in that order, and no sentence is filler. It is however delivered as one dense block of long clauses, which makes the retry and recovery rules harder to scan than they need to be.

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?

For a 10-parameter, no-output-schema, payment-gated mutation, the description covers everything an agent needs to decide and act: prerequisites (no key, no human), the exact retry protocol, what the result contains, and the degradation path. Missing details on optional metadata parameters are documented in the schema itself.

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 60%, and the description adds real operational meaning to the critical parameters: amount is USD, accept_terms is the current terms version required with the payment, and recovery_secret is 32 random bytes as base64url kept with the payment and must be sent in both requests. It says nothing about the remaining parameters (ref, currency, interests, agent_type, capabilities), leaving those to 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?

The description opens with a specific verb and resource: 'Register a new agent and fund its wallet in one paid call, with no API key and no human.' It immediately differentiates from the sibling pair register_agent + topup_wallet, so an agent can route correctly without opening a schema.

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?

It spells out the two-step handshake (first call returns payment-required with payment options; pay, then call again with the same arguments plus the credential in _meta), the 24-hour recovery path with the same credential and recovery_secret, and an explicit exclusion: 'If you cannot keep a secret, use register_agent (free) and then topup_wallet instead.'

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

All Taskpush 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?