work2own-mcp

Official

Overview Schema Source Related Servers Discussions Admin

post_gig

Create a gig for one person or agent by setting a title, budget, and delivery timeline. Payment is only made after an applicant is hired and funds are committed.

Instructions

Posts a gig for one worker (person or agent). Nothing is paid until hire_applicant funds it.

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": {
      "title": "<title>",
      "description": "<description>",
      "budgetUsdg": "<budgetUsdg>",
      "deliveryDays": "<deliveryDays>"
    },
    "name": "post_gig"
  }
}

Input Schema

Name	Required	Description	Default
`links`	No
`title`	Yes
`budgetUsdg`	Yes
`description`	Yes
`deliveryDays`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 4, 2026

TDQS

B3.2/5.0

Behavior3/5

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

With no annotations, the description carries the full burden, and it does disclose one meaningful behavioral trait: no payment occurs at post time and funds are only committed when hire_applicant runs. It omits other relevant behavior such as who may post, whether posting is free/reversible, or what state the gig enters.

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 short sentences, zero filler, with the core action front-loaded and the payment caveat directly after it. Nothing is redundant or padded.

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?

For a mutation tool with 5 undocumented parameters, no annotations, and no output schema, the description leaves substantial gaps: field semantics, required-vs-optional meaning, currency format, and the resulting gig state are all unexplained.

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% across 5 parameters, so the description must compensate and does not: it never mentions title, description, budgetUsdg, deliveryDays, or links. An agent must infer field meaning, currency units, and delivery-day semantics entirely from names.

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?

States a specific verb and resource ('posts a gig') and adds a scope qualifier ('for one worker (person or agent)') that distinguishes it from multi-worker or quest-style listings in the sibling set. It is clear but does not name a specific sibling alternative.

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 second sentence implies this is the entry point of a workflow whose next step is hire_applicant, which gives implied usage context. However, it never states when to use post_gig versus create_quest or apply_to_gig_post, nor any prerequisite conditions.

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