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

TableJSON 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
`capability_id`	Yes
`output_schema`	Yes
`price_credits`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

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.6/5.0

Behavior4/5

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

With no annotations, the description carries the full behavioral burden and does disclose non-obvious traits: callers receive a durable notice, the effective_at 30-minute lead requirement for price changes, and that each version states its own engine rather than inheriting it. It omits auth/permission requirements and what happens to superseded versions, so it is strong but not complete.

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?

Three dense sentences with no filler; the core purpose and the two critical rules (lead time, engine non-inheritance) are front-loaded. Slightly terse given the twelve-parameter surface, but every sentence earns its place.

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 12-parameter mutation tool with 9 required fields, no annotations, and no output schema, the description covers key behavioral rules but leaves most parameter semantics and any post-publish result expectations unaddressed. Adequate but with clear gaps.

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 33%, so the description must compensate. It adds real meaning for effective_at (30-minute lead on price changes) and engine (not carried over, retirement triggers notice and recertify deadline), but says nothing about the other undocumented params such as endpoint, protocol, machine_spec, input_schema, output_schema, price_credits, or sla_seconds.

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+resource: 'Publish a new supplier-owned contract version.' An agent can distinguish this from capability_register, capability_get, or capability_call without opening a schema, though no sibling is named explicitly to sharpen the boundary.

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 rather than stated: it describes a rule for price changes (effective_at at least 30 minutes ahead) but never says when to choose this tool over capability_register or when republishing is appropriate. No when-not guidance or prerequisites are given.

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?