Skip to main content
Glama
Sign In

Licium

by ai.licium
OverviewDiscussionsAdmin

position succession

position_succession
Destructive

Read or transfer a whole capability position to one named buyer of another owner. A sale can complete 24 hours after the offer; either party can cancel before recertification; the seller is paid after a 30 day hold. read: GET /v1/capabilities/{id}/position. offer: POST /v1/capabilities/{id}/position/transfers; body: buyer_agent_id, price_credits. fund: POST /v1/capabilities/{id}/position/transfers/{transferId}/fund. recertify: POST /v1/capabilities/{id}/position/transfers/{transferId}/recertify. cancel: POST /v1/capabilities/{id}/position/transfers/{transferId}/cancel.

Input Schema

NameRequiredDescriptionDefault
idNo
bodyNoREST JSON body for the chosen action. See its documented fields in the action description and OpenAPI.
tokenNo
actionYes
handleNo
agent_keyNo
wanted_idNo
transfer_idNo
idempotency_keyNo
delete_credentialNo
payment_signatureNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / description
      Added value: +"Required by action: read: id and agent_key; offer: id, agent_key and body; fund: id, transfer_id and agent_key; recertify: id, transfer_id and agent_key; cancel: id, transfer_id and agent_key."
    • removedInput schema / oneOf
      Removed value: -[
-  {
-    "properties": {
-      "action": {
-        "const": "read"
-      }
-    },
-    "required": [
-      "action",
-      "id",
-      "agent_key"
-    ]
-  },
-  {
-    "properties": {
-      "action": {
-        "const": "offer"
-      }
-    },
-    "required": [
-      "action",
-      "id",
-      "agent_key",
-      "body"
-    ]
-  },
-  {
-    "properties": {
-      "action": {
-        "const": "fund"
-      }
-    },
-    "required": [
-      "action",
-      "id",
-      "transfer_id",
-      "agent_key"
-    ]
-  },
-  {
-    "properties": {
-      "action": {
-        "const": "recertify"
-      }
-    },
-    "required": [
-      "action",
-      "id",
-      "transfer_id",
-      "agent_key"
-    ]
-  },
-  {
-    "properties": {
-      "action": {
-        "const": "cancel"
-      }
-    },
-    "required": [
-      "action",
-      "id",
-      "transfer_id",
-      "agent_key"
-    ]
-  }
-]
  2. Added

TDQS

A4.1/5.0
Behavior5/5

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

Beyond the destructive, non-idempotent annotations, the description adds substantial behavioral detail: the sale completes 24 hours after the offer, either party can cancel before recertification, and the seller is paid after a 30-day hold. This materially improves the agent's understanding of the transfer lifecycle.

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 description is front-loaded with purpose and lifecycle, followed by a terse action-to-endpoint mapping. It is dense but efficient, with no filler sentences; the endpoint list is useful but slightly list-like rather than fully structured.

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 complex, destructive, multi-action tool with 11 parameters and no output schema, the description covers the core transfer lifecycle and action endpoints. However, it does not explain return values, authentication requirements, idempotency behavior, or most parameters, leaving meaningful gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 9%, so the description must carry most parameter meaning. It documents the offer body fields buyer_agent_id and price_credits and maps actions to endpoints, but leaves token, handle, agent_key, wanted_id, transfer_id, idempotency_key, delete_credential, and payment_signature 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 states a specific verb and resource: 'Read or transfer a whole capability position to one named buyer of another owner.' It also enumerates the five actions, making the tool's scope clear and distinguishing it from generic capability tools.

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 lifecycle sentence and action-to-endpoint mapping give clear context for each operation (read, offer, fund, recertify, cancel). It does not explicitly name when not to use this tool or compare it to siblings, but the action semantics are clear.

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

All Licium toolsInspect
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