For AI agents

One interface for agents to discover, order, execute, and verify real business services.

Use a shared service and order model across WebMCP, remote MCP, and HTTP. Discovery stays open; payment, sensitive context, and acceptance keep explicit approval boundaries.

What happens nextEvery request has one clear next step.

See what is waiting, who needs to act, and what will complete the work.

Review delivery→Accept or correct

The agent flow

Discover → Order → Execute → Verify.

A single contract carries the buyer from a reliable service description to an evidence-backed result.

Discover

Read the service registry.

Start with the canonical catalog and inspect the capability, inputs, price, and completion condition.

Output · a service the agent can trust
Order

Create an explicit request.

Submit the approved inputs and keep scope, authorization, and the next action attached to the order.

Output · a tracked order
Execute

Follow the live route.

Move through payment, human approvals, fulfillment, and exceptions without losing state.

Output · visible progress and ownership
Verify

Close with evidence.

Review the delivered result and accept or request correction from the signed receipt state.

Outcome · a verifiable completion

Connect quickly

Three routes. One registry.

Use the strongest structured connection available in the environment, then fall back without changing the service or order contract.

WebMCP

Preferred in-browser route

Use tools exposed by the current Quindart page when the browser supports WebMCP.

Zero setup for compatible browser agents

Remote MCP

Preferred remote route

Connect a Streamable HTTP MCP client to the stable Quindart endpoint.

https://quindart.com/mcp

HTTP API

Fallback route

Use the OpenAPI surface when MCP is unavailable or you need direct HTTP control.

GET /api/catalog · POST /api/orders

Capability matrix

Same capability, whichever surface you use.

Read-only discovery stays open. Commitments, payment, and acceptance remain explicit human approval boundaries.

CapabilityWebMCPMCPHTTPApproval
Discover servicescatalogcatalogGET /api/catalogOpen
Inspect a serviceinspect_servicecatalogGET /api/catalog/:slugOpen
Request scoperequest_scoperequest_scopePOST /api/project-inquiryHuman
Create fixed-price ordercreate_ordercreate_orderPOST /api/ordersHuman
Track deliveryget_orderget_orderGET /api/orders/:idOpen
Verify receiptreceiptreceiptGET /api/orders/:id/receiptOpen

Quick start

Machine-readable by default.

Use catalog first, then let the returned next_action choose the next call or human handoff.

Browse the human catalog
Catalog discovery

GET /api/catalog

{
  "purchase_mode": "fixed_price",
  "next_action": "buy_now",
  "agent": {
    "order_creatable": true,
    "payment_delegatable": false
  }
}
Create an order

POST /api/orders

{
  "serviceSlug": "agent-readiness-review",
  "name": "Buyer",
  "email": "buyer@example.com"
}
Continue from state

GET /api/orders/:id

{
  "state": "payment_required",
  "next_action": "human_payment_handoff",
  "can_agent_continue": false
}

Rules and recovery

Human approval stays explicit.

Agents should preserve uncertainty, show pending states as pending, and offer a recovery action when payment, delivery, or context is incomplete.

Can an agent buy without a human?

Agents can discover services and create an order with an approved key. The current payment rail hands the buyer to hosted Stripe Checkout, so the agent must present checkout_url and wait for confirmed payment.

What is the source of truth?

GET /api/catalog and GET /api/catalog/:slug. Never infer price, availability, scope, or delivery promises from old pages, search results, or cached prompt text.

What does human approval mean?

It marks actions that commit money, disclose sensitive context, accept delivery, or request a correction. The machine contract stays usable, but the approval boundary remains visible.

Where are the policy and manifest?

Read /.well-known/agent.md before acting. The machine-readable manifest, OpenAPI document, MCP server card, and copy-ready prompt are linked below.

  • Never invent price, availability, timing, or evidence requirements.
  • Do not call a side-effecting tool without explicit buyer intent.
  • A 402 is a hosted checkout handoff; it is not proof of payment.
  • Only a finality receipt proves verified completion.