Bearer Pilot Onboarding

How a Bearer pilot works, end to end. Pilots are email-driven so we can scope the work together before anything is metered. There is no self-serve signup page and no credit card form — that is intentional at this stage of the tier's life.

How a pilot works

The whole flow, at a glance:

1. You email us with a short use-case description — what you're building, which tools you'd call, roughly how often
2. We scope the pilot together — length (30–60 days is typical), rate-limit shape, success criteria, cost
3. We issue a Bearer key — a single key delivered over a secure channel
4. You plug the key into your MCP client — standard Authorization: Bearer <key> header, no client-code changes beyond that
5. We review together at the end — did it work, what should change, is a longer engagement the right shape

The whole thing is designed to be low-ceremony. If a pilot doesn't make sense yet, we'll say so during the scoping conversation and point you back to the anonymous tier.

Step by step

Step 1 — Email us with your use case

Send a short note to admin@markcolabs.com covering:

• What you're building — one paragraph, plain English
• Which of the 13 tools you'd be calling (see the API Reference for the list)
• Rough call volume — per day, per week, or peak burst
• Any timing constraint — production launch date, procurement window, demo deadline

We usually reply within two business days. You do not need to have your MCP client wired up before you email — we'd rather scope first and integrate second.

Step 2 — Scope the pilot together

We'll set up a short scoping call (or continue by email if you prefer). The goal is to align on:

• Pilot length — 30 days is the default; 60 days for larger integrations with staged rollouts
• Rate-limit window — sized to your expected load, with headroom for bursts
• Success criteria — what "the pilot worked" looks like from your side (e.g., "answered X production questions with citations," "reduced our hallucination rate on retirement math to 0")
• Cost — scoped per pilot; we don't publish a rate card yet and would rather have the number reflect what you actually need
• Terms — a short pilot agreement layered on top of LICENSE-API.md covering the specifics

Step 3 — We issue your Bearer key

Once the pilot is scoped, the maintainer generates a key. Under the hood this runs from an authenticated environment:

node infra/mcp/scripts/issue-key.mjs --write --pilot <partner>

The script writes a hashed record to DynamoDB (per the contract and ADR-0045) and emits the plaintext key exactly once. That key is then delivered to you over a secure channel — never over plaintext email or a public Slack channel. Concretely: a 1Password shared item, a Signal message, or a PGP-encrypted email. We will confirm with you which channel is workable on your end before generating the key.

Step 4 — Plug the key into your MCP client

The endpoint is the same as the anonymous tier — https://mcp.digitalcalculator.info/mcp — but every request now carries an Authorization header:

curl -X POST https://mcp.digitalcalculator.info/mcp \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer <YOUR_KEY_HERE>' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"mortgage_monthly_payment","arguments":{"principal":300000,"annualRatePercent":6.5,"termYears":30}}}'

The plaintext key in your header looks like dc_pilot_XXXXXXXX... (32 lowercase alphanumeric characters after the prefix). If you're integrating via an MCP client library, look for its Bearer / API-key config option:

• Claude Custom Connectors — add the key under the connector's "Authentication" field when creating the connector in claude.ai
• MCP Inspector — add the header via the transport configuration panel
• Raw HTTP / SDK — set Authorization: Bearer <key> on every POST to /mcp
• npm shim (@markcolabs/mcp) — the shim forwards the Authorization header from your client to the hosted endpoint; set it in your MCP client config as usual

Once the key is in place, tool responses are byte-identical to what the anonymous tier returns for the same inputs — per the anonymous-parity invariant. What changes is the rate-limit shape, the per-key attribution, and the support relationship. See the API Reference for the tool schemas; nothing about the tool contracts changes for authenticated calls.

Step 5 — End-of-pilot review

Toward the end of the pilot window, we schedule a review call (or email exchange) covering:

• Did the pilot meet the success criteria we agreed on in step 2?
• What surprised you — positive or negative?
• Were the rate limits sized right? Did you hit them? Were they too loose?
• Any tool coverage gaps you'd want in a longer engagement?
• Next step: continue, extend, restructure, or stop

If we're both happy to continue, we roll into a longer engagement (terms, cadence, and pricing set together at that point). If not, we revoke the key cleanly, both sides walk away with what they learned, and the anonymous tier remains open to you forever.

What we ask of a pilot partner

Pilots are a two-way commitment. From your side, we ask:

• An honest use case — describe what you're actually building, not a placeholder ("we might use it for something later")
• Willingness to give feedback — the whole point of a pilot is to learn something. If you hit rough edges, tell us; that is more valuable than a smooth pilot with no signal
• Tolerance for iteration — the Bearer tier is new; a rate-limit or contract detail may need to move mid-pilot. We'll flag anything material in writing before changing it
• Reasonable security hygiene on the key — store it in a secrets manager, don't check it into git, rotate it if a laptop is lost

FAQ

Can I test the tools without a Bearer key first?

Yes — that is exactly what the anonymous tier is for. Point your MCP client at https://mcp.digitalcalculator.info/mcp with no Authorization header and every tool works. Use the anonymous tier to verify the tool outputs meet your accuracy expectations before you commit to a pilot. The math is byte-identical between anonymous and Bearer responses (anonymous-parity invariant).

Do you offer free trials of the Bearer tier?

The pilot itself is the trial. We scope pilots that are short and finite (30–60 days) precisely so both sides can walk away cleanly if it doesn't fit. There is no "free trial that auto-converts to paid" — every engagement is explicit.

What happens after the pilot ends?

One of three outcomes: (1) we continue into a longer engagement on terms set during the review, (2) we extend the pilot for another window to answer a specific open question, (3) we wind down cleanly — we revoke the key, you continue on the anonymous tier if the use case fits it. There is no lock-in.

What happens if I lose my Bearer key?

Bearer keys are stored server-side as a SHA-256 hash — we don't have the plaintext either. If you lose the key, email us; we'll revoke the old one and issue a new one via the same secure-channel process from step 3. There is no self-serve rotation UI yet; that is on the roadmap for when the tier is broader.

Can I get multiple keys for staging and production?

Yes — we can issue separate keys for staging and production environments so you can independently monitor and revoke each. Mention this in your initial email so we scope it into the pilot from the start.

References

• Pricing — two-tier overview, feature comparison
• Versioning contract — SemVer policy, anonymous-parity invariant, deprecation window
• API Reference — input schemas and output shapes for all 13 tools
• Quickstart — first call in under 5 minutes (anonymous tier)
• FAQ — general questions about the server

Ready to start? Email admin@markcolabs.com with the four bullet points from step 1.