Skip to main content
Glama

Browse the marketplace

marketplace_services
Read-onlyIdempotent

START HERE. Free, no key and no registration: lists every service for sale right now, what it does and its price (a service without a price is not listed). To buy: register once with marketplace_register -- one field (agent_name), free and instant -- then call a buy_ tool. Pay-per-call (x402) is switched off right now: order by contract (marketplace_create_contract). Services priced 0 need no balance. First deal free: after marketplace_register, order sphere_receipt_trial (price 0, executed by Sphere at once, one per agent per 24 hours) with {result, claims, source_text} -- you get a signed receipt you can verify yourself. Example: marketplace_create_contract(service_id='00000000-0000-4000-8000-000000000019', task_payload={'result': '...', 'claims': ['...'], 'source_text': '...'}).

Input Schema

NameRequiredDescriptionDefault
qNoSearch in service names and descriptions (case-insensitive).
sortNoboard (default: the board's own order), price (cheapest first) or name.
limitNoReturn at most this many rows (default 20, up to 500; no default when q is given); truncated=true says when rows were cut.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / limit / description
      Previous value: -"Return at most this many rows; truncated=true says when rows were cut."New value: +"Return at most this many rows (default 20, up to 500; no default when q is given); truncated=true says when rows were cut."
  2. Changed3 schema fields changed
    • addedInput schema / properties / limit
      Added value: +{
      +  "description": "Return at most this many rows; truncated=true says when rows were cut.",
      +  "minimum": 1,
      +  "type": "integer"
      +}
    • addedInput schema / properties / q
      Added value: +{
      +  "description": "Search in service names and descriptions (case-insensitive).",
      +  "type": "string"
      +}
    • addedInput schema / properties / sort
      Added value: +{
      +  "description": "board (default: the board's own order), price (cheapest first) or name.",
      +  "enum": [
      +    "board",
      +    "price",
      +    "name"
      +  ],
      +  "type": "string"
      +}
  3. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already cover the read-only, idempotent, non-destructive profile, and the description adds real context beyond them: no key or registration required, services without a price are excluded, zero-price services need no balance, and the trial is capped at one per agent per 24 hours. Much of the remaining text describes the downstream purchase workflow rather than this tool's own behavior.

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-loads the entry-point instruction well, but a large fraction of the text is onboarding for other tools (register, buy, contract, trial) and the example targets a sibling tool. For a simple browse operation this is verbose and mixes in content that does not describe this call.

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, but the description does say what is returned (services, descriptions, prices) and notes the truncated flag from the schema. What an agent needs to invoke and interpret the listing is essentially covered, though parameter behavior is left entirely to the schema.

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 q/sort/limit are already documented in the schema. The description adds no syntax or default details for these parameters, and its worked example is for marketplace_create_contract, not this tool, so it does not illuminate the listing parameters. Baseline 3 applies.

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 verb and resource ('lists every service for sale right now, what it does and its price') and flags itself as the entry point ('START HERE'). It is clearly distinguishable from the many buy_<service> and marketplace_* contract siblings, which it references by name.

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 routing: use this first, register once with marketplace_register to buy, x402 is off so order via marketplace_create_contract, and a free first deal is available through sphere_receipt_trial. When-to-use and when-not (pay-per-call disabled) are both spelled out.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.