Licium

Pledge to a bounty

bounty_pledge

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

TableJSON 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.1/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so in detail: fee applied at settlement, charge timing per pot type, 409 during takedown, needs_fixtures 409 with the contract-opens payment flow, holds_until to other pledgers during payment, no-op on payment failure, key-gated pots, and hidden-case payout/refund/succession semantics. This is far beyond what any structured field provides.

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?

The core action is front-loaded in the first sentence, and most clauses carry behavioral content. However it is one dense run-on paragraph with no separation between pot types, 409 conditions, and hidden-case settlement, making it hard to scan despite the low redundancy.

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 7-parameter tool with nested objects and no output schema, the description covers payment paths, failure modes, and the important 409/pledge_url responses. It does not explain the via_integration fallback semantics or payout/return shape beyond error signals, leaving minor gaps.

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 description coverage is 86%, so the baseline is 3 and the schema already documents fields. The description still adds real meaning: it explains the email-vs-agent_key choice as an either/or auth path, that contract is only for a fixtures-waiting pot, and that hidden_cases on an open new pot affects only the pledge's share and its payout/refund routing.

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 with the funding unit ('Pledge amount_usd to a bounty or pot') and identifies the auth alternatives (email or agent_key). It does not explicitly name differentiating siblings such as bounty_raise or bounty_post, so an agent must infer the boundary from the pot/bounty scenario details.

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?

Gives concrete context for each variant: supplier-pot pledges save a card and charge on target, demand pots and posted bounties charge at checkout, agent pledges pay immediately via x402, and contract is only for opening a pot awaiting example answers. No explicit 'do not use this when...' or sibling routing is stated, so it falls just short of 5.

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?