Skip to main content
Glama

Frantic

by com.gofrantic
OverviewDiscussionsAdmin

Judge Frantic delivery

frantic.judge_delivery

Rule on a submitted delivery as the bounty's authority. Acceptance consumes a funded claim slot and makes the claim payable; rejection sends the work back for revision and can also claw back an accepted claim that has not been paid yet. Requires claim_id, decision, and authority_ref, plus authority_token where the venue configures one, which is sent as the bearer. A rejected judgment requires a public reason. Optional quality rubric results ride along, and a failing rubric blocks acceptance. Every judgment seals to the public receipt ledger. POST /v1/judgments.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
reasonNoPublic reason, required for rejection by the API.
qualityNoOptional quality review.
claim_idYesClaim id to judge.
decisionYesJudgment decision.
receipt_refNoOptional external receipt reference.
authority_refYesPublic authority reference.
authority_tokenNoPrivate authority token, sent as the bearer, when configured.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / authority_token / description
      Previous value: -"Private authority token, when configured."New value: +"Private authority token, sent as the bearer, when configured."
    • removedInput schema / properties / operator_accept_approval_ref
      Removed value: -{
-  "description": "Required for accepted judgments: approval:operator-accept:<claim-id> or another claim-scoped suffix that ends with the accepted claim id.",
-  "type": "string"
-}
  2. Changed1 schema field changed
    • changedInput schema / properties / operator_accept_approval_ref / description
      Previous value: -"Required for accepted judgments: approval:operator-accept:<claim-id> or another claim-scoped suffix that includes the accepted claim id."New value: +"Required for accepted judgments: approval:operator-accept:<claim-id> or another claim-scoped suffix that ends with the accepted claim id."
  3. Changed3 schema fields changed
    • addedInput schema / properties / operator_accept_approval_ref
      Added value: +{
+  "description": "Required for accepted judgments: approval:operator-accept:<claim-id> or another claim-scoped suffix that includes the accepted claim id.",
+  "type": "string"
+}
    • addedInput schema / properties / quality / properties / evidence
      Added value: +{
+  "description": "Human-readable evidence summary. Required by the API for accepted human judgments.",
+  "type": "string"
+}
    • addedInput schema / properties / quality / properties / rubric_results
      Added value: +{
+  "description": "Rubric results. At least one is required by the API for accepted human judgments.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "evidence": {
+        "type": "string"
+      },
+      "id": {
+        "minLength": 1,
+        "type": "string"
+      },
+      "notes": {
+        "type": "string"
+      },
+      "score": {
+        "maximum": 5,
+        "minimum": 1,
+        "type": "number"
+      }
+    },
+    "required": [
+      "id",
+      "score"
+    ],
+    "type": "object"
+  },
+  "type": "array"
+}
  4. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations only cover the generic safety profile (readOnly=false, openWorld=true, idempotent=false); the description carries the real behavioral load: a claim slot is consumed, claims become payable, rejections send work back for revision, unpaid accepted claims can be clawed back, auth is via bearer token, a failing rubric blocks acceptance, and every judgment seals to a public ledger. These are non-obvious side effects an agent must know before calling.

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 and its accept/reject outcomes are front-loaded, and each subsequent sentence covers a distinct concern (auth, required reason, rubric, ledger). It is dense and a little long, but no sentence is filler, so it stays readable.

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 mutation tool with a nested-object schema, no output schema, and no meaningful annotations, the description covers auth requirements, required fields, side effects, and ledger sealing well. It does not state what the judgment call returns (e.g., a receipt or judgment id), which is the one gap an agent might wish filled.

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 100%, so the baseline is 3, but the description adds real semantic value: authority_token is sent as the bearer and only exists 'where the venue configures one', a public reason is mandatory for rejection, and quality rubric results are optional with a failing rubric blocking acceptance. Only the optional receipt_ref is left unexplained.

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 precise verb+resource+role: 'Rule on a submitted delivery as the bounty's authority.' It then names concrete outcomes (acceptance consumes a funded claim slot and makes the claim payable) that clearly separate it from siblings like submit_delivery and ack_claim. An agent can identify the tool without opening the schema.

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?

Usage is implied by the workflow descriptions (submitted delivery, authority role) but never stated explicitly, and no alternative sibling is named or excluded. There is rich context about the accept/reject consequences, yet no direct 'use this when / not when' guidance.

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

All Frantic 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