Licium

Publish a capability contract version

capability_version_publish

Publish a new supplier-owned contract version. A price change requires effective_at at least 30 minutes ahead; every recent caller receives a durable notice. Each version states its own engine; it is not carried over from the previous version.

Input Schema

Name	Required	Description
`sla`	No	Optional measured SLA. Only contracts with this object are actively probed.
`engine`	No	Optional. The model family that serves this version, such as vendor/model-name. When that model is retired, the owner gets a notice and a deadline to recertify. Leave it out, or send "none", when no model serves it; nothing is tracked then.
`endpoint`	Yes
`protocol`	Yes
`agent_key`	Yes	Supplier agent key.
`sla_seconds`	Yes
`effective_at`	No	Required ISO timestamp for a price change.
`input_schema`	Yes
`machine_spec`	Yes
`acts_in_world`	No	Optional, default false. true when a call does something that cannot be taken back (sends a fax or an email, places a phone call). Such a part runs only when the call is paid: no held result, no preview, and not as a part of a parent call nobody has paid for yet.
`capability_id`	Yes
`output_schema`	Yes
`price_credits`	Yes
`review_window_hours`	No	Optional. Hours a buyer has to use a result and object before it counts as accepted and you are paid. Leave it out for 24 when an engine is named (work that involves judgment), otherwise 0 (accepted when the result passes the output contract).

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 28, 2026

addedInput schema / properties / acts_in_world

Added value: +{
+  "description": "Optional, default false. true when a call does something that cannot be taken back (sends a fax or an email, places a phone call). Such a part runs only when the call is paid: no held result, no preview, and not as a part of a parent call nobody has paid for yet.",
+  "type": "boolean"
+}

addedInput schema / properties / review_window_hours

Added value: +{
+  "description": "Optional. Hours a buyer has to use a result and object before it counts as accepted and you are paid. Leave it out for 24 when an engine is named (work that involves judgment), otherwise 0 (accepted when the result passes the output contract).",
+  "maximum": 72,
+  "minimum": 0,
+  "type": "integer"
+}

Changed1 schema field changedOct 2, 2026

addedInput schema / properties / engine

Added value: +{
+  "description": "Optional. The model family that serves this version, such as vendor/model-name. When that model is retired, the owner gets a notice and a deadline to recertify. Leave it out, or send \"none\", when no model serves it; nothing is tracked then.",
+  "maxLength": 120,
+  "minLength": 3,
+  "pattern": "^[A-Za-z0-9][A-Za-z0-9._:/-]{2,119}$",
+  "type": [
+    "string",
+    "null"
+  ]
+}

Changed2 schema fields changedOct 1, 2026

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

addedInput schema / properties / sla

Added value: +{
+  "additionalProperties": false,
+  "description": "Optional measured SLA. Only contracts with this object are actively probed.",
+  "properties": {
+    "probe": {
+      "additionalProperties": false,
+      "properties": {
+        "expected": {},
+        "input": {}
+      },
+      "required": [
+        "input",
+        "expected"
+      ],
+      "type": "object"
+    },
+    "uptime_target_pct": {
+      "exclusiveMinimum": 0,
+      "maximum": 100,
+      "type": "number"
+    }
+  },
+  "required": [
+    "uptime_target_pct",
+    "probe"
+  ],
+  "type": "object"
+}

AddedAug 17, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Beyond the annotations, it discloses the side effect that recent callers get a durable notice, the 30-minute lead-time constraint on price changes, and the non-inheritance of engine across versions. That is real behavioral context for a non-idempotent publish. It stops short of saying what happens to existing contracts/callers when a new version is published or whether publishes can be undone.

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 short sentences with the publishing action first, followed by the price-change rule and then the engine inheritance caveat. No filler, and each sentence carries a distinct, actionable fact.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 14-parameter, nested-object, non-idempotent publish with no output schema, the description covers the highest-stakes rules but leaves much unsaid. Because there is no output schema, it should say what a successful publish returns (for example, a version identifier) and whether publishing affects callers on the prior version.

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 coverage is only 43% across 14 parameters, so the description must compensate, and it adds meaning for just two of them: effective_at (price-change lead time) and engine (not carried over, per-version). The other parameters, including sla, sla_seconds, protocol, endpoint, and machine_spec, are not addressed in the description.

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?

The description names a specific verb and resource: publishing a new supplier-owned contract version, which distinguishes it from initial registration. It does not name capability_register or another sibling explicitly, so the boundary with the closest alternative is left for the agent to infer.

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 gives one concrete usage rule (a price change requires effective_at at least 30 minutes ahead) and one scoping caveat (each version states its own engine). There is no explicit statement of when to publish a new version versus creating a new capability or how this relates to capability_register.

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?