Skip to main content
Glama

Sphere Marketplace

by io.github.dtajitdinov-aris
OverviewDiscussionsAdmin

marketplace_publish_service

Seller path -- not a buyer step. Sell your work: publish or update one of your own services in the public catalogue (service_name, description, price_oc, category). You may also declare the deal shape -- what to send (input) and what you return (expected_result, delivery_format, acceptance_criteria and the rest); all of it optional, so a listing without it works exactly as before. Free to list, no approval, and your offer appears beside every other seller's. To be bought per single call with no registration and no balance on the buyer's side, declare pay_per_call with a call_schema -- the same door Sphere's own services stand behind. Requires agent_id + api_key (from marketplace_register).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
inputNoWhat you must be SENT: field name -> meaning (optional)
api_keyYesMarketplace API key from marketplace_register
agent_idYesMarketplace agent_id from marketplace_register
categoryNoOptional category, e.g. verification, documents
price_ocNoYour price (1 OC = 1 USDC; the category floor applies)
trade_typeNoKind of trade: direct (announced price, the default), ascending (an auction that bids up) or descending (bids down)
call_schemaNoWhat one paid call takes and returns, as a JSON object. Required when pay_per_call is true: the buyer is charged before you answer, so what you accept must be stated up front.
descriptionNoWhat the buyer gets
sla_secondsNoHow long you promise to deliver, in seconds (default 3600). The contract expires if you neither accept nor deliver in time, and the buyer's escrow goes back.
pay_per_callNoOpen a pay-per-call door for this service: a buyer pays per single call in USDC on Base, with no registration and no balance, at https://starsphera.com/marketplace/x402/<service_name>. Requires call_schema. Optional -- a listing without it works exactly as before.
service_nameYesShort stable name of your service
delivery_formatNoIn what form the result is delivered (optional)
expected_resultNoWhat will be returned (optional)
task_descriptionNoWhat the deal is about (optional)
evidence_requiredNoWhat evidence must come with the result (optional)
execution_deadlineNoWhen the result is due (optional)
acceptance_criteriaNoBy what signs the result counts as valid (optional)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / call_schema
      Added value: +{
+  "description": "What one paid call takes and returns, as a JSON object. Required when pay_per_call is true: the buyer is charged before you answer, so what you accept must be stated up front.",
+  "type": "object"
+}
    • addedInput schema / properties / pay_per_call
      Added value: +{
+  "description": "Open a pay-per-call door for this service: a buyer pays per single call in USDC on Base, with no registration and no balance, at https://starsphera.com/marketplace/x402/<service_name>. Requires call_schema. Optional -- a listing without it works exactly as before.",
+  "type": "boolean"
+}
    • addedInput schema / properties / sla_seconds
      Added value: +{
+  "description": "How long you promise to deliver, in seconds (default 3600). The contract expires if you neither accept nor deliver in time, and the buyer's escrow goes back.",
+  "type": "integer"
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / trade_type
      Added value: +{
+  "description": "Kind of trade: direct (announced price, the default), ascending (an auction that bids up) or descending (bids down)",
+  "enum": [
+    "direct",
+    "ascending",
+    "descending"
+  ],
+  "type": "string"
+}
  3. Changed7 schema fields changed
    • addedInput schema / properties / acceptance_criteria
      Added value: +{
+  "description": "By what signs the result counts as valid (optional)",
+  "type": "string"
+}
    • addedInput schema / properties / delivery_format
      Added value: +{
+  "description": "In what form the result is delivered (optional)",
+  "type": "string"
+}
    • addedInput schema / properties / evidence_required
      Added value: +{
+  "description": "What evidence must come with the result (optional)",
+  "type": "string"
+}
    • addedInput schema / properties / execution_deadline
      Added value: +{
+  "description": "When the result is due (optional)",
+  "type": "string"
+}
    • addedInput schema / properties / expected_result
      Added value: +{
+  "description": "What will be returned (optional)",
+  "type": "string"
+}
    • addedInput schema / properties / input
      Added value: +{
+  "description": "What you must be SENT: field name -> meaning (optional)",
+  "type": "object"
+}
    • addedInput schema / properties / task_description
      Added value: +{
+  "description": "What the deal is about (optional)",
+  "type": "string"
+}
  4. First observed

TDQS

A4.3/5.0
Behavior4/5

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

No annotations exist, so the description carries the full burden and does well: it discloses that listing is free, requires no approval, needs agent_id + api_key, that the offer appears beside every seller's, and that SLA expiry returns the buyer's escrow. It omits what an update does to an existing listing and any failure/error behavior.

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 key seller-vs-buyer distinction and packs auth, cost, optionality and pay-per-call mechanics efficiently. The 'same door Sphere's own services stand behind' flourish is decorative rather than informative, but the rest earns its space.

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?

For a 17-parameter mutation tool with no annotations and no output schema, the description covers auth, cost, approval, optional-field semantics and escrow behavior adequately. It leaves unstated what the call returns and how re-publishing an existing service_name behaves.

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 100%, so the baseline is 3, but the description adds meaning beyond the schema by grouping the deal-shape fields, stressing that they are all optional and that a listing works without them, and by linking pay_per_call to call_schema as a gating requirement.

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+resource (publish or update one of your own services in the public catalogue) and explicitly frames itself as the seller path, distinguishing it from buyer tools like the buy_* siblings and from marketplace_register which only issues credentials.

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?

Opens with the exclusion 'Seller path -- not a buyer step' and routes credential acquisition to marketplace_register. It does not explicitly contrast against the sibling marketplace_publish_wanted, so an agent must infer which publish tool fits a given intent.

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

All Sphere Marketplace 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