SameDayDesk agent tools

plan_taskmarket_delegation

Read-only

Prepare a bounded TaskMarket delegation for research, coding, data collection, benchmarking, or verification. Requires chain_id, token_address, deliverable, reward, deadline, and an explicit maximum-spend ceiling. Reads public chain metadata. Returns the canonical TaskMarket API payload and approval summary without creating a task, holding a wallet, or spending funds.

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": {
      "request": "<request>",
      "deliverable": "<deliverable>",
      "chain_id": "<chain_id>",
      "token_address": "<token_address>",
      "deadline_hours": "<deadline_hours>"
    },
    "name": "plan_taskmarket_delegation"
  }
}

Input Schema

Name	Required	Description	Default
`mode`	No		bounty
`tags`	No
`request`	Yes	The external work needed, written as a clear task.
`chain_id`	Yes	Explicit served chain id; no default.
`deliverable`	Yes	The exact artifact or result the worker must return.
`reward_usdc`	No	Proposed worker reward in USDC, up to 6 decimal places.
`token_address`	Yes	Explicit payment token contract on that chain, checked against current network.info.
`deadline_hours`	Yes	Hours until TaskMarket submission closes.
`max_spend_usdc`	No	Explicit user-authorized reward ceiling in USDC.
`reward_base_units`	No	Exact gross reward in the selected token's integer base units. Use with max_spend_base_units.
`acceptance_criteria`	No	Up to 10 testable acceptance checks.
`max_spend_base_units`	No	Explicit reward ceiling in the same chain/token's integer base units. No exchange conversion.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedOct 23, 2026

addedInput schema / properties / chain_id

Added value: +{
+  "description": "Explicit served chain id; no default.",
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / max_spend_base_units

Added value: +{
+  "description": "Explicit reward ceiling in the same chain/token's integer base units. No exchange conversion.",
+  "pattern": "^[0-9]{1,78}$",
+  "type": "string"
+}

addedInput schema / properties / reward_base_units

Added value: +{
+  "description": "Exact gross reward in the selected token's integer base units. Use with max_spend_base_units.",
+  "pattern": "^[0-9]{1,78}$",
+  "type": "string"
+}

addedInput schema / properties / token_address

Added value: +{
+  "description": "Explicit payment token contract on that chain, checked against current network.info.",
+  "pattern": "^0x[a-fA-F0-9]{40}$",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "request",
-  "deliverable",
-  "reward_usdc",
-  "max_spend_usdc",
-  "deadline_hours"
-]New value: +[
+  "request",
+  "deliverable",
+  "chain_id",
+  "token_address",
+  "deadline_hours"
+]

First observedOct 10, 2026

TDQS

A4/5.0

Behavior4/5

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

Beyond the readOnlyHint/destructiveHint=false annotations, the description discloses that it reads public chain metadata, returns the canonical API payload plus an approval summary, and touches no wallet or funds — valuable given there is no output schema. It omits rate limits, error behavior, and why idempotentHint is false.

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?

Three tight sentences: purpose, required inputs, and effect/return, ordered with the most decision-relevant information first. No filler or redundant restatement of the name.

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 12-parameter planning tool with no output schema, the description covers what is consumed, what is returned, and what side effects do not occur. The gaps are the unexplained mode enum (bounty vs claim) and tags, which an agent must guess at.

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 coverage is 83%, so the schema already documents nearly every parameter and the baseline is 3. The description's requirement list partially duplicates the schema and is slightly out of step with it (reward_usdc and max_spend_usdc are not in the schema's required array), and it never explains the bounty/claim mode choice or tags.

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 verb+resource is precise: 'Prepare a bounded TaskMarket delegation,' followed by the supported work categories, and it clarifies the output is a payload/approval summary rather than a live task. It never names a sibling tool, so differentiation from browse_taskmarket_tasks or track_taskmarket_task is left implicit.

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?

Clear context is given: this is the planning/no-spend path ('without creating a task, holding a wallet, or spending funds'), plus the prerequisites (chain_id, token_address, deliverable, reward, deadline, max-spend ceiling). It stops short of explicit when-not-to-use guidance or naming the alternative tool an agent should call to actually execute.

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

All SameDayDesk agent tools 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.