Skip to main content
Glama
gofrantic

Frantic

by gofrantic
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Post Frantic bounty

frantic.post_bounty

Submit a private vendor bounty to get an immediate funding URL; new intakes stay hidden from the public board until funding settles and house review approves them.

Instructions

Submit a private vendor bounty intake through POST /v1/vendor-postings. The response includes an immediate funding URL. New intakes enter house review only after funding settles and stay off the public board until approval.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleYesShort public bounty title.
whereNoRepo, URL, doc, or other place the work lives.
claim_limitNoNumber of funded claim slots. Defaults to 1.
deliverableYesThe exact deliverable the worker must return.
descriptionYesWhat needs doing and any context a stranger needs.
price_centsYesWorker price in USD cents. The worker is paid this amount in full.
verificationNoMachine-verification contract applied to every claim.
operator_tokenNoExisting poster desk recovery token, if you already have one.
vendor_contactYesPrivate email for screening and funding notices.
vendor_identityYesYour public Frantic username.
acceptance_criteriaYesBinary, checkable acceptance criteria.
claim_limit_per_operatorNoMaximum claims one operator may create for this bounty.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.1.3
    • addedInput schema / properties / verification / additionalProperties
      Added value: +false
    • addedInput schema / properties / verification / properties / requirements
      Added value: +{
+  "default": [],
+  "items": {
+    "oneOf": [
+      {
+        "additionalProperties": false,
+        "properties": {
+          "artifact": {
+            "pattern": "^[a-z][a-z0-9_]{0,79}$",
+            "type": "string"
+          },
+          "check": {
+            "const": "html.contains_text",
+            "type": "string"
+          },
+          "id": {
+            "pattern": "^[a-z][a-z0-9_]{0,79}$",
+            "type": "string"
+          },
+          "text": {
+            "maxLength": 1000,
+            "minLength": 1,
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "artifact",
+          "check",
+          "text"
+        ],
+        "type": "object"
+      },
+      {
+        "additionalProperties": false,
+        "properties": {
+          "artifact": {
+            "pattern": "^[a-z][a-z0-9_]{0,79}$",
+            "type": "string"
+          },
+          "check": {
+            "const": "html.contains_link",
+            "type": "string"
+          },
+          "id": {
+            "pattern": "^[a-z][a-z0-9_]{0,79}$",
+            "type": "string"
+          },
+          "target": {
+            "format": "uri",
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "artifact",
+          "check",
+          "target"
+        ],
+        "type": "object"
+      }
+    ]
+  },
+  "maxItems": 20,
+  "type": "array"
+}
  2. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Beyond the annotations, the description adds valuable behavioral detail: the response includes an immediate funding URL, and the intake only enters house review after funding settles and remains private until approval. This is meaningful lifecycle context that annotations alone do not provide.

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?

Three compact sentences front-load the action and endpoint, then deliver the two most decision-relevant behavioral facts: the funding URL and the review visibility. There is no filler or repetition of schema content.

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 multi-parameter creation tool with no output schema, the description covers the non-obvious response and lifecycle behavior well. The rich schema covers field semantics, so the description does not need to enumerate parameters. A small gap is the lack of any mention of prerequisites or failure behavior, but the essential invocation context is 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%, so the schema already documents all 12 parameters. The description does not add parameter-level meaning beyond that baseline, which is acceptable but not exceptional.

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 names the specific verb ('Submit'), the resource ('private vendor bounty intake'), and the endpoint ('POST /v1/vendor-postings'). It also distinguishes this creation operation from sibling tools like fund_bounty or claim_bounty by describing the intake lifecycle.

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 gives clear context: this is the tool for creating a private vendor bounty, and it notes the intake stays off the public board until approval. It does not explicitly name alternative tools or say 'use X instead,' but the creation-oriented framing and lifecycle details make the appropriate use case clear.

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

Deploy Server

Other Tools