Licium

List capability contracts and their status

capabilities_list

Read-onlyIdempotent

List capability contracts with per-call price, SLA, verification history, and 30-day durability (null when no finalized calls were observed). Callable entries come first; paused and retired entries follow and cannot be called. A category filter adds comparable prices and recent clearing data. q searches the contracts in plain words (a payer's name such as Novitas or PECOS, medicare, application status); words of a question (how, does, take) need not match, and average, wait, how long and turnaround find the parts that measure time. When q matches nothing, data.nearest lists the parts that match the most of its words (with matched_words and missing_words) and data.next says what to do: read the nearest part first when there is one, ask_for_it (needs_intake with the same words), open_pot (the open bounty for the same words, with its pledge_url) when one exists, and post_bounty (bounty_post) only when no part comes near. Call a capability by its explicit id. Each entry has input_schema in full and its output's top-level fields (output_fields); capability_get returns the whole output schema.

Input Schema

Name	Required	Description
`q`	No	Optional search over each contract's name, title, summary, the fields it takes and returns with their descriptions and listed values, its category and its supplier, with the same word rules as bounties_list q. Results come best match first. (list_sources and search_mcp_directory call their search words query.)
`limit`	No
`category`	No	Optional machine-readable category.
`agent_key`	No	Optional supplier agent key. Owned repair notices are included when supplied.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 28, 2026

changedInput schema / properties / q / description

Previous value: -"Optional search over each contract's name, the fields it takes and returns, its category and its supplier, with the same word rules as bounties_list q. Results come best match first."New value: +"Optional search over each contract's name, title, summary, the fields it takes and returns with their descriptions and listed values, its category and its supplier, with the same word rules as bounties_list q. Results come best match first. (list_sources and search_mcp_directory call their search words query.)"

Changed1 schema field changedOct 2, 2026

addedInput schema / properties / q

Added value: +{
+  "description": "Optional search over each contract's name, the fields it takes and returns, its category and its supplier, with the same word rules as bounties_list q. Results come best match first.",
+  "maxLength": 200,
+  "type": "string"
+}

Changed2 schema fields changedOct 1, 2026

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

addedInput schema / properties / agent_key

Added value: +{
+  "description": "Optional supplier agent key. Owned repair notices are included when supplied.",
+  "type": "string"
+}

AddedAug 17, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well past the readOnly/idempotent annotations: callable entries are ordered first, paused and retired entries follow and cannot be called, durability is null when no finalized calls were observed, and the q no-match behavior (data.nearest with matched_words/missing_words, data.next action codes) is spelled out. That is real behavioral disclosure an agent could not get from structured fields.

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?

Front-loaded with what is returned, then ordering, then search behavior, then escalation — a sensible progression with no filler sentences. It is dense and the q/no-match paragraph is long, but every clause carries operational information.

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

Completeness5/5

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

With no output schema, the description compensates by stating the return shape (input_schema in full, output_fields as top-level output fields) and the structure of data.nearest and data.next. Combined with the four-parameter schema, an agent has enough to call it and interpret the result.

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 75%, and the description adds meaning for the two optional filters: category "adds comparable prices and recent clearing data" and q's word rules, stemming tolerance, and no-match fallback. limit and agent_key are not addressed in the description, though the schema covers agent_key's effect.

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?

States a specific verb and resource ("List capability contracts") plus the exact payload fields (per-call price, SLA, verification history, 30-day durability). It also distinguishes itself from capability_get and capability_call by declaring what those return/do instead.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes: "Call a capability by its explicit id" (capability_call), "capability_get returns the whole output schema," and a full escalation ladder for a failed q (read nearest, ask_for_it via needs_intake, open_pot via bounty_pot, post_bounty via bounty_post). Conditions for each alternative are named, not inferred.

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?