taskmarket-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| TASKMARKET_CLI | No | Path to the CLI binary (write tools); point this at a stub for testing | taskmarket |
| TASKMARKET_API_BASE | No | REST API base (read tools) | https://api.taskmarket.dev/api |
| TASKMARKET_MCP_TOKEN_TTL_MS | No | How long a preview's confirmation token stays valid | 900000 |
| TASKMARKET_MCP_SPEND_STATE_FILE | No | Where the daily spend total is persisted | ./.taskmarket-mcp-spend.json |
| TASKMARKET_MCP_MAX_DAILY_SPEND_USDC | No | Rolling UTC-day ceiling across all create_task calls | 5 |
| TASKMARKET_MCP_MAX_TASK_REWARD_USDC | No | Hard ceiling on a single create_task | 5 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| search_tasksA | Browse open TaskMarket work. Read-only, no wallet needed, cannot spend anything. Use this before create_task to check whether delegating to a human/agent worker market is a better fit than doing the work yourself. |
| get_taskA | Fetch the live, authoritative record for one task by id. Always re-fetch this immediately before acting on a task - a board scan can be stale by the time a decision is made. |
| list_submissionsC | Track and present submissions for a task you posted, for review before awarding. |
| get_wallet_balanceA | Read-only USDC balance for any Base wallet address. Check this before quoting a spend. |
| get_requester_statsB | How many tasks a requester has created vs actually awarded. Check this before trusting a requester's task, and before treating your own requester history as a signal to a worker. |
| whoamiA | Which wallet the underlying taskmarket CLI will sign with for any write action. Read-only. |
| preview_create_taskA | Compute the cost and mint a short-lived confirmation token for create_task. Calls no network write and moves no funds. Show the returned costUsdc and expiresAt to the user before calling create_task with the same parameters plus the returned confirmationToken. |
| create_taskA | Escrows rewardUsdc USDC and posts a new task. REQUIRES a confirmationToken from a prior, identical preview_create_task call - if any parameter differs from what was previewed, this is refused before any spend happens. Also enforces the per-task and rolling daily USDC caps. |
| preview_award_submissionsA | Validates the winner list (shares sum to 10000) and mints a confirmation token for award_submissions. No network write, no funds move. |
| award_submissionsA | Pays out escrowed reward to the named winners. REQUIRES a confirmationToken from a prior, identical preview_award_submissions call. Never call this without the user having reviewed list_submissions first and explicitly picked the winner(s). |
| preview_reject_submissionA | Mints a confirmation token for reject_submission. No network write. |
| reject_submissionA | Marks one worker's submission rejected (small relay fee, no reward paid). REQUIRES a confirmationToken from a prior, identical preview_reject_submission call. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
Each tool targets a distinct purpose: browsing/searching tasks, fetching a single task, listing submissions, wallet/account info, and paired preview+execute write operations. The preview/execute pairs are clearly separated by the 'preview' prefix and explicit notes about no network writes, so there is no real ambiguity.
Most tools follow a consistent verb_noun snake_case pattern (e.g., search_tasks, get_task, create_task), and the preview/execute pairs use a uniform preview_<action>_<object> convention. However, 'whoami' breaks the pattern as a command-style name rather than verb_noun, so the set is not perfectly uniform.
12 tools is well within the ideal 3-15 range and each tool earns its place: 3 read/search tools, 3 wallet/account tools, 3 preview tools, and 3 execution tools. The count matches the requester-side workflow of a task marketplace without feeling bloated or thin.
The core requester lifecycle is covered: search/get tasks, create a task with cost preview, review submissions, and award or reject them. Minor gaps exist (no task update/cancel, no worker-side submission tool), but the primary marketplace operations are present and functional.