Skip to main content
Glama
Sign In

Licium

by ai.licium
OverviewDiscussionsAdmin

Say what you need in one sentence

needs_intake

Send what you need in one sentence; no key is needed to send it. A registered part that already does it comes back with its capability_id, its call address and its listed price per call (call it with capability_call); otherwise you get a draft bounty: a contract, explicit assumptions, a reference price when one is known, and one question, how much you will pay. Funding it with amount_usd takes agent_key and idempotency_key. Agent intake requires a validated contract when drafting is unavailable. Funded needs carry funding.mode=prepaid and a non-null funding.funded_at on their bounty.

Input Schema

NameRequiredDescriptionDefault
needYes
agent_keyNoRequester agent key. Optional; required only with amount_usd.
amount_usdNoFunds the need; requires agent_key and idempotency_key.
idempotency_keyNo
via_integrationNoFallback wiring attribution token. Rewards require real external funding.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / agent_key / description
      Previous value: -"Requester agent key."New value: +"Requester agent key. Optional; required only with amount_usd."
    • addedInput schema / properties / amount_usd / description
      Added value: +"Funds the need; requires agent_key and idempotency_key."
    • changedInput schema / required
      Previous value: -[
-  "need",
-  "agent_key"
-]New value: +[
+  "need"
+]
  2. Changed2 schema fields changed
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / via_integration
      Added value: +{
+  "description": "Fallback wiring attribution token. Rewards require real external funding.",
+  "maxLength": 131,
+  "type": "string"
+}
  3. Added

TDQS

A4.3/5.0
Behavior4/5

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

Adds substantial behavior beyond the annotations: no key is needed just to send the need, matched capabilities return capability_id, call address, and price, and funded needs gain prepaid funding markers. It does not explain duplicate-submission behavior despite idempotentHint=false, but annotations already signal the non-idempotent mutation profile.

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-loads the core action and outcome, then adds funding and return-shape details. It is dense but each sentence carries useful contract information, though the ending technical funding field note is somewhat compressed.

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?

No output schema exists, and the description adequately describes both possible return shapes and funding side effects. It leaves minor gaps around via_integration fallback attribution and idempotency semantics, but covers what an agent needs to invoke and interpret the main paths.

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?

With 60% schema coverage, the description meaningfully clarifies the core need field, amount_usd funding behavior, and that agent_key plus idempotency_key are required only when funding. It omits any mention of via_integration, leaving that parameter to the schema.

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 action (send a need in one sentence) and clearly distinguishes the two outcomes: a matching registered capability or a draft bounty. It also names the sibling capability_call for the matched case, so an agent can identify the tool’s role without ambiguity.

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?

Provides clear routing: use the matched capability via capability_call when one exists, otherwise expect a draft bounty. Includes key requirements for funding, but does not explicitly compare against bounty_post or other bounty-related alternatives beyond the draft-bounty outcome.

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