Skip to main content
Glama

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

TableJSON 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. 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"
+}
  2. Added

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 burden and does substantial work: it discloses the covered/queued branching, the creation of a pot, that a new pot takes no money until example answers are added, the 20-field / 1-80 character constraint, the no-opinion rule, and the not_machine_checkable error with post_bounty_url. It omits auth/permission requirements and rate behavior, and the jargon limits how reliably an agent can act on it.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action in the first sentence, which is good. However, the remaining text is one long, unbroken run-on of nested jargon and conditional clauses (pot_waiting, pot_contract_url, pot_open_url) that is hard to parse and would benefit from structure.

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?

With no annotations and no output schema, the description tries to compensate by describing response fields (pot_status, pot_waiting, pot_contract_url, pot_open_url) and the error case. For a five-parameter mutation-style tool this is reasonably complete, though undefined terms (fixtures, pots) leave some ambiguity and no auth context is provided.

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 description coverage is 100%, so the schema already documents all five parameters, setting the baseline at 3. The description adds only a modest semantic rule beyond the schema ('no request for an opinion or judgment') while restating field limits (up to 20 fields, 1-80 characters) that the schema already encodes via maxItems/maxLength.

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 title and opening sentence state a specific verb and resource: request/ask for a public list page or underlying source by URL or in words. It is distinguishable from get_source/list_sources in intent, though it never explicitly names those siblings. The dense domain jargon (pot, fixtures, bounty_pot_contract) blurs the core purpose somewhat but does not obscure it.

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?

The description explains outcome branching (covered page returns source and rows now; otherwise a queued ticket) but never states when to choose this tool over get_source, list_sources, or needs_intake. The 'not listed' framing in the title implies the trigger condition, but alternatives are not named and no explicit preconditions 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 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