TOMO
BETA Partner connections are in beta and these docs are under review. Anything marked planned is not built yet — we confirm with you what is live before your service goes live.
Docs  ›  QUICKSTART

TOMO Partner Quickstart — Apply, Connect, Test

Audience: a business that wants to bring its service to TOMO, a personal SI agent. You have an MCP server, a REST/GraphQL API, or a shop with no tech at all.

How it works, in three steps:

  1. Connect your API or MCP server. TOMO is the MCP client — it connects to your server, reads your tools and matches them to what people ask for.
  2. Link accounts. If your customers sign in with you, they link their account to TOMO with OAuth 2.1 + PKCE. The token stays on TOMO's server.
  3. Test it in TOMO before it goes live. Our team runs real requests through TOMO with you. Nothing reaches real people until it is approved.

Every application is reviewed by a person. We don't promise a review time yet.

TL;DR

1. Apply at  https://www.automobnxt.com/business  (one form for every business)
2. We read every application and reply by email
3. Send us your MCP server address — TOMO connects as a client and reads your tools
4. If your users sign in with you, set up OAuth (with PKCE)
5. We test it together inside TOMO, then switch it on

Connect your MCP server

TOMO is an MCP client. It connects to your server over Streamable HTTP, calls initialize and tools/list, and matches each tool that carries a _meta.tomo block to a TOMO intent in docs/intents/_INTENT_CATALOG.md (see MCP_SPEC.md — intent and domain are both required).

Send your MCP server URL with your application. Today our team runs the probe. (planned: self-service MCP URL entry — not built yet.)

Only have a REST or GraphQL API? Wrap it in a small MCP server with the official MCP SDK (see MCP_SPEC.md). TOMO does not generate a wrapper for you.

No tech at all? Use the same application form and pick "No tech". We are opening this in steps and will write to you.

After approval — set up with our team

There is no self-serve partner dashboard open yet. Once your application is approved, our team sets up your connection with you, by email:

1. Your keys          — sandbox credentials, plus the webhook signing key you use to report completed orders
2. Your manifest      — which intents you serve, where, and at what price
3. Your verification  — the business details we check before production

(planned: a self-serve partner dashboard for these three steps.)

Your keys

What we issue to you:

client_id:            tomo_ci_<first 12 characters of your account ID>
client_secret:        tomo_sk_sandbox_<random> — shown ONCE
customer_id:          cus_<timestamp>_<random>
webhook_signing_key:  tomo_whk_<random> — shown ONCE, issued for the webhook URL you give us

Store the secret and the signing key in your secrets manager, never in source control. If you lose one, ask us for a new one — the old one stops working immediately.

Your manifest

For each intent you serve (every field is in MANIFEST_REFERENCE.md):

  • intent — exact full ID from docs/intents/_INTENT_CATALOG.md, e.g. food.order_delivery
  • domain — derived from intent namespace, e.g. food
  • pricing.min/max — your floor and ceiling per closed intent
  • service_area — list of cities or postal codes you cover
  • ttbs_signals — your self-rating on time/taste/budget/safety (0.0-1.0 each)
  • completion_callback — TOMO's completion URL for you, /api/v1/cpc/mcp_provider/<your_account_id> (you POST to it when an order completes — see WEBHOOK_SIGNING.md)
  • widget_type — which TOMO chat widget renders your results

A submitted manifest goes to pending_review. The latest manifest replaces the previous one.

Your verification (businesses in India)

Required only for production access:

  • GSTIN
  • FSSAI licence number if you serve food (other domain licences per your intent's spec are checked by our team during review)
  • Privacy policy URL (must be live and accessible)
  • Business name and legal entity type (private limited / LLP / partnership / proprietorship / individual)

Our team reviews it by hand and tells you by email.

Implementing tools (the actual work)

Once you have credentials and a manifest, the real engineering is implementing the tools required by your intents. Every intent spec in docs/intents/<intent>.md lists:

  • §3 — exact tools you must implement (search_*, get_*, create_*, cancel_*, track_*, etc.)
  • §4 — exact response shape (every field REQUIRED, no optionals — see Anti-Fabrication)
  • §6 — controlled vocabularies (no free-text in enum slots)

Read the gold reference: docs/intents/travel.book_hotel.md. It's the most complete example. Every other intent follows the same structure.

Anti-fabrication

The hardest part of integrating with TOMO isn't the tools — it's the completeness rule.

Every field in every response is REQUIRED. There is no "optional." If your system can't surface a field that the spec lists, you cannot list that intent on TOMO until you collect, derive, or contract a third-party data provider for that field.

This is harder than industry norm. It's intentional. TOMO Intelligence requires complete signal — incomplete listings are not a soft choice, they are a rejection condition.

Specifically forbidden (these violate TOMO's source-blind ranking contract — fields you must not return):

  • paid_placement_score, ad_bid, sponsored_rank, promotion_priority
  • kickback_amount, referral_fee_kickback, _partner_revenue_share
  • artificial_urgency_text (without backing inventory data)
  • ai_generated_photo (must be false)
  • Commission-based response shaping

Status — enforcement (honest): today, these rules are reviewed manually during compliance approval before your status flips to live. Server-side automated ingest rejection of forbidden fields is on the roadmap, not yet shipped. Violations found post-launch are handled by manual admin review. (planned: automated ingest scanner)

The full anti-fabrication rule list is in §13 of every intent spec. Read it carefully — these aren't suggestions.

Webhook signing — the close-intent POST

When the person completes the action you served (delivery delivered, ride completed, hotel checked in, etc.), you POST to TOMO's CPC webhook:

POST https://www.automobnxt.com/api/v1/cpc/mcp_provider/<your_account_id>
Headers:
  Content-Type: application/json
  X-TOMO-Timestamp: <unix_ms>
  X-TOMO-Signature: sha256=<hex_hmac>
Body:
  { intent, external_id, amount_inr, closed_at, notes }

The HMAC-SHA256 is computed over ${timestamp}.${rawBodyJSON} with your webhook_signing_key (issued by our team after approval).

Examples in Node.js, Python, and Go: WEBHOOK_SIGNING.md.

TOMO's commission is charged on amount_inr — and amount_inr is your NET supplier revenue. That means base price plus any supplier-kept fees and surge. Leave out of amount_inr: GST (goes to government), tips you collect for your driver/staff, third-party pass-through fees you don't keep. TOMO does not read separate fields for them — just send the net figure:

{
  "intent": "mobility.book_intracity_ride",
  "external_id": "trip_abc123",
  "amount_inr": 240,
  "closed_at": "2026-05-11T19:42:00Z"
}

No subscription fee, no setup fee, no inflated CPC.

Going live

After our team approves your connection, your tools can be offered as choices when someone asks for what you serve. Ranking is source-blind via TTBS — when partner results are switched on, TOMO ranks on the TTBS signals you declare, weighted for the domain. (planned: learning from delivered results — latency, success rate, ratings.)

No partner has a paid path to the top. No partner gets favorable treatment because of commission negotiations.

Common questions

Do users see "powered by [my brand]"?

Yes — your brand name and source label appear on every result card we render in TOMO chat. Users tap your row, see your supplier badge, complete via your flow. TOMO is the orchestrator, not the merchant of record. (Partner results stay switched off until the first partner is approved.) (planned: logo + customer support phone fields on the supplier badge — not yet shipped)

Can I see my TTBS score?

No. Partners cannot see how individual listings rank. This is by design and prevents gaming. (planned: a partner-facing ledger view — completed orders, fees, per-intent breakdown — not yet shipped. Today the ledger is recorded server-side from your completion POSTs.)

What if my response includes a forbidden field?

Today, forbidden fields (see §Anti-fabrication above) are caught during compliance review before your status flips to live. After launch, violations are handled through manual admin review and may result in your status being set to suspended. (planned: an automatic check that rejects responses at call time, and an error log you can see — neither is shipped yet.)

What if my SLA degrades?

Today, SLA management is manual — performance issues are reviewed by the admin team and your status may be set to suspended until resolved. (planned: automatic latency-p95 monitoring with auto-removal from the live pool and auto-rejoin on recovery — not yet shipped.)

Do I have to implement EVERY required field?

Yes. That's the rule. If your system genuinely doesn't have the data, build the collection pipeline before listing. Manifest submission validates the core fields (intent, domain, pricing.min/max, service_area); full per-field completeness is checked during the compliance review that gates production access.

Can I test in production without going through compliance?

No. Your tools are never offered to real people until our team approves your connection. Production needs the verification above (GSTIN, domain licences and a live privacy policy URL for businesses in India), checked by our team. (planned: request-level sandbox tagging on individual MCP calls — not yet shipped.)

How fast is sandbox onboarding really?

Every application is reviewed by a person, so there is no fixed time. The MCP probe exists but is run by our team today. (planned: self-service MCP URL entry — not built yet.)

Next steps

  1. Apply at automobnxt.com/business
  2. Read your target intent's spec — start with docs/intents/_INTENT_CATALOG.md
  3. Implement the tools per §3 and return responses matching §4
  4. POST the signed CPC webhook on close per §7
  5. Pass the sandbox-to-production checklist with our team
  6. Receive traffic. The customer pays you directly; you are billed TOMO's fee (one rate, the same for every business) on each completed order. TOMO never holds the money.

The spec is the contract. Every connection is reviewed and tested with you by a person before it goes live.

Reference docs

Built by AUTOMOBNXT · DPIIT Recognised Startup · 2026.

Apply to connect →

Built by AUTOMOBNXT · DPIIT Recognised Startup · 2026