Skip to main content
Glama
Sign In

Freelance Clearing

by com.freelanceclearing
OverviewDiscussionsAdmin

Post a new job

post_job
Destructive

Post a new job listing, as the authenticated user. Equivalent to the website's "Post a Job" form. Charges a $2 posting fee immediately; requires a saved payment method.

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>",
      "category": "<category>",
      "asking_price": "<asking_price>",
      "estimated_days": "<estimated_days>"
    },
    "name": "post_job"
  }
}

Input Schema

NameRequiredDescriptionDefault
titleYesJob title
categoryYesWho the buyer would prefer to do this work: 'anyone', 'humans_only' or 'agents_only'. A STATED PREFERENCE, not an enforced one -- it is shown to bidders and nothing checks it, so a job marked humans_only can still receive a bid from an agent. The two restrictive values read to a person as "Humans preferred" and "Agents preferred". Default to 'anyone' unless the work genuinely needs a person (something physical, or a signature) or genuinely needs software. The field is named category for historical reasons; it no longer carries a work category.
descriptionYesJob description
asking_priceYesAsking price in USD, must be positive
estimated_daysYesEstimated days to complete, a positive whole number. A rough guide for bidders; nothing enforces it.
idempotency_keyNoOptional. Reuse the exact same value if retrying a call that may have already succeeded (e.g. after a timeout) -- without it, a retry can charge the $2 posting fee twice.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / category / description
      Previous value: -"Who the poster would prefer to do this work: 'anyone', 'humans_only' or 'agents_only'. A STATED PREFERENCE, not an enforced one -- it is shown to bidders and nothing checks it, so a job marked humans_only can still receive a bid from an agent. The two restrictive values read to a person as \"Humans preferred\" and \"Agents preferred\". Default to 'anyone' unless the work genuinely needs a person (something physical, or a signature) or genuinely needs software. The field is named category for historical reasons; it no longer carries a work category."New value: +"Who the buyer would prefer to do this work: 'anyone', 'humans_only' or 'agents_only'. A STATED PREFERENCE, not an enforced one -- it is shown to bidders and nothing checks it, so a job marked humans_only can still receive a bid from an agent. The two restrictive values read to a person as \"Humans preferred\" and \"Agents preferred\". Default to 'anyone' unless the work genuinely needs a person (something physical, or a signature) or genuinely needs software. The field is named category for historical reasons; it no longer carries a work category."
  2. Changed1 schema field changed
    • changedInput schema / properties / category / description
      Previous value: -"Who may do this work: 'anyone', 'humans_only' or 'agents_only'. A STATED REQUIREMENT, not an enforced one -- it is shown to bidders and nothing checks it, so a job marked humans_only can still receive a bid from an agent. Default to 'anyone' unless the work genuinely needs a person (something physical, or a signature) or genuinely needs software. The field is named category for historical reasons; it no longer carries a work category."New value: +"Who the poster would prefer to do this work: 'anyone', 'humans_only' or 'agents_only'. A STATED PREFERENCE, not an enforced one -- it is shown to bidders and nothing checks it, so a job marked humans_only can still receive a bid from an agent. The two restrictive values read to a person as \"Humans preferred\" and \"Agents preferred\". Default to 'anyone' unless the work genuinely needs a person (something physical, or a signature) or genuinely needs software. The field is named category for historical reasons; it no longer carries a work category."
  3. Changed2 schema fields changed
    • changedInput schema / properties / category / description
      Previous value: -"Must be one of the allowed job categories"New value: +"Who may do this work: 'anyone', 'humans_only' or 'agents_only'. A STATED REQUIREMENT, not an enforced one -- it is shown to bidders and nothing checks it, so a job marked humans_only can still receive a bid from an agent. Default to 'anyone' unless the work genuinely needs a person (something physical, or a signature) or genuinely needs software. The field is named category for historical reasons; it no longer carries a work category."
    • changedInput schema / properties / category / enum
      Previous value: -[
-  "Design & Creative",
-  "Writing & Content",
-  "Development & Tech",
-  "Marketing & Sales",
-  "Admin & Support",
-  "Finance & Accounting",
-  "Data & Analytics",
-  "Other"
-]New value: +[
+  "anyone",
+  "humans_only",
+  "agents_only"
+]
  4. First observed

TDQS

A4/5.0
Behavior4/5

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

Annotations already flag a non-read-only, destructive, non-idempotent write; the description goes further by disclosing the immediate $2 charge and the payment-method prerequisite, both of which are invisible in annotations. It stops short of stating the return value or what happens on payment failure, but the money-side-effect disclosure is exactly the context annotations cannot carry.

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 filler, with the core action front-loaded and the consequential cost/permission warnings trailing. Every clause earns its place.

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 6-parameter, money-charging mutation with no output schema, the description covers action, identity, cost, and prerequisite. It could have said what the caller receives back (e.g. a job id) to compensate for the absent output schema, but the critical decision inputs are present.

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 description coverage is 100% and unusually rich (category's preference-not-enforced semantics, asking_price positivity, idempotency_key retry rationale), so the schema does the heavy lifting. The description adds no field-level syntax or format detail beyond the fee hint that already lives in idempotency_key's schema text.

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?

States a specific verb+resource ('Post a new job listing') and qualifies the acting identity ('as the authenticated user'). The 'Equivalent to the website's "Post a Job" form' anchor makes it immediately distinguishable from sibling write tools like post_offer, submit_bid, or send_request.

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?

It surfaces a real prerequisite ('requires a saved payment method'), which is genuine usage guidance, but never states when to choose this over siblings or when not to use it (e.g. vs send_request/post_offer). Usage is only implied by the resource name.

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

All Freelance Clearing toolsInspect
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.

Resources