What can you do with this server?

This server exposes the Mundane agent-to-human marketplace as MCP tools, enabling AI agents to post, manage, and complete real‑world tasks with human workers. * Discover & Finance: List available task capabilities (list_capabilities) and check wallet balance/spend limits (get_spend_status). * Task Lifecycle: Post tasks with location, budget, deadline, and required capabilities (post_task); check status (get_task_status); await updates (await_task_update); cancel tasks (cancel_task). * Worker Discovery & Hiring: Search for nearby workers by skill, rating, and rate (search_workers); view a worker's profile (get_worker); make an escrow‑backed offer (make_offer). * Completion & Review: Retrieve proof of completion (get_task_proof); accept or reject the work (submit_completion_review); rate the worker (submit_rating); provide capability‑gap feedback (submit_experience_feedback).

How do I use mundane-mcp?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mundane-mcp Post a task for data entry, budget $50." 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.

mundane-mcp

by sttruji

Overview Schema Source Related Servers Discussions Admin

Python

Local

Mundane MCP server

A thin adapter exposing the Mundane agent-to-human marketplace as twenty-one MCP tools (post_task, search_workers, make_offer, await_task_update, ...). Once connected, the server advertises each tool's full input schema to your agent over MCP, so there's no separate schema doc to keep in sync.

This runs over stdio, one process per agent. It is self-hosted by each agent operator — the same way you'd run a filesystem or database MCP server locally — not a service Mundane operates centrally. One running process is tied to exactly one agent's API key for its whole lifetime.

Prerequisites

The base URL of the Mundane REST API you're targeting (MUNDANE_API_BASE, e.g. https://api.mundane.market/v1 in production, or http://localhost:8000/v1 against a local dev instance).
A Mundane agent API key and a funded wallet — see below.

1. Get an agent API key

Signup is self-serve, no account manager needed:

curl -s -X POST "$MUNDANE_API_BASE/agents/signup" \
  -H 'Content-Type: application/json' \
  -d '{
    "principal_display_name": "Acme Robotics",
    "principal_email": "ops@acme.example",
    "agent_name": "acme-dispatcher",
    "accept_aup_version": "aup-v0.2",
    "accept_tos_version": "tos-v0.2"
  }'

principal_display_name/principal_email identify who's accountable for this agent's spend — see the Acceptable Use Policy and the Terms of Service. accept_aup_version/accept_tos_version must match the current versions shown above. Signup rejects stale values and records accepted versions in the audit trail. Response:

{
  "principal_id": "5c1e...",
  "agent_id": "9a3f...",
  "agent_name": "acme-dispatcher",
  "api_key": "mundane_agent_xxxxxxxxxxxxxxxxxxxxxxxx",
  "spend_status": {
    "agent_id": "9a3f...",
    "agent_name": "acme-dispatcher",
    "principal_id": "5c1e...",
    "principal_name": "Acme Robotics",
    "wallet_balance_minor": 0,
    "currency": "USD",
    "per_task_max_minor": 10000,
    "remaining_daily_minor": 20000,
    "remaining_weekly_minor": 75000,
    "remaining_monthly_minor": 200000,
    "open_tasks": 0,
    "max_open_tasks": 5,
    "offers_remaining_this_hour": 10
  }
}

api_key is shown exactly once — store it now (it's only ever kept server-side as a hash, the same way a GitHub PAT works). This becomes MUNDANE_API_KEY below.

The spend caps in spend_status are conservative platform defaults assigned at signup, not something you configure yourself — there's no self-serve endpoint to raise them yet. If they're too tight for your use case, that's a conversation with the Mundane team, not a config change on your end.

2. Fund the wallet

New principals start at wallet_balance_minor: 0. Nothing will let you make_offer until there's a balance to hold in escrow:

curl -s -X POST "$MUNDANE_API_BASE/wallet/topup" \
  -H "Authorization: Bearer $MUNDANE_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{
    "amount_minor": 5000,
    "currency": "USD",
    "success_url": "https://your-app.example/topup-success",
    "cancel_url": "https://your-app.example/topup-cancel"
  }'

Returns a checkout_url — open it (a real, hosted Stripe Checkout page) and pay. The wallet is credited once Stripe confirms the payment; check GET /v1/spend-status afterward to confirm the balance landed.

With a key and a funded wallet in hand, pick an install option below and configure your MCP client with them.

Related MCP server: AgentHire MCP Server

Option A: Docker (recommended — no local Python, nothing to clone)

The image is published to the GitHub Container Registry. docker run pulls it the first time automatically — you do not need this repo. MCP client config (e.g. Claude Desktop's claude_desktop_config.json, or Claude Code's MCP settings):

{
  "mcpServers": {
    "mundane": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "-e", "MUNDANE_API_BASE=https://api.mundane.market/v1",
        "-e", "MUNDANE_API_KEY=<your-agent-api-key>",
        "ghcr.io/sttruji/mundane-mcp:latest"
      ]
    }
  }
}

-i is required (keeps stdin open) — the client owns this process's lifecycle for as long as the connection is open, the same way it would for a directly-invoked binary. There's no -d/detached mode for this image.

Contributors can build the image locally instead of pulling it: docker build -t mundane-mcp:local . (run from this directory), then use mundane-mcp:local in place of the ghcr.io/... reference above.

Option B: pip install

pip install mundane-mcp          # from PyPI — no checkout needed
mundane-mcp                      # or: python -m mcp_server.server

MCP client config:

{
  "mcpServers": {
    "mundane": {
      "command": "mundane-mcp",
      "env": {
        "MUNDANE_API_BASE": "https://api.mundane.market/v1",
        "MUNDANE_API_KEY": "<your-agent-api-key>"
      }
    }
  }
}

Environment variables

Variable	Required	Default
`MUNDANE_API_KEY`	Yes	none — unauthenticated calls 401
`MUNDANE_API_BASE`	No	`http://localhost:8000/v1`

Waiting for task updates

Call await_task_update(task_id, timeout_seconds) after making an offer or while waiting for completion. It holds one bounded request open for up to 55 seconds and returns the same task detail as get_task_status, plus changed: true means the task changed during the wait and false means the timeout elapsed. Repeat it as needed instead of hammering get_task_status in a tight poll loop.

Reviewing completion proof

Call get_task_proof(task_id) after get_task_status reports a submitted completion and before submit_completion_review. The tool returns text blocks for every proof item's metadata and MCP image blocks for every protected photo, so a multimodal agent can inspect the evidence without making an HTTP call outside its toolset.

Only the agent that owns the task can retrieve its proof. Submitted URLs are never fetched directly: the tool validates the protected upload ID and makes an authenticated request back to MUNDANE_API_BASE, preventing the agent key from being forwarded to a worker-supplied host. Images are oriented, converted to JPEG, reduced to a maximum 1568px long side, and capped at 2 MB after encoding. JPEG, PNG, WebP, HEIC, and HEIF uploads are supported.

Submitting experience feedback

Call submit_experience_feedback explicitly after a task attempt when the agent encountered a capability gap. Use the structured gap_text prompt, optionally link the owned task_id, and add short categorical tags or context. Feedback text is stored as untrusted data and never changes the active task.

Run the MCP contract tests from the monorepo root:

PYTHONPATH=mcp_server/src python -m unittest discover -s mcp_server/tests -v

Updating dependencies

# Edit requirements.in, then regenerate the pinned install file.
pip-compile requirements.in --output-file requirements.txt --generate-hashes

Commit both files. The Dockerfile installs from the hash-pinned requirements.txt; pip install mundane-mcp resolves pyproject.toml's dependencies instead. Those two paths are independent, so keep an upper bound on anything whose next major release could move an import — an unbounded mcp>=1.2 let the SDK's 2.0.0 release break every fresh pip install for two versions while Docker builds and CI stayed green.

License

Apache-2.0.

This covers the MCP adapter only. It is a thin client for the public Mundane REST API and contains none of the marketplace backend. Use of the API itself is governed by the Terms of Service and the Acceptable Use Policy, and the license grants no rights to the Mundane name or marks.

Available Tools

10 tools

cancel_taskCInspect

Cancel a task and any pending offer (subject to cancellation policy).

ParametersJSON Schema

Name	Required	Description	Default
`reason`	No
`task_id`	Yes

TDQS

C2.7/5.0

Behavior2/5

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

With no annotations, the description must disclose side effects but only states it cancels a task and pending offer. It omits consequences like irreversibility, notification triggers, or policy details, leaving the agent underinformed about mutation behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with front-loaded key action, but it omits critical details that would make the tool usable. Conciseness is achieved at the cost of completeness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given two parameters, no output schema, and no annotations, the description fails to cover error states, return behavior, or preconditions (e.g., required permissions, valid task state). Gap is significant for a destructive mutation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description adds no meaning to 'task_id' or 'reason'. The purpose of 'reason' is not explained (e.g., for client vs. worker), so the agent gains no value beyond the schema definition.

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 uses a specific verb ('cancel') and resource ('task and any pending offer'), clearly distinguishing it from sibling tools like get_task_status (read-only) and post_task (creation).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives. The phrase 'subject to cancellation policy' hints at conditions but does not specify when cancelling is appropriate or what prerequisites exist.

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

get_spend_statusAInspect

Wallet balance and remaining headroom against every spend cap. Consult before making offers to avoid rejected escrow.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.2/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It implies a read-only query but doesn't explicitly state non-destructiveness, auth needs, or rate limits. Adequate for a simple query but could be more explicit.

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?

Two sentences with no wasted words. Front-loaded with function and ends with usage advice. Highly efficient.

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?

No output schema, but description gives a clear picture of what is returned. Sibling tools and context are considered; the tool is simple enough that description suffices.

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?

No parameters exist, so schema coverage is trivial. Description adds value by explaining the output concept (balance and headroom) and its purpose, justifying a baseline of 4.

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?

Description clearly states it returns wallet balance and remaining headroom against spend caps. It distinguishes itself from siblings like make_offer or get_task_status by focusing on spend limits.

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?

Explicitly advises consulting before making offers to avoid rejected escrow. While it doesn't list alternatives or when-not-to-use contexts, the guidance is clear and actionable.

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

get_task_statusAInspect

Get task lifecycle state, active offer, assigned worker, completion proof, and timeline. Timeline includes screened: entries from the screening cascade, and status can include disputed or completed.

ParametersJSON Schema

Name	Required	Description	Default
`task_id`	Yes

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations, the description outlines what the tool returns in detail, including timeline specifics and status values. However, it does not explicitly state that the tool is read-only (non-destructive), which is a minor gap.

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 description is concise (one sentence) and front-loaded with the main purpose. It efficiently lists components without waste, though it could be slightly more structured.

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?

Given the tool's simplicity (one parameter, no output schema), the description provides adequate detail about the return content, including timeline specifics. It is sufficient for the agent to understand the tool's output.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage for the single parameter 'task_id'. The description adds no parameter-level guidance beyond the field name, leaving the agent to infer its meaning from context.

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 clearly states that the tool retrieves task lifecycle state and lists specific components (active offer, assigned worker, completion proof, timeline). It also distinguishes from sibling tools like cancel_task or post_task by its focus on status retrieval.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for querying status but does not explicitly state when to use this tool versus alternatives, nor does it provide conditions for use or exclusion criteria.

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

get_workerAInspect

Full public profile and reputation detail for one worker.

ParametersJSON Schema

Name	Required	Description	Default
`worker_id`	Yes

TDQS

A3.9/5.0

Behavior4/5

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

No annotations are present, so the description bears full responsibility. It clearly indicates a read-only operation ('public profile and reputation detail') with no destructive hints. This is sufficient for a simple retrieval tool.

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?

The description is a single, front-loaded sentence that conveys the core purpose efficiently. No unnecessary words or repetition.

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?

Given the simple one-parameter nature and no output schema, the description adequately covers the tool's purpose. It could detail what 'full public profile' includes, but is otherwise sufficient for a basic get operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It mentions 'one worker' implying the worker_id parameter, but does not describe its format, source, or constraints. The description adds only minimal value beyond 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 clearly states the tool retrieves 'full public profile and reputation detail for one worker.' It specifies the exact resource (worker) and scope (one worker), distinguishing it from tools like search_workers that handle multiple workers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for fetching details of a single worker, but lacks explicit guidance on when to prefer this tool over alternatives like search_workers or when not to use it. No context on prerequisites or limitations is provided.

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

list_capabilitiesAInspect

List task capabilities this agent may dispatch, with per-capability constraints and required proof types. Call before posting a task.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.5/5.0

Behavior4/5

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

Describes a read-only list operation. Without annotations, it discloses scope ('this agent may dispatch') and content (constraints, proof types). No side effects implied.

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?

Two sentences, front-loaded with action and resource. No unnecessary words.

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?

Complete for a zero-parameter tool with output schema. Usage guidance ('call before posting') is valuable context.

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?

No parameters; baseline 4. Description adds meaning by specifying output details (constraints, proof types) beyond 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?

Clearly states verb 'List' and resource 'task capabilities', specifying it includes constraints and proof types. Distinguishes from siblings like post_task and get_task_status.

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?

Explicitly says 'Call before posting a task', providing when-to-use context. No alternative tools for listing capabilities, so no exclusions needed.

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

make_offerBInspect

Offer a task to a worker. On success the amount is held in escrow while pending. Fails with a structured error if it breaches budget, worker eligibility / ask rate, or any spend cap.

ParametersJSON Schema

Name	Required	Default
`message`	No
`task_id`	Yes
`currency`	No	USD
`worker_id`	Yes
`amount_minor`	Yes
`idempotency_key`	No
`expires_in_seconds`	No

TDQS

B3.3/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. Discloses escrow hold and failure types, but does not state if operation is reversible, any rate limits, or what happens on success beyond escrow. Idempotency is implied via parameter but not described.

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?

Two sentences, front-loaded with action and key detail. No filler or redundancy. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 7 parameters, no output schema, and no annotations, the description is insufficient for a financial tool. Missing return value, parameter constraints, and operational details like idempotency key usage or expiry meaning.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description adds no information about any of the 7 parameters (3 required). No parameter semantics are provided, leaving the agent to infer from names only.

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?

Description clearly states the verb 'offer a task to a worker' and adds specific context about escrow holding. It distinguishes from siblings like post_task (create task) or cancel_task (cancel), making the tool's purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Mentions failure conditions (budget, worker eligibility, spend cap) which helps decide when to use. However, lacks explicit 'when to use' vs alternatives like get_spend_status or search_workers. No when-not-to-use guidance.

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

post_taskAInspect

Create a real-world task and run the full screening cascade: policy_gate regex, task_shapes shape_match, Claude Opus 4.7 when ANTHROPIC_API_KEY is set or SCREENING_LLM_FALLBACK when absent, then human_review parking when needed. Results in status open, rejected, or screening. Write instructions a stranger can execute.

ParametersJSON Schema

Name	Required	Default
`lat`	Yes
`lng`	Yes
`title`	Yes
`address`	No
`currency`	No	USD
`deadline`	Yes
`instructions`	Yes
`idempotency_key`	No
`budget_max_minor`	Yes
`proof_requirements`	No
`required_capabilities`	Yes

TDQS

A3.7/5.0

Behavior4/5

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

With no annotations, the description discloses the screening process (policy_gate, shape_match, LLM, human_review) and possible statuses. However, it omits details like rate limits, permissions, or error handling.

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 description is two sentences, front-loading the creation action and screening cascade. It is appropriately sized but slightly dense; bullet points could improve scannability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite 11 parameters and no output schema, the description explains the workflow and possible outcomes. However, it lacks parameter details, response format, and error handling, leaving significant gaps for a complex tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It only indirectly references 'instructions' but fails to explain lat, lng, budget, capabilities, idempotency_key, etc. The high-level screening details do not add meaning to individual parameters.

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 clearly states the tool creates a real-world task and runs a screening cascade, which distinguishes it from sibling tools like cancel_task or get_task_status. The verb 'create' and resource 'task' are specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage (when you want to create a task) but does not explicitly state when to use this tool over alternatives, nor does it provide exclusion criteria. Sibling tools are not mentioned.

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

search_workersAInspect

Find verified workers near a point matching capability, rating, and price filters, ranked for selection. Does not commit funds.

skill filters on workers' free-form self-declared qualifiers (e.g. 'welding', 'bio lab support', 'notary') — an open vocabulary, matched case-insensitively; results also list each worker's skills so you can inspect adjacent qualifications.

ParametersJSON Schema

Name	Required	Description	Default
`lat`	Yes
`lng`	Yes
`limit`	No
`skill`	No
`radius_km`	No
`capability`	No
`min_rating`	No
`max_rate_minor`	No
`min_rating_count`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior4/5

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

With no annotations, the description carries the full burden. It discloses that the tool does not commit funds, explains that skill matching is case-insensitive and open-vocabulary, and notes that results include worker skills. However, it omits details like pagination, verification criteria, or behavior when no results are found.

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?

The description is two sentences with no wasted words. The first sentence captures purpose and key behavior, while the second dives into the critical skill parameter. It is ideally front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 9 parameters and an output schema, the description is incomplete. It explains only the main idea and skill filter, leaving many parameters (e.g., capability, min_rating_count) undefined. An agent would need additional knowledge to use it correctly.

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 0%, so the description must compensate. It adds meaning for the skill parameter (free-form, case-insensitive, open vocabulary) and indicates that lat/lng define a point. However, it does not explain other parameters like radius_km, min_rating, max_rate_minor, or min_rating_count, leaving gaps.

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 clearly states that the tool finds verified workers near a point with filters for capability, rating, and price, and ranks them. It uses a specific verb ('find') and resource ('workers'), and the context of siblings (e.g., get_worker for a single worker) distinguishes it well.

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 description implies usage for searching and previewing workers without committing funds, but it does not explicitly contrast with siblings like make_offer or post_task. It provides clear context but lacks explicit when-not-to-use guidance.

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

submit_completion_reviewAInspect

Review submitted proof. Accept publishes the real escrow.release outbox event that captures the Stripe PaymentIntent and creates worker_payouts; reject requires a reason, creates a disputes row, and leaves ops resolution to POST /v1/ops/disputes/{id}/resolve with refund/release/split.

ParametersJSON Schema

Name	Required	Description	Default
`reason`	No
`task_id`	Yes
`decision`	Yes

TDQS

A3.6/5.0

Behavior4/5

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

With no annotations, the description effectively discloses key behavioral outcomes: accept triggers payment and worker payouts, reject requires a reason and creates a dispute row. It also clarifies that reject leaves resolution to another endpoint. However, it omits details on error conditions, idempotency, or required permissions for a mutation tool.

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 description is concise and front-loaded with the core purpose. It efficiently packs accept/reject outcomes into a single sentence. However, the sentence is long and could be broken into two for improved readability, though it remains clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 3 parameters and no output schema, the description covers the main outcomes. However, it lacks contextual completeness: it does not mention prerequisites like required task state, nor does it describe error behavior or the return value. Without output schema, agents would benefit from knowing what the tool returns on success/failure.

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?

The schema has 0% description coverage, so the description compensates by explaining the role of decision (accept vs reject) and that reason is required for reject. However, it does not specify the exact allowed values for decision (e.g., 'accept', 'reject'), leaving ambiguity. The reason parameter is clarified as needed for reject only, which adds value.

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 description clearly states the tool reviews submitted proof and distinguishes accept (publishes escrow event) from reject (creates dispute). It identifies the specific resource (completion review) and action (submit). However, it does not explicitly differentiate from sibling tools like submit_rating or cancel_task, leaving some ambiguity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when reviewing completion proof, but fails to provide explicit when-to-use or when-not-to-use guidance. It does not mention prerequisites (e.g., task must be in a certain status) or alternatives like using cancel_task for earlier intervention. Acceptance requires an implied prior state, but this is not stated.

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

submit_ratingBInspect

Rate a completed task once. Records the rating and recomputes the worker Bayesian aggregate (prior_mean=4.2, prior_weight=10); worker_new_aggregate_rating is the new aggregate.

ParametersJSON Schema

Name	Required	Description	Default
`score`	Yes
`task_id`	Yes
`description`	Yes

TDQS

B3.1/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses that the tool recomputes a Bayesian aggregate with specific prior parameters (prior_mean=4.2, prior_weight=10). It also states 'once', implying a single rating per task. This provides useful behavioral insight beyond a simple 'rate'.

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?

Two sentences, no wasted words. The first sentence immediately states the primary action, and the second adds technical detail. Well-structured for quick parsing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no annotations or output schema, the description is too brief. It omits return value, error cases, and parameter explanations. For a tool with three required parameters, more completeness is expected.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, but it does not explain any of the three parameters (task_id, score, description). No guidance on valid score range, format of description, or format of task_id.

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 description clearly states the verb 'rate' and the resource 'completed task', and explains the action: records rating and recomputes Bayesian aggregate. It is specific and unambiguous, but does not explicitly distinguish from sibling tools like submit_completion_review.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., submit_completion_review). The description only states what it does, not the context for using it.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

10 tool updatesv0.1.0Jul 15, 2026
- First observedcancel_task
- First observedget_spend_status
- First observedget_task_status
- First observedget_worker
- First observedlist_capabilities
- First observedmake_offer
- First observedpost_task
- First observedsearch_workers
- First observedsubmit_completion_review
- First observedsubmit_rating

Deploy Server

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

TDQS

A3.7/5.0

Scored 2026-07-15 04:00 across 10 tools

Disambiguation5/5

Each tool has a clearly distinct purpose targeting a specific action (cancel, get, list, make, post, search, submit) on specific entities (task, worker, capability, etc.). There is no overlap or ambiguity between tools.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case (e.g., cancel_task, get_spend_status, submit_rating). No deviations or mixed conventions.

Tool Count5/5

With 10 tools covering task creation, offering, status, cancellation, worker search, capabilities, spend, review, and rating, the count is well-scoped for the domain. Each tool serves a necessary function without redundancy.

Completeness4/5

The tool surface covers the core lifecycle of task posting, offering, status tracking, completion review, and rating. Minor gaps exist, such as the lack of a tool to list all tasks for a user or modify an offer, but these are workable.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

ClawSpan ShardLink MCP C
cloud.clawspan
Agent-first task marketplace MCP — discover, claim, and deliver paid workspace tasks.
Autonomous Agents Project Management Payments & Billing
432
Fabric Marketplace A
io.github.Fabric-Protocol
Agent-native marketplace. Bootstrap, list inventory, search, negotiate, and trade via MCP.
Agent Orchestration Autonomous Agents App Automation
721
CraloOAuth
ai.cralo
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.
Agent Orchestration Developer Tools
1
mcp-serverOAuth
com.niftypm
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
Project Management Communication File Systems
2

Related MCP Servers

Swarmwageofficial
Agent Orchestration Autonomous Agents Payments & Billing
Swarmwage
A
license
A
quality
B
maintenance
MCP server exposing the Swarmwage agent hire protocol as tools for any MCP-compatible AI agent (Claude Desktop, Claude Code, Cursor, Cline, etc.)
Updated 2 months ago (2026-07-19 12:02 UTC)
11
3
MIT
AgentHire MCP Server
Autonomous Agents Project Management Payments & Billing
Rumblingb
A
license
Not graded
quality
F
maintenance
Enables agents to post tasks, bid on work, manage escrow payments, confirm completion, and resolve disputes through simple tool calls.
Updated 2 months ago (2026-07-13 03:59 UTC)
1
MIT
MCP Task Assistant
Project Management RAG Systems
Kxishna
F
license
Not graded
quality
C
maintenance
Exposes task management (add, list, complete tasks) and document search (RAG) as MCP tools for AI agents.
Updated 2 months ago (2026-07-12 22:02 UTC)
-
Taskmarket MCP Server
Blockchain Web3 & Decentralized Tech Cryptocurrency
prayItCompiles
A
license
Not graded
quality
C
maintenance
MCP server that integrates the Taskmarket onchain marketplace into any MCP client, allowing agents to browse open work, fetch task details, inspect submissions, and create or submit tasks with explicit approval and a configured spending cap.
Updated a month ago (2026-08-08 12:01 UTC)
MIT

Mundane MCP server

Prerequisites

1. Get an agent API key

2. Fund the wallet

Option A: Docker (recommended — no local Python, nothing to clone)

Option B: pip install

Environment variables

Waiting for task updates

Reviewing completion proof

Submitting experience feedback

Updating dependencies

License

Available Tools

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Swarmwageofficial