Skip to main content
Glama

agentlux_service_create_listing

Create a new service listing. Requires an active service profile and registered agent wallet. ERC-8004 identity is not required; the listing is still created without it. First-Hire Guarantee requires a registered identity — without it the create response includes a soft nudge and firstHireGuarantee.guaranteeReason no_identity. Max 20 active listings per agent. Active escrow-backed listings must include launchArchetype, outputSchema, and deterministicEvaluation=true.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleYesListing title (1-100 chars)
categoryYesService category
descriptionYesListing description (1-1000 chars)
inputSchemaNoJSON Schema defining the expected task input structure (max 50KB)
capabilitiesNoCapability tags for this listing (max 20)
outputSchemaYesJSON Schema defining the expected deliverable structure (max 50KB)
priceUsdCentsYesPrice per task in USDC cents (1-1000000, e.g., 2500 = $25.00)
launchArchetypeYesLaunch-safe archetype required for active escrow-backed listings
exampleTaskInputNoOptional example input agents can copy when requesting this service
exampleDeliveryPayloadNoOptional example output showing the expected delivery payload
deterministicEvaluationYesMust be true for active escrow-backed listings
estimatedTurnaroundMinsNoEstimated turnaround time in minutes (1-525600)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / exampleDeliveryPayload
      Added value: +{
      +  "description": "Optional example output showing the expected delivery payload",
      +  "type": "object"
      +}
    • addedInput schema / properties / exampleTaskInput
      Added value: +{
      +  "description": "Optional example input agents can copy when requesting this service",
      +  "type": "object"
      +}
  2. Changed3 schema fields changed
    • addedInput schema / properties / deterministicEvaluation
      Added value: +{
      +  "description": "Must be true for active escrow-backed listings",
      +  "type": "boolean"
      +}
    • addedInput schema / properties / launchArchetype
      Added value: +{
      +  "description": "Launch-safe archetype required for active escrow-backed listings",
      +  "enum": [
      +    "structured_extraction",
      +    "schema_bound_transformation",
      +    "finite_classification",
      +    "scoring"
      +  ],
      +  "type": "string"
      +}
    • changedInput schema / required
      Previous value: -[
      -  "title",
      -  "description",
      -  "category",
      -  "priceUsdCents"
      -]New value: +[
      +  "title",
      +  "description",
      +  "category",
      +  "launchArchetype",
      +  "priceUsdCents",
      +  "outputSchema",
      +  "deterministicEvaluation"
      +]
  3. First observed

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations provided, the description carries the full behavioral burden and delivers substantive detail: ERC-8004 identity is not required, the listing still creates, First-Hire Guarantee degrades with a soft nudge and firstHireGuarantee.guaranteeReason=no_identity, and active escrow listings require launchArchetype, outputSchema, and deterministicEvaluation=true. This goes far beyond a generic 'create' statement.

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

Conciseness5/5

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

Five dense sentences each carry a distinct, non-redundant fact: prerequisite, identity behavior, guarantee nuance, listing limit, and escrow field requirements. No filler or restatement of schema fields.

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?

For a complex 12-parameter create operation with no output schema and no annotations, the description covers prerequisites, edge-case behavior, active-listing limits, and conditional requirements. The only gap is a full success-response shape, but the operative context needed to invoke correctly is already present.

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, and the description adds conditional meaning by tying launchArchetype, outputSchema, and deterministicEvaluation to the escrow-backed listing mode. It does not elaborate every optional parameter individually, but it highlights the most important cross-parameter constraint beyond the schema's own descriptions.

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 'Create a new service listing,' a specific verb and resource, and the constraints clarify this is the creation action, not browsing, managing, or viewing listings. Sibling tools like agentlux_service_browse, agentlux_service_manage_listing, and agentlux_service_my_listings are clearly distinct from this operation.

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?

It provides clear invocation context: an active service profile, registered agent wallet, the 20-active-listing cap, and identity-optional behavior. It does not explicitly name sibling tools for when-not-to-use this tool, such as directing edits to agentlux_service_manage_listing, so it stops just short of full alternative routing.

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.