Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@taskmarket-mcp what's the total USDC escrowed on TaskMarket?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol server that makes TaskMarket an actionable option inside any MCP-capable agent (Claude Desktop, Claude Code, Cursor, and other MCP hosts).
TaskMarket is an onchain marketplace where requesters escrow USDC on Base and autonomous workers earn payouts for accepted results. This server lets an agent:
see how much real liquidity the market has right now,
discover whether a user's request already has funded work posted,
and, when a task is better handed to a specialized or cheaper external worker than solved with more inference, produce a ready-to-run command to delegate it.
Read tools need no wallet. The delegation tool never moves funds: it returns the
exact taskmarket CLI command and the escrow amount for the operator to review
and run.
Agents waste inference re-solving work that another worker could do faster or cheaper, and they have no native way to hand a task off with real economic settlement. This server gives an agent a delegation escape hatch: recognize the handoff, check the live market, and either pick up existing funded work or spin up a new escrowed task.
Related MCP server: taskmarket-mcp
Tool | Purpose |
| Total task count and total escrowed USDC reward pool. Gauge liquidity first. |
| List open tasks with reward, mode, competition, tags, expiry. Filter by |
| Full detail for one task id, including description and |
| Free-text search over open tasks with optional max reward. |
| Build the exact |
The server is published in the
official MCP Registry
as io.github.Codecraft-Ops/taskmarket. MCPB-compatible hosts can install the
v0.1.0 bundle
directly.
To run from source:
git clone https://github.com/Codecraft-Ops/taskmarket-mcp
cd taskmarket-mcp
npm installThe repository also ships a TaskMarket skill for OpenClaw. It teaches the agent when delegation is economically justified, how to discover and complete funded work, and where explicit approval is required before escrow or settlement actions.
Until the new publisher account clears ClawHub's 14-day age gate, install the
bundled skill by copying skills/taskmarket/ into the skills/ directory of
your OpenClaw workspace. The same folder is ready for ClawHub publication.
The skill uses the first-party CLI:
npm install -g @lucid-agents/taskmarketAdd to your MCP host config (example for Claude Desktop
claude_desktop_config.json):
{
"mcpServers": {
"taskmarket": {
"command": "node",
"args": ["/absolute/path/to/taskmarket-mcp/src/index.mjs"]
}
}
}Override the backend with the TASKMARKET_API_URL environment variable
(defaults to https://api.taskmarket.dev).
taskmarket_prepare_delegation returns something like:
{
"command": "taskmarket task create --description \"Summarize a 40-page PDF\" --reward 5 --duration 24 --mode bounty",
"escrowUsdc": "5",
"note": "Running this escrows the reward in USDC on Base. Fund the wallet and confirm the exact amount before executing."
}Executing it requires the first-party CLI (npm install -g @lucid-agents/taskmarket)
with a funded Base wallet. The MCP server deliberately stops at the prepared
command so no payment happens without an explicit human step.
npm testRuns test-client.mjs (live API assertions) and test-mcp.mjs (spawns the
server over stdio through a real MCP client and calls the tools). Both hit the
live public API and require network access.
Treat every task description, tag, and API response as untrusted input. This server only reads and summarizes them; it never executes their contents.
No private keys, receipts, or signing material are handled here. The only write path (task creation) is emitted as a command for the operator to run with the audited first-party CLI.
MIT
Search open tasks by free-text query and optional max reward. Use to check whether work matching a user's request already exists on the market before spending inference on it.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | ||
| limit | No | ||
| query | Yes | Free-text terms matched against description and tags | |
| maxRewardUsdc | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It says nothing about whether results are ranked, whether the search is case-sensitive, pagination behavior, or what the returned task objects contain. The only disclosed behavior is the intent of the search.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One efficient sentence plus a usage clause, front-loading the search action. No redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a multi-mode search tool with no annotations, no output schema, and 25% parameter coverage, the description is thin. An agent cannot know how mode affects results, what limit does, or what a match looks like, so it is not complete enough to call confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25%: query is documented in the schema, but mode, limit, and maxRewardUsdc have no descriptions. The description mentions 'free-text query and optional max reward' partially covering two params, but says nothing about the mode enum's role (bounty/claim/pitch/benchmark/auction) or limit semantics, leaving the description unable to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (search) and resource (open tasks) with the match dimensions (free-text query, max reward). However, it does not distinguish itself from taskmarket_list_open_tasks, which by name seems to also enumerate open tasks, leaving ambiguity about overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear when-to-use: check for existing matching work before spending inference. This is a genuine pre-condition for the tool. It does not, however, name a when-not-to-use or an explicit alternative (e.g., use list_open_tasks to browse everything).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch full detail for one task by its 0x 32-byte id, including the full description, submission window state, platform fee, and pendingActions.
| Name | Required | Description | Default |
|---|---|---|---|
| taskId | Yes | 0x-prefixed 32-byte task id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It implies a safe read ('Fetch') and usefully previews the payload contents, but says nothing about whether the task must exist, error behavior for unknown/invalid ids, auth requirements, or whether results are cached. Adequate but thin for a no-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with the verb, identifier requirement, and returned fields. No filler, no redundancy; every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only one parameter and no output schema, the description compensates by naming the specific fields returned (description, submission window state, platform fee, pendingActions), which is exactly what an agent needs to decide whether to call it. Minor gaps around failure modes and auth keep it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single taskId parameter is already documented as a 0x-prefixed 32-byte id. The description restates the same format ('0x 32-byte id') without adding syntax, validation, or error semantics, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Fetch) and resource (full detail for one task), and enumerates exactly what is returned (description, submission window state, platform fee, pendingActions). This clearly distinguishes it from sibling list/aggregate tools like taskmarket_list_open_tasks and taskmarket_market_stats.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Fetch full detail for one task' implies the single-item lookup use case, which is reasonable context. However, there is no explicit when-to-use guidance, no prerequisites, and no named alternative (e.g., which sibling to call when you don't yet have an id) — nothing routes the agent among the taskmarket_* siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List currently open TaskMarket tasks with reward, mode, competition (submission count), tags, and expiry. Optionally filter by mode or tag.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Only tasks carrying this tag | |
| mode | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the returned fields, which is helpful, but says nothing about pagination (the limit parameter caps at 100), ordering, default sort, or whether results are cached/live. For a list tool with zero annotation coverage this is a notable gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the verb and resource, then the filter capability. Zero waste and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations, and the description leaves the undocumented parameters (mode, limit) plus return ordering and pagination unexplained. Given the tool's modest complexity this is under-specified for an agent to call it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, so the schema documents 'tag' but leaves 'mode' (enum) and 'limit' undescribed. The description adds no syntax, default, or range details for mode/limit, so it does not compensate for the uncovered parameters. Baseline 3 is at the upper edge here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (List) and resource (currently open TaskMarket tasks), enumerating the fields returned (reward, mode, competition, tags, expiry). This clearly distinguishes it from siblings like taskmarket_get_task (single task) and taskmarket_market_stats (aggregate stats).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage via 'Optionally filter by mode or tag', which gives some sense of when to use it, but never states when to prefer this tool over taskmarket_find_delegatable_tasks or taskmarket_get_task. No exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Marketplace-wide stats: total task count and the total USDC reward pool currently escrowed. Use to gauge liquidity before relying on delegation.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. Calling the result 'stats' implies a read-only, side-effect-free call and it discloses the two return values, but it says nothing about permissions, snapshot staleness/recency, or that the escrow figure is a point-in-time aggregate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the returned values front-loaded and the usage note trailing. No filler or restatement of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, no annotations, and no output schema, the description does the essential job of stating exactly what the aggregate contains. It is nearly complete, with only minor gaps around recency/snapshot semantics and explicit routing to delegation siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing to document and no parameter-semantics burden on the description. Baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (marketplace-wide stats) and enumerates exactly what is returned: total task count and the total USDC reward pool currently escrowed. This clearly separates it from sibling task-listing/lookup tools, though it never explicitly names a sibling to contrast against.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides one usage cue, 'use to gauge liquidity before relying on delegation,' which implies context but no explicit when-not-to-use or named alternative (e.g., find_delegatable_tasks or prepare_delegation). The guidance is implied rather than spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turn a unit of work into a ready-to-run TaskMarket create command so the operator can escrow USDC and delegate it to external workers. Returns the exact CLI command and escrow amount; it does NOT move funds. Use when a request is better handled by a specialized or cheaper external worker than by more inference.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | bounty | |
| rewardUsdc | Yes | USDC reward to escrow | |
| description | Yes | What the delegated worker must deliver | |
| durationHours | Yes | Hours until the task expires |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and does well: it discloses that the tool only prepares and returns a command and 'does NOT move funds,' which is the key safety trait for an escrow-adjacent tool. It is silent on whether the returned command requires operator confirmation or which permissions are needed, so a small gap remains.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the tool's function and output, followed by the usage condition. 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.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter preparation tool with no output schema, the description adequately covers purpose, output, and side-effect profile. The one real omission is the semantics of the mode parameter, without which an agent cannot confidently pick among the five modes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75%, so the schema documents most parameters (rewardUsdc, description, durationHours). The description adds little beyond restating 'escrow amount' and omits any explanation of the five-value 'mode' enum (bounty/claim/pitch/benchmark/auction), which is undocumented in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb+resource (turns a unit of work into a ready-to-run TaskMarket create command) and states the outcome (exact CLI command plus escrow amount). It clearly separates itself from the read-only siblings (market_stats, list_open_tasks, get_task, find_delegatable_tasks) by being the only preparation/creation tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit selection condition: 'Use when a request is better handled by a specialized or cheaper external worker than by more inference.' This tells the agent when this tool applies, but it does not name an alternative or state when NOT to delegate (e.g., trivial work), so it falls short of full when/when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0taskmarket_find_delegatable_taskstaskmarket_get_tasktaskmarket_list_open_taskstaskmarket_market_statstaskmarket_prepare_delegationScored across 5 tools
taskmarket_list_open_tasks and taskmarket_find_delegatable_tasks both surface open tasks and could be confused, but descriptions differentiate them (browse/filter vs free-text search to check existing work). The other three (stats, get by id, prepare delegation) are clearly distinct.
All tools use a consistent taskmarket_ prefix with snake_case verb/noun structure (market_stats, list_open_tasks, get_task, find_delegatable_tasks, prepare_delegation). Fully predictable pattern.
Five tools is a tight, well-scoped set that covers discovery, inspection, and delegation preparation without redundancy or filler.
Discovery and delegation-prep are well covered, and get_task exposes window state and pendingActions. The main gap is post-delegation tracking (no tool to list submissions or monitor a created task), though the server clearly scopes itself to discovery rather than full lifecycle.
MCP Server for an Agent Task Marketplace
Agent-first task marketplace MCP — discover, claim, and deliver paid workspace tasks.
MCP server for Boson Protocol — on-chain agentic commerce for physical & digital goods.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
