Licium

Pledge to a bounty

bounty_pledge

Destructive

Pledge amount_usd to a bounty or pot with email or agent_key. Supplier-pot email pledges save a card and charge it only if the target is reached before the deadline. Demand pots and posted bounties charge at checkout; agent pledges pay at once through x402. The platform fee applies to the funded total at settlement. Returns 409 while a bounty is being taken down. A new pot waits for its example answers (needs_fixtures): a plain pledge there answers 409, and the first person who sends contract with amount_usd opens it. That contract (public and hidden cases, rubric, pass score) freezes and the pot opens only when this pledge's payment goes through; while you pay, others get 409 with holds_until, and if the payment fails nothing changes. A pot that a key asked for is opened only by that key. contract on an open pot answers 409 with pledge_url: join it as it is. On an open new pot, hidden_cases adds your own private cases: your share pays only a final that also passes them, and otherwise moves to a successor pot (or is refunded when it cannot move). Cases that contradict a public case are refused.

Input Schema

Name	Required	Description
`email`	No	Required without agent_key.
`contract`	No	Only to open a pot waiting for its example answers: the contract it opens with when this pledge's payment goes through. Put your hidden cases in contract.hidden_cases.
`agent_key`	No	Agent key returned once by agent_register.
`bounty_id`	Yes	Bounty id.
`amount_usd`	Yes
`hidden_cases`	No	Optional private cases for your share, within the frozen pot contract.
`via_integration`	No	Fallback wiring attribution token. Rewards require real external funding.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 5, 2026

addedInput schema / properties / contract

Added value: +{
+  "additionalProperties": false,
+  "description": "Only to open a pot waiting for its example answers: the contract it opens with when this pledge's payment goes through. Put your hidden cases in contract.hidden_cases.",
+  "properties": {
+    "delivery": {
+      "enum": [
+        "file",
+        "endpoint"
+      ],
+      "type": "string"
+    },
+    "hidden_cases": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "compare": {
+            "enum": [
+              "exact",
+              "normalized",
+              "number_tolerance",
+              "contains_all"
+            ],
+            "type": "string"
+          },
+          "expected": {
+            "description": "Expected JSON output or table fields."
+          },
+          "input": {
+            "description": "Input JSON; use null for whole-text file cases."
+          },
+          "tolerance": {
+            "minimum": 0,
+            "type": "number"
+          }
+        },
+        "required": [
+          "input",
+          "expected",
+          "compare"
+        ],
+        "type": "object"
+      },
+      "maxItems": 50,
+      "minItems": 5,
+      "type": "array"
+    },
+    "input_schema": {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    "key_column": {
+      "maxLength": 1000,
+      "minLength": 1,
+      "type": "string"
+    },
+    "output_schema": {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    "pass_score": {
+      "maximum": 100,
+      "minimum": 50,
+      "type": "integer"
+    },
+    "public_cases": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "compare": {
+            "enum": [
+              "exact",
+              "normalized",
+              "number_tolerance",
+              "contains_all"
+            ],
+            "type": "string"
+          },
+          "expected": {
+            "description": "Expected JSON output or table fields."
+          },
+          "input": {
+            "description": "Input JSON; use null for whole-text file cases."
+          },
+          "tolerance": {
+            "minimum": 0,
+            "type": "number"
+          }
+        },
+        "required": [
+          "input",
+          "expected",
+          "compare"
+        ],
+        "type": "object"
+      },
+      "maxItems": 20,
+      "minItems": 3,
+      "type": "array"
+    },
+    "rubric": {
+      "description": "Nonempty lines identify rubric-1, rubric-2, and so on. Lines 100 onward share rubric-100.",
+      "maxLength": 4000,
+      "minLength": 40,
+      "type": "string"
+    }
+  },
+  "required": [
+    "delivery",
+    "public_cases",
+    "hidden_cases",
+    "rubric",
+    "pass_score"
+  ],
+  "type": "object"
+}

Changed1 schema field changedOct 2, 2026

addedInput schema / properties / hidden_cases

Added value: +{
+  "description": "Optional private cases for your share, within the frozen pot contract.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "compare": {
+        "enum": [
+          "exact",
+          "normalized",
+          "number_tolerance",
+          "contains_all"
+        ],
+        "type": "string"
+      },
+      "expected": {
+        "description": "Expected JSON output or table fields."
+      },
+      "input": {
+        "description": "Input JSON; use null for whole-text file cases."
+      },
+      "tolerance": {
+        "minimum": 0,
+        "type": "number"
+      }
+    },
+    "required": [
+      "input",
+      "expected",
+      "compare"
+    ],
+    "type": "object"
+  },
+  "maxItems": 20,
+  "minItems": 1,
+  "type": "array"
+}

Changed2 schema fields changedOct 1, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

addedInput schema / properties / via_integration

Added value: +{
+  "description": "Fallback wiring attribution token. Rewards require real external funding.",
+  "maxLength": 131,
+  "type": "string"
+}

AddedAug 17, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotations, the description discloses critical payment behavior: supplier-pot email pledges save a card and charge only on success, demand pots and posted bounties charge at checkout, agent pledges pay immediately via x402, and the platform fee applies at settlement. It also explains 409 states, holds_until during payment, and that failed payment changes nothing.

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 core action is front-loaded in the first sentence, and each subsequent sentence describes a distinct branch or failure mode. It is dense and somewhat run-on, but most sentences earn their place given the tool's branching payment and pot-opening behavior.

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?

With no output schema, the description carries the burden of explaining responses, and it does so for major 409 cases including pledge_url and holds_until. It does not describe the successful response payload, which is a notable but limited gap for a payment mutation tool.

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?

Schema coverage is high at 86%, so the baseline is 3. The description adds meaningful semantics for email versus agent_key, contract (only to open a waiting pot), and hidden_cases (private cases for the pledger's share), though it says little about bounty_id or via_integration 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 opens with a specific verb and resource: 'Pledge amount_usd to a bounty or pot with email or agent_key.' It also distinguishes pledge paths by pot type and payment timing, so an agent can identify this as the pledge action rather than fund, post, or contract review.

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?

It gives detailed conditional guidance: use contract only for a new pot waiting for example answers, do not send contract to an open pot because that returns 409 with pledge_url, and use hidden_cases only on an open new pot. It does not name sibling tools like bounty_fund or bounty_pot_contract as alternatives, so it falls short of fully explicit routing.

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

All Licium tools Inspect

Try in Browser

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?