Skip to main content
Glama
Sign In

Licium

by ai.licium
OverviewDiscussionsAdmin

Request a source that is not listed

request_source

Ask for a public list page by URL or in words. A covered page returns its source and rows now. Otherwise you get a queued ticket and, when eligible, a pot with its pot_status and subscription URL. A new pot waits (pot_status needs_fixtures) and takes no money until its example answers are added: the answer then has pot_waiting (who adds them and what happens next) instead of a pledge URL, pot_contract_url when your key can add them with bounty_pot_contract, and pot_open_url when anyone can open it by adding the first money with its contract (bounty_pledge with contract). A pot needs up to 20 named fields (1 to 80 characters each) and no request for an opinion or judgment; otherwise the response is not_machine_checkable with post_bounty_url.

Input Schema

NameRequiredDescriptionDefault
urlNoThe public list page.
needNoWhat source or rows you need, written in words.
noteNoAnything that helps a person judge it.
fieldsNoOptional columns you need. Omit or send [] for a ticket only.
via_integrationNoOptional integration attribution token.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / description
      Added value: +"Send exactly one of: url or need."
    • removedInput schema / oneOf
      Removed value: -[
-  {
-    "required": [
-      "url"
-    ]
-  },
-  {
-    "required": [
-      "need"
-    ]
-  }
-]
  2. Changed6 schema fields changed
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / fields / description
      Previous value: -"Columns you need."New value: +"Optional columns you need. Omit or send [] for a ticket only."
    • addedInput schema / properties / fields / items / maxLength
      Added value: +80
    • addedInput schema / properties / fields / items / minLength
      Added value: +1
    • addedInput schema / properties / fields / maxItems
      Added value: +20
    • addedInput schema / properties / via_integration
      Added value: +{
+  "description": "Optional integration attribution token.",
+  "maxLength": 131,
+  "type": "string"
+}
  3. Added

TDQS

A3.8/5.0
Behavior4/5

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

The description adds substantial behavior beyond the annotations: it distinguishes covered pages from queued tickets, explains pot_status states including needs_fixtures, and states that a new pot takes no money until example answers are added. It also describes which URL fields appear depending on eligibility. It does not cover auth prerequisites or ticket tracking details, but it is far richer than the annotations alone.

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 the core action and every sentence carries operational detail, with no obvious filler. It is dense and jargon-heavy in a single paragraph, which makes it harder to scan than it could be, but the length is largely justified by the workflow complexity.

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?

There is no output schema, so the description must carry return-value semantics, and it does explain source/rows, queued tickets, pot_status values, pledge-related URLs, and the not_machine_checkable error. It is nearly complete, though the term 'pot' is not independently defined and some prerequisite details are left implicit.

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 already 100%, so the baseline is 3. The description adds a meaningful semantic constraint not captured by the schema: fields must not ask for an opinion or judgment, and eligible pots require named fields. It otherwise largely reinforces schema details like the 20-field limit and 1-80 character bounds.

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 states a specific verb and resource: ask for a public list page by URL or in words. It clearly describes a request/intake action rather than a lookup, but it does not explicitly name or differentiate siblings such as get_source or list_sources.

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 by the title 'Request a source that is not listed' and by the request framing, but the description itself does not say when to use this versus get_source or list_sources. It describes outcomes after invoking the tool rather than selection guidance.

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