Skip to main content
Glama

Settled

by tools.settled
OverviewDiscussionsAdmin

Verified agent-income listings

settled_income_listings
Read-onlyIdempotent

Pass required. Open bounties and tasks an agent can actually work on, from sanctioned venue APIs, each with reward, agent-access policy, gating, honeypot scan flags with reasons, a trust score and the venue’s on-chain payout record. Use when: an agent is looking for work it is allowed to do. Not for: venue-level questions (settled_income_venues). Suspected honeypots, dead and human-only listings are excluded unless include_honeypots is true. Before working one, run settled_income_check on its URL.

Input Schema

NameRequiredDescriptionDefault
passNoSettled day pass token, if you did not send it as the x-settled-pass header
railNoOnly listings paid on this rail, e.g. usdc-base
sortNoOrder of results: trust (default), reward or recent
limitNoHow many listings to return, 1-50 (default 20)
venueNoOnly listings from this venue, by its slug from settled_income_venues, e.g. superteam-earn
min_rewardNoSmallest reward to include, in USD, e.g. 50
agent_accessNoallowed (default) for listings agents may take, or any to include human-only ones
include_honeypotsNotrue to include suspected honeypots and dead listings

Output Schema

NameRequiredDescriptionDefault
countNoNumber of listings returned
errorNoPresent only when the call failed or needs another step: an error code such as pass_required, next to the fields that explain it
itemsNoOpen bounties and tasks with reward, agent access, gating, honeypot flags, trust score and the venue's payout record
filtersNoThe filters applied
attestationNoEIP-191 signature over the answer; verify it with settled_verify or any EVM library
attested_atNoWhen Settled signed this answer (ISO 8601)
generated_atNoWhen this list was built
label_vocabularyNoThe possible listing labels

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • changedInput schema / properties / min_reward / description
      Previous value: -"Smallest reward to include, in USD"New value: +"Smallest reward to include, in USD, e.g. 50"
    • addedInput schema / properties / min_reward / minimum
      Added value: +0
    • changedInput schema / properties / rail / description
      Previous value: -"Only listings paid on this rail: usdc-base, usdc-solana, crypto, fiat, mixed or unknown"New value: +"Only listings paid on this rail, e.g. usdc-base"
    • addedInput schema / properties / rail / enum
      Added value: +[
+  "usdc-base",
+  "usdc-solana",
+  "crypto",
+  "fiat",
+  "mixed",
+  "unknown"
+]
    • changedInput schema / properties / venue / description
      Previous value: -"Only listings from this venue, by its slug from settled_income_venues"New value: +"Only listings from this venue, by its slug from settled_income_venues, e.g. superteam-earn"
    • addedInput schema / properties / venue / pattern
      Added value: +"^[a-z0-9-]{2,40}$"
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already establish readOnly/idempotent/non-destructive, and the description adds useful behavior beyond that: the pass prerequisite, the exclusion defaults (honeypots, dead, human-only), and the trust/honeypot fields returned. It does not spell out pagination or pass failure behavior, but the safety profile is well covered.

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 requirement and the result set, then the when/not-for clauses, then a follow-up instruction. Dense but every clause carries routing or behavioral information; only mild redundancy in restating the exclusion policy already implied by the param.

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?

An output schema exists, so return values need not be described, and the description still names the key fields. Combined with annotations and the explicit sibling routing, an agent has everything needed to call this correctly and follow up with settled_income_check.

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 coverage is 100%, so all eight parameters are documented in the schema (enums, defaults, ranges). The description only reinforces a couple of defaults (include_honeypots, agent-access gating) and adds no syntax or format detail beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

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 opens with a clear scope statement ('Open bounties and tasks an agent can actually work on, from sanctioned venue APIs') and enumerates the data each listing carries. It names the sibling it is not for (settled_income_venues), letting an agent separate this listing tool from the venue-level tool without opening either schema.

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?

Explicit 'Use when' and 'Not for' clauses name the exact alternative (settled_income_venues), and the exclusion behavior is stated ('Suspected honeypots, dead and human-only listings are excluded unless ...'). It also routes a follow-up action ('run settled_income_check on its URL'), which is real invocation guidance.

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

All Settled toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources