ServerConnect — The Playbook

A practical launch guide for NIGHTSHIFT and IMD
Research edition: 17 October 2026. Live observations: approximately 21:37–21:42 UTC. Prices, catalogs and availability can change.

1. The decision: connect first, sell one useful outcome

Use NIGHTSHIFT’s existing hosted MCP at https://getnightshift.tech/mcp to manage a NIGHTSHIFT company. Use the separately maintained RobertKodes/imd-mcp connector when an assistant needs to commission work directly from IMD. Start by selling a downloadable workflow pack through a NIGHTSHIFT company. There is no evidenced need to build another MCP server to get started.

This report interprets “sell skills” as selling reusable instructions, examples and acceptance checks that help an operator complete a job. It also explains the separate path for charging for execution. A purchased skill file, an MCP tool and an IMD catalog skill are three different things; publishing one does not automatically create the others.

The most useful first offer is ServerConnect Starter, proposed at 29 USDC: a connection checklist, a reusable workflow, two request examples, a troubleshooting sheet and a verified sample result. Sell the reduction in setup errors and uncertainty. Free connectors already exist; charging merely for their URLs is a weak offer.

What can be done today: connect an owner’s client, inspect its actual tool schemas, validate a bounded brief for free, commission a small approved job, inspect the delivered files, and prepare a product page. What remains unproved: authenticated NIGHTSHIFT tool operation, seller onboarding, a paid purchase, protected delivery and withdrawal. Those require an owner’s account and a controlled transaction; this research did not perform them.

How to read the evidence

• Observed: a public response or public source file inspected during this research. An API’s statement about its own state is still self-reported.
• Documented: a capability described by its publisher, without an end-to-end test here.
• Inference: a conclusion drawn from the evidence, with its limits stated.
• Proposal: a product, price, design or operating rule recommended by this report.
• Open: information not established by the available evidence.

All commercial prices, conversion targets and time budgets below are proposals, not measured demand or promised results.

2. What actually exists

Component	Finding and evidence	Practical consequence
Correct NIGHTSHIFT	Its public site describes a company-building service using IMD and selling digital goods for USDC. The delivered application has company, market and MCP views. Observed source; operation documented. Site, application asset.	Use this domain. Search results for other “Nightshift” coding tools and security scanners are unrelated.
Runtime state	GET /api/health returned mode: live, requireAuth: true, salesChainId: 8453, platformFeeBps: 150, and imdUsd: 5.44. Observed self-report. Health.	Model Base sales and a 1.5% withdrawal fee, but recheck before funding. The IMD USD value is indicative, not an executable exchange quote.
Hosted MCP	An unauthenticated MCP initialization POST returned HTTP 401 and asked for a dashboard API key in a bearer header. Observed. MCP endpoint and instructions.	The endpoint responds to MCP traffic. Successful initialization and its authenticated tool list remain untested.
Market	The public response was {"mode":"live","chainId":8453,"products":[]}. Observed snapshot. Market API, market view.	No listings were returned at that moment. This is neither evidence of sales nor proof that publishing is broken.
IMD commissioning	Capabilities advertised seven actions, 0.5 IMD per ordinary action, Ethereum mainnet payment and a 600-second quote lifetime. Schedules are priced per run. Observed API contract. Capabilities.	Buying production work and selling its result use separate payment rails. Read capabilities again before any payment.
IMD work catalog	/skills returned 56 entries, including research-report v1 and build-website v9. Both had judge: verifier-paths and checks: none. Observed metadata. Catalog.	Do not turn “accepted” into a claim of independently verified research, behavior or security. Entries include internal/reference roles, not 56 retail products.
Direct connector	The NIGHTSHIFT MCP view links to RobertKodes/imd-mcp; that repository declares MIT licensing and says it is not affiliated with IMD. Documented. Connector.	Treat it as a separate dependency, with its own source review and release pin.

The supporting repository includes timestamped observations and saved free-check responses. They record what was seen; they are not an independent audit.

The four connections

Owner's assistant ── bearer API key ──> NIGHTSHIFT hosted MCP
                                              │
                                     company and spending policy
                                              │
                                              v
                                       IMD production work

Owner's assistant ── local stdio connector ──> IMD API (direct commissioning)

Buyer/browser/agent ── USDC on Base ──> NIGHTSHIFT product checkout
                                              │
                                              v
                                        delivered product

The lower path is the commercial delivery flow advertised by NIGHTSHIFT. It has not been payment-tested here. MCP supplies the assistant’s tools; it does not itself supply payment settlement, product licensing or file protection. MCP tools specification, x402 payment flow.

3. Connect to NIGHTSHIFT in one working session

Prerequisites

Have the owner’s browser wallet, access to the NIGHTSHIFT dashboard and an MCP-capable client. A NIGHTSHIFT API key is distinct from a wallet private key and from IMD’s order-read token. Never put the latter two into a NIGHTSHIFT bearer header.

Documented setup: open NIGHTSHIFT’s MCP page, sign in with the owner wallet, create a labeled API key and copy it while displayed. The application provides key revocation. The page advertises company inspection, creation, shifts, approvals, limits, pausing and withdrawals. These are advertised operations, not an authenticated discovery result from this research.

Claude Code example

The site supplies this HTTP connection pattern; Claude’s documentation supports HTTP MCP servers and custom headers. Run it on the owner’s workstation, entering the real key when prompted. The variable is populated interactively, not supplied in this report.

read -r -s -p 'NIGHTSHIFT API key: ' NIGHTSHIFT_API_KEY
printf '\n'
claude mcp add --transport http nightshift \
  https://getnightshift.tech/mcp \
  --header "Authorization: Bearer $NIGHTSHIFT_API_KEY"
unset NIGHTSHIFT_API_KEY

The client may persist the header in its own configuration. Protect that configuration and revoke the dashboard key if it is exposed. For Cursor, the site supplies an mcpServers entry using url and an Authorization header; use the dashboard-generated value. NIGHTSHIFT connection page, Claude MCP documentation.

Success criteria: the client completes initialization; tools/list returns names and input schemas; a read-only company-list operation succeeds for the signed-in owner. Save names and schemas, never the authorization header, in the team’s integration notes. Tool discovery and invocation are separate protocol operations. MCP tools.

Suggested first instruction to the assistant:

Inspect this server’s tools and schemas. List my companies and summarize their status and current spending limits. Do not create, fund, shift, approve, change settings, buy or withdraw anything. If a required read operation is unavailable, show the error and stop that operation.

Use a permission ladder

Stage	Allow	Exit condition
Inspect	Company reads and market discovery, where present	Correct owner and company are visible
Prepare	Draft a company idea and spending proposal	Owner has reviewed the exact proposal
Pilot	One expressly approved production request	A delivered file is inspected against its brief
Sell	One approved product and price	An external buyer can receive the intended file
Operate	Bounded shifts with human review	Reconciliation and pause controls have been exercised

This is a proposed client policy. Server-side read-only scopes were not established. A prompt or a disabled UI button is not proof that a token cannot invoke a write operation.

The application advertises nightshift_companies, nightshift_company, nightshift_create, nightshift_shift, nightshift_approve, nightshift_decline, nightshift_limits, nightshift_pause and nightshift_withdraw. Its market view additionally names nightshift_market. Inspect the authenticated schemas before calling any of them; do not guess arguments from these names. NIGHTSHIFT MCP and market application.

If connection fails: a 401 points first to a missing/revoked/wrong key; a page of HTML points to transport or routing rather than successful MCP initialization. A browser GET to /mcp can display the site’s instructions while a POST serves protocol traffic. HTTP MCP uses JSON-RPC and transport negotiation; test through the client, not by judging the browser page. MCP transports.

4. Commission IMD directly, without confusing the connectors

Use direct IMD access when you want an assistant to buy a specific report, site or tool without delegating business management to a NIGHTSHIFT company.

There are at least two similarly named repositories. The older commissioned identity-md-launches/launch-600-build-imd-mcp-model-context calls its payment tool imd_pay and labels itself experimental. The connector linked by the current NIGHTSHIFT site is RobertKodes/imd-mcp, whose payment tool is imd_order. Their tool names and settings are not interchangeable. Commissioned connector README, site-linked connector README.

Start without a wallet

The inspected site-linked package is version 0.2.0, requires Node.js 20 or later, and uses stdio. The inspected commit is 15fcbf9ba01f7a7e6089cc2afeef9acfc50d757f. This is a reproducible research reference, not a claim that it will always be the best release. Pinned package metadata.

Example client configuration for an initial read-only installation:

{
  "mcpServers": {
    "imd_swarm": {
      "command": "npx",
      "args": [
        "-y",
        "github:RobertKodes/imd-mcp#15fcbf9ba01f7a7e6089cc2afeef9acfc50d757f"
      ],
      "env": {
        "IMD_READ_ONLY": "1",
        "IMD_DAILY_CAP": "0.5",
        "IMD_MAX_PER_ORDER": "0.5",
        "IMD_REQUIRE_CONFIRM": "1"
      }
    }
  }
}

This is a configuration example, not an installed dependency bundled with this report. The reader needs network access to install it. First installation executes package build scripts; inspect the pinned source before running it. We did not install or launch it here.

A concrete setup caveat: at this commit, the CLI’s setup output switches its execution target to unscoped npx -y imd-mcp, even when setup was launched from the GitHub repository. Preserve the explicit GitHub commit in the final client configuration above. This avoids silently changing the package source. Pinned CLI source.

The useful workflow

1. imd_find_existing: search for a usable result before commissioning another.
2. imd_draft: describe a report, website, tool, audit, image or contract project.
3. Inspect the returned body, plan, blockers, price and similar work. A draft supplies a local connector checkToken; changing the body requires checking it again.
4. Only after the owner approves the exact paid proposal, use imd_order with that body and its token.
5. Use imd_track to follow the returned identifier; keep the order history for reconciliation.

These are documented tools, with their input validation visible in the pinned server source. Direct HTTP free checks do not themselves produce the connector’s local checkToken.

A free draft example:

{
  "kind": "report",
  "brief": "Write a current operator guide for connecting NIGHTSHIFT to an MCP client and selling one downloadable skill pack. Cite primary sources; distinguish observations, recommendations and unknowns. Include a checklist, bounded cost model and failure recovery. Never transact or publish anything.",
  "minCitations": 5
}

Call that as the arguments to imd_draft, not as a raw /requests/check body. Its kind and brief shape comes from the inspected connector. Draft tool schema.

A first paid pilot

Proposal: use a separate order wallet holding only 0.5 IMD for one job, plus ETH for any necessary approval gas. Leave the main treasury disconnected. After the owner deliberately enables payments, configure their own key file; never distribute a key inside a skill pack. The connector has wallet-creation and Permit2-approval operations. Its inspected defaults are 2 IMD/day and 0.5 IMD/order; the example above deliberately narrows the daily limit. Configuration source, wallet operations.

Code-review inference, not an exploit test: the site-linked connector checks its spending gate, awaits balance/payment work, then records the order. Its saver uses a JSON file. No cross-process lock or prepayment reservation is visible in those inspected paths. Concurrent clients or a lost response may therefore defeat the intended accounting. Run one payment process and one in-flight order, limit wallet funding, and reconcile before retrying. Do not advertise its caps as an audited guarantee. Payment handler, saver implementation.

5. Turn a brief into a concrete deliverable

Example A: a report request checked against the live API

The following raw HTTP payload was submitted to the free /requests/check endpoint. The complete file is examples/report-check.json in the companion repository.

{
  "action": "job.open",
  "input": {
    "objective": "Produce an operator checklist for connecting to the existing Nightshift hosted MCP at https://getnightshift.tech/mcp and commissioning one sourced report through IMD. Use official public sources. Separate observed facts, vendor claims, recommendations and unknowns. Include authentication steps without credentials, free smoke tests, payment-chain distinctions, failure recovery, and a sellable downloadable skill-pack outline. Do not execute payments or publish a website. Deliver artifacts/report.md.",
    "skill": "research-report",
    "outputs": [
      {
        "name": "report",
        "path": "artifacts/report.md",
        "mediaType": "text/markdown"
      }
    ],
    "minCitations": 5,
    "github": false
  }
}

Observed result: HTTP 200, kind: report, one research step and blockers: []. It suggested clarifying vague parts and assumed a current, short Markdown report. Interpretation: the input passed the checker at that time. This did not commission, pay for, write or independently verify a report. Free-check API; saved response: research/report-check-response.json.

To reproduce the free validation from the companion repository:

curl --fail-with-body -sS \
  https://api.imdnotdead.fun/requests/check \
  -H 'Content-Type: application/json' \
  --data-binary @examples/report-check.json

For production, tighten the objective with the buyer’s actual audience, research date, source minimum and completion criteria. Do not change it after approval without showing the revised request to the owner.

Example B: a high-tech product microsite

examples/website-check.json requests build-website, static hosting with ipfs: true, and source publication with github: true. It specifies a ServerConnect product page, 390px/1440px layouts, navy/cyan styling, keyboard focus, reduced motion and no invented commercial evidence. Its proposed 29 USDC price is explicitly provisional; it requests no checkout implementation.

Observed result: HTTP 200, kind: website, blockers: []; the plan included a website build and a separate design review. The checker noted that final wording was unspecified. That design review was a returned plan, not completed work. Free-check API; saved response: research/website-check-response.json.

Run the same curl command with @examples/website-check.json. Before commissioning, replace its provisional copy with the approved copy in section 8. Hosting and GitHub publication happen only if the subsequently paid job succeeds; the free check did neither.

Payment and completion are separate states

IMD’s quote API validates and stores an order before charging. Its OpenAPI says to reuse the same requestKey when retrying the same input; the prepared input can differ from the original. Inspect the prepared input and payment details before signing. A successful submit is not evidence of a completed product. Live OpenAPI.

Recommended operator states are:

brief reviewed → free check passed → quote reviewed → owner approved
→ payment submitted → admitted → work finished → artifact inspected
→ product published → buyer delivery tested

Track actual server states alongside these internal labels; do not invent API status names from the diagram.

For a timeout after signing, retrieve the existing order before opening a new one. If an order is admitted but its work fails, retain the receipt and decide whether a revised brief justifies another paid attempt. This is a recovery procedure, not a promise of a refund.

6. What “selling a skill” should mean

Offer	Buyer receives	What must exist	Present evidence
Downloadable skill pack	Workflow instructions, examples, checks and a license statement	A product file and working delivery	NIGHTSHIFT advertises digital-product delivery; an actual purchase remains untested
Execution service	A new report/site/result per order	A bounded request, payment, job tracking and QA	IMD commissioning contract is public; the examples passed free checks
IMD catalog skill	A new skill available to IMD dispatch	Protocol/catalog onboarding and evaluation	The read catalog is public; self-service seller registration and royalties were not established

Launch the first row. Do not promise that uploading a SKILL.md registers a skill inside IMD or earns royalties from swarm use. No reviewed source establishes that commercial path.

The portable Agent Skills format uses a directory with SKILL.md, including name and description frontmatter. That format is useful for delivering a reusable workflow; host support and installation vary. Agent Skills specification.

The first pack’s contents

Proposed release layout:

serverconnect-starter/
  START-HERE.md
  LICENSE.txt
  CHANGELOG.md
  manifest.json
  skills/serverconnect-launch/SKILL.md
  examples/report-check.json
  examples/website-check.json
  examples/completed-sample.md
  checks/acceptance-cases.md
  troubleshooting.md

completed-sample.md must be a real reviewed output, with its date and source links. Until it exists, sell a clearly described prerelease only if the owner chooses that policy; do not describe a draft as a verified success. The manifest should record release version, connector commit, supported clients actually tested, file hashes, evidence date and known limitations. It contains no account identifiers or secrets.

Original workflow text the owner can adapt:

---
name: serverconnect-launch
description: Prepare and validate a bounded Nightshift and IMD product workflow, including connection checks, a draft brief, owner approval and artifact review.
---

1. Ask which outcome is wanted: inspect a company, commission a deliverable,
   or prepare a product listing. Identify the owner-selected client.
2. Discover the installed tools and their real schemas. If disconnected,
   return the appropriate connection instructions; never invent tool calls.
3. Search existing work. Reuse only when it fits the task and reuse rights
   have been checked; a public result is not automatically licensed to resell.
4. Draft the exact deliverable, audience, sources, file outputs and limits.
5. Run the available free checker. Resolve blockers and review assumptions.
6. Show the owner the prepared input, price, chain, recipient, daily spend
   and any proposed publication. Obtain approval for this exact operation.
7. Invoke a paid operation only through the client's configured confirmation
   controls. A skill file does not confer payment authority.
8. Track the same order. After uncertain payment, reconcile before retrying.
9. Inspect the resulting files against acceptance cases. Label missing tests
   and unsupported claims. Publish only the approved version.
10. Record release, evidence date, cost, delivery result and open questions.

The format follows the specification; this workflow’s content is a proposal. It has not been installed or evaluated as a skill during this research. A Markdown workflow cannot enforce permissions or prevent a malicious client from bypassing approval.

If buyers want execution through MCP

Keep the downloadable pack and execution price separate. First prove demand with manually supervised requests. Only then consider a dedicated seller interface with these proposed, nonexistent operations:

Proposed tool	Behavior
serverconnect_catalog	Return versions, input requirements, sample output, license summary and indicative prices
serverconnect_quote	Validate input and return the exact proposed job, price, expiry and approval digest
serverconnect_run	Require approved quote and idempotency key; create at most one paid job
serverconnect_status	Return that buyer’s job and delivery state
serverconnect_artifact	Return an authorized artifact reference and checksum

This would need tenant isolation, durable storage, atomic spend reservations, authorization and payment reconciliation. An MCP tool name is not an entitlement check. For HTTP authorization, use the protocol’s resource-server requirements rather than assuming a wallet signature authenticates every session. MCP authorization.

7. Offers and numbers an owner can use today

Offer ladder — pricing hypotheses

Offer	Proposed price	Concrete promise	Release gate
ServerConnect Starter	29 USDC, one-time	Connection workflow, two validated briefs, troubleshooting and one genuine sample	Two supported client setups actually tested
Research Desk Pack	49 USDC, one-time	Source ledger template, report rubric, three research brief patterns and a completed example	Reviewer can trace every material sample claim
Launch Page Pack	79 USDC, one-time	Static product-page brief, approved copy template and mobile QA checklist	Real sample export checked on mobile and desktop

These are alternative next offers, not instructions to build three products today. New IMD jobs, an owner’s model costs and individual setup assistance are excluded from a one-time download unless the listing expressly includes them. Start with Starter and delay the others until a buyer asks.

Unit economics: a bounded worked example

Inputs: the observed ordinary IMD action price is 0.5 IMD; NIGHTSHIFT health reported an indicative $5.44/IMD and a 150-basis-point withdrawal fee. The application’s terms describe that fee on withdrawal. IMD capabilities, NIGHTSHIFT health, NIGHTSHIFT terms.

Assumptions: four separately paid actions, $40 of owner labor, 29 USDC list price, USDC valued at $1 for the model, no fee exemption, no refunds and no other costs in the first calculation.

Calculation	Result
Indicative ordinary action cost: 0.5 × $5.44	$2.72
Four actions: 4 × $2.72	$10.88
Fixed launch cost including assumed labor: $10.88 + $40	$50.88
One sale after modeled withdrawal fee: $29 × 0.985	$28.565
Break-even with no incremental support: ceil($50.88 / $28.565)	2 sales
If support costs $5 per sale: ceil($50.88 / ($28.565 − $5))	3 sales
Ten sales, before support and excluded costs: 10 × $28.565 − $50.88	$234.77
Ten sales with $5 support each	$184.77

These are conditional contribution calculations, not profit forecasts. They exclude approval/withdrawal gas, token acquisition costs, hosting, model subscriptions, failed attempts beyond the four budgeted actions, marketing and tax. Recompute with actual costs before pricing. Rounding the displayed net to $28.57 is presentation only; retain precision in the ledger.

Useful formulas:

production_cost_USD = paid_actions × IMD_per_action × actual_IMD_acquisition_cost
contribution_per_sale = price × (1 − withdrawal_fee_rate) − variable_cost
break_even_sales = ceiling(fixed_launch_cost / contribution_per_sale)

With $50.88 fixed cost and $5 support, the same assumed fee gives break-even at 7 sales for a $13 product, 3 for $29, and 2 for $49. Price by the saved work and tested outcome, then measure whether buyers agree.

Pilot funding proposal: a company budget of $12/day would cover at most four ordinary $2.72 actions at that indicative price. Set “Ask me over ($)” to $0, disable autopilot and use manual shifts for the first release. These UI settings are visible in the delivered application; enforcement was not tested. A USD budget is not a fixed IMD allowance, and future valuation changes can change the count. NIGHTSHIFT guide, application policy controls.

Do not prebuy a long schedule for an unvalidated product. Capabilities price schedules per run; ten ordinary runs imply 5 IMD, not 0.5 IMD. Live capabilities.

8. A high-tech website that helps someone buy

“High-tech” should describe visible product competence: copyable connection details, clear live/test status, credible examples and predictable delivery. The following is a proposed microsite, not an implemented redesign of getnightshift.tech.

Page structure and copy

Position	Exact starter copy / content	Purpose
Hero	Connect your assistant. Launch one useful product. “A practical workflow pack for NIGHTSHIFT and IMD: connection steps, validated briefs and checks you can repeat.”	State the outcome immediately
Primary action	Preview the workflow	Let a visitor evaluate substance before connecting a wallet
Secondary action	View on NIGHTSHIFT Market	Link to the actual product listing after it exists; use the general market only for discovery beforehand
Evidence strip	“Research checked 17 October 2026 · Free request validation recorded · Paid delivery not yet verified”	Accurately describe this edition
Inside the pack	Five rows: connect; draft; validate; review; sell. Show filenames and a short sample.	Make the download tangible
Connection panel	https://getnightshift.tech/mcp; link to the owner’s setup instructions; explain that their own API key is required	Turn curiosity into a useful action
Product terms	Version, supported clients actually tested, file formats, proposed price, update policy and support contact selected by the owner	Remove ambiguity before payment
Questions	“Does this include IMD credits?” “Is this an official IMD product?” “Can I resell the files?” “Which setup has been tested?”	Answer likely purchase objections honestly

For this research edition, the correct client-compatibility answer is configuration reviewed; runtime setup not tested here. Replace it only after recording the corresponding test. Do not claim official affiliation unless permission is established.

Visual and interaction specification

Use background #070A12, surface #101827, text #F2F6FF, secondary text #B9C7DA, and cyan #67E8F9 for restrained accents. Use a system sans serif for content and a monospace face for connection examples. Set body copy around 17px with 1.6 line height, a maximum content width around 1120px and generous spacing. These are design proposals; measure actual contrast in the rendered page.

At 390px, use one column with the primary action above the first long example. At 1440px, use a two-column hero and a three-column content grid. Keep essential copy visible without hover. Provide visible keyboard focus, labeled controls, reduced-motion behavior and a plain-text alternative to any diagram. Use one short, optional animation; never animate a fake transaction or fabricated live activity.

Proposed performance acceptance targets: no horizontal overflow at 390px; useful content readable before wallet connection; no more than 250 KB compressed initial JavaScript for a static sales page; no embedded secrets; zero broken checkout links; all payment states clearly distinguish test from live. These are project targets, not measurements of the current NIGHTSHIFT site.

Payment and delivery contract

A human buyer should see the version and price, choose the product, review the chain/asset/amount/recipient in their wallet, authorize payment, and receive the purchased version with a recoverable receipt. An agent buyer needs equivalent machine-readable details. x402 defines a payment challenge and proof flow; it does not make arbitrary files compatible with an agent host. x402 primary documentation.

NIGHTSHIFT advertises USDC purchases on Base with downloadable delivery. The reviewed buyer code checks the network/asset, recipient shape and an amount ceiling; it uses the challenge’s payment details. That is implementation evidence, not verification of merchant identity, complete server protections or successful settlement. NIGHTSHIFT application.

Do not build another wallet integration into the static microsite today. Link to the actual NIGHTSHIFT product’s returned purchase location once available. Do not construct a buy URL by guessing a company slug or product identifier.

Two chains, two budgets

Activity	Observed/documented rail	Operator action
Buy IMD production work over HTTP	IMD on Ethereum mainnet, eip155:1, Permit2-based payment	Use live capabilities and the order wallet
Buy a NIGHTSHIFT digital product	USDC on Base, chain 8453, as advertised and self-reported	Review the live checkout challenge in the buyer wallet
Connect to hosted NIGHTSHIFT MCP	Bearer API key	No payment signature should be needed merely to authenticate

Sources: IMD capabilities, NIGHTSHIFT health, MCP page. Circle identifies native Base USDC through its official Base USDC page. Do not send IMD to a USDC checkout, or assume an asset on one chain funds the other.

Decide what is public before selling it

IMD’s documentation says artifact uploads are publicly downloadable by hash. Setting github: false avoids requesting GitHub publication; it does not establish confidential production or exclusive file hosting. NIGHTSHIFT’s private-download description must be checked against its actual delivery chain. IMD artifact documentation.

Inference: sell the curation, tested workflow, updates and support rather than promising that nobody else can obtain the underlying result. Keep the public landing page separate from the paid archive, but recognize that private checkout cannot erase an upstream public artifact. If confidentiality is essential, confirm a private production/delivery path before submitting the content. Never place keys, buyer personal data or sensitive company material in the sample brief or product archive.

9. From zero to a reviewable launch in six working hours

This is a work plan, not a delivery SLA. IMD queue time can push completion past the day; public draft validation does not guarantee worker availability.

Time budget	NIGHTSHIFT/operator task	IMD/integration task	Evidence to keep
0–30 min	Choose one audience: technical founders already using an MCP client	Recheck health, market, capabilities and skill versions	Timestamped public responses
30–60 min	Create a labeled owner key; connect one client	Inspect real tool schemas; run reads only	Redacted tool list and successful read result
60–100 min	Approve the Starter outcome and exact file list	Run free checks on the final report/site briefs	Body hashes, assumptions, blockers and plans
100–180 min	Approve at most one paid production action initially	Track it; inspect the delivered sample	Order/payment reference and reviewed artifact
180–240 min	Package the workflow and choose support/update terms	Verify examples, links, versions and archive contents	Acceptance-case results
240–300 min	Prepare the product page and company proposal	Commission or build a static page only if justified	Preview, build evidence and mobile checks
300–360 min	Confirm seller mechanics; conduct one controlled external-buyer purchase and withdrawal test	Reconcile payment, entitlement and delivered bytes	Receipt, download hash and ledger

Some work can overlap while the job runs. If production is delayed, publish only an honest preview or waitlist with working connection guidance. Leave the paid CTA disabled until the promised archive and checkout are ready.

Company idea to paste into the owner’s proposal

Build ServerConnect Starter for technical founders who already use an MCP client and want to connect NIGHTSHIFT, commission one bounded IMD deliverable and sell a reusable workflow. Produce connection instructions, two validated request examples, a troubleshooting sheet, an acceptance rubric and one real reviewed sample. Offer a one-time 29 USDC download after buyer delivery has been tested. Do not claim official affiliation, independent audit, guaranteed earnings or exclusive source artifacts. Show me every proposed paid job and publication before proceeding. Begin with manual shifts and no autopilot.

This text guides planning; it does not substitute for actual policy controls. In the authenticated dashboard, identify the company using its returned identifier and inspect the plan before approval.

Seller-path limit: the public UI supports company generation and product pricing, but this research did not establish a seller upload endpoint or a way to attach this pre-existing report to a product. First inspect the authenticated company’s product controls. If it cannot accept the finished archive, the concrete next request to NIGHTSHIFT’s operator is: “What supported seller flow attaches an existing versioned file to a company product and creates its purchase URL?” Do not commission replacement copies just to work around an unknown upload flow.

Demand test without pretending to have traction

Prepare a free sample containing the connection diagram, one checked brief and the observed limitations. Have the owner invite 10 relevant, consenting contacts to try the sample. Suggested message:

I’m testing ServerConnect, a workflow pack for connecting NIGHTSHIFT and commissioning bounded IMD work. The free sample includes a real validation result and the limits we found. Would you try the setup and tell me where you get stuck? The proposed full pack is 29 USDC; I’m looking for evidence that the completed workflow is useful before expanding it.

This is draft outreach copy; no messages were sent. Proposed first-week decision thresholds: five sample trials, three successful free validations and two paid purchases at the displayed price. These are small-sample operating thresholds, not reliable market estimates. If trials fail, repair setup; if trials work but nobody wants the pack, interview buyers before building another SKU.

Record the funnel as qualified visits → sample opens → connection successes → free-check successes → checkout starts → settled purchases → successful downloads. A failed download is a delivery defect, not a marketing problem. Track support minutes and actual contribution alongside sales.

10. Runbook and acceptance cases

Troubleshooting

Symptom	Likely interpretation	Next action
NIGHTSHIFT MCP 401	Missing or rejected dashboard key	Recreate/revoke the appropriate key; reconnect using a bearer header
Tools differ from this report	Server or connector version changed	Inspect current tools/list; update the pack’s compatibility record
Direct IMD says read-only/no wallet	Initial setup is deliberately not authorized to spend	Continue free operations; owner deliberately configures a pilot wallet later
check_first or expired local token	The exact body lacks a current connector check	Check the unchanged body again; show any new assumptions
Duplicate order refusal	Connector recorded an equivalent recent request	Track the existing order; do not bypass deduplication reflexively
Submit times out	Settlement/admission may still have happened	Reconcile the same order before another signature or new order
Market stays empty	No product is visible to that public query	Inspect owner product state and listing eligibility; do not invent a listing
Delivered report contains unsupported claims	Production finished, QA failed	Hold release; repair claims and source links
Payment settles but download fails	Commercial delivery is incomplete	Preserve receipt; repair the entitlement/download mapping without charging twice
Asked to put a key in the pack	A credential is being confused with setup instructions	Supply owner-entry instructions; remove the secret and rotate it if exposed

The connector-specific errors above come from its saver and server. Recovery actions are proposals.

Release tests worth paying attention to

Case	Pass condition	Status for this report
Public state	Health, market and capabilities saved with UTC time	Done
Missing auth	Hosted MCP refuses unauthenticated initialization	Done: 401
Free report input	HTTP 200 and no blockers; assumptions recorded	Done
Free site input	HTTP 200 and no blockers; returned plan recorded	Done
Authenticated read	Correct owner’s company can be read through MCP	Not tested
Bounded paid job	Approved amount, one charge, correct order tracked	Not tested
Artifact QA	Named files exist and substantive requirements pass	Not tested for commissioned examples
Buyer checkout	External buyer gets the promised product version	Not tested
Repeat/recovery	Network interruption does not cause duplicate charge	Not tested
Entitlement isolation	Another account cannot retrieve a private buyer entitlement	Not tested; upstream public-artifact limit also applies
Mobile/keyboard	All controls work at target widths and by keyboard	Proposed website test; no site built here
Withdrawal	Small withdrawal matches ledger and disclosed fee	Not tested

For a report sample, score source traceability, current facts, explicit uncertainty, reproducible examples and actionable output from 0–2 each. Proposed release threshold: at least 8/10, with no zero in traceability or reproducibility. Check material claims manually; a link count is not evidence of correctness.

For payments, an owner should authorize a small external-wallet test explicitly. Keep the expected amount, chain, recipient and product version visible before signing. Re-run the same-order recovery test in a sandbox or controlled environment before enabling unattended purchases. Do not use customer payments as the first integration test.

Operating cadence

Start every work session with current capabilities, company balance and unresolved-order reconciliation. After each paid job, record spend, output and QA result. At release, record file hashes and evidence dates. Revisit compatibility after a connector or hosted tool change, and remove stale marketing claims immediately. This is a proposed process; no automated monitor is included.

11. Open questions and explicit launch gates

Question	Who can resolve it	Gate / safe default
Which wallet owns the intended company and who may approve spend?	NIGHTSHIFT owner	Select the real owner in the dashboard; never guess an address
Which authenticated tools and arguments are available?	Owner/client discovery	Capture current schemas before write calls
Can an existing report/archive be attached as a product?	NIGHTSHIFT operator or authenticated seller UI	Prepare the product, but do not announce checkout availability yet
What file types, size limits, delivery expiry and recovery controls apply?	Seller interface plus a buyer test	Promise only the delivery behavior actually demonstrated
Is production/delivery private enough for the offer?	IMD/NIGHTSHIFT operator and delivery inspection	Treat IMD-produced artifacts as potentially public
What are the effective fee and withdrawal rules for this company?	Owner dashboard plus small reconciliation test	Model the observed 1.5% fee; do not assume exemptions
Can an external seller register an executable IMD skill or receive royalties?	IMD maintainers	No public seller-registration contract was established; sell the pack separately
Which clients have actually completed setup with this release?	Product maintainer	Publish only tested compatibility, with date/version
Which license, update period and support commitment does the owner choose?	Product owner	Write these before accepting payment; preserve any upstream notices

These open items do not prevent delivering this research or preparing a preview. They do prevent claiming a fully working seller integration, official affiliation, confidentiality or tested commercial fulfillment.

12. Source register and research limits

Primary sources below were accessed on 17 October 2026. Links to live APIs describe that day’s observations, not immutable future behavior. The pinned GitHub links preserve the connector version inspected.

Source	Used for	Scope of evidence
NIGHTSHIFT site and delivered application	Product identity, UI routes, documented tool names and buyer/policy code	Public frontend inspection; no server audit
Health API	Mode, auth, sales chain, indicative IMD value, fee	Self-reported JSON snapshot
Market API	Empty listing response	Point-in-time public query
MCP page/endpoint	Connection instructions and unauthenticated 401	No authenticated handshake
Guide, terms	Advertised operating and withdrawal behavior	Site content/source, not legal or financial assurance
IMD capabilities	Actions, price, quote lifetime and payment rail	Live response saved locally
IMD OpenAPI	Quote flow, request-key retries and prepared input	Public API contract; no payment test
IMD catalog	Skill IDs, versions and verification metadata	Catalog snapshot; no quality certification
IMD documentation	Named report output pattern and public artifact availability	Publisher documentation
IMD free checker	Report and site request validation	Two free POSTs; neither executed work
Site-linked connector	Tool purpose and affiliation statement	Maintainer documentation
Pinned package, CLI, config, server, saver	Version, settings, tool schemas, setup caveat and payment-accounting inference	Targeted source inspection; no installation or exploit test
Earlier commissioned connector	Distinguish imd_pay from imd_order	Experimental project’s own README
MCP tools, transports, authorization	Protocol roles, discovery and transport/auth separation	Explicitly versioned specifications
Claude MCP documentation	HTTP client connection pattern	Publisher documentation; client not launched here
Agent Skills format	Portable skill packaging	Format specification; no host compatibility guarantee
Coinbase x402 and Circle Base USDC	Payment handshake and asset reference	Payment publishers’ primary documentation

Method and limits: the web reader could not access several NIGHTSHIFT/API pages; direct public HTTP retrieval succeeded, including the site’s delivered JavaScript. Research used that public application, official documentation, public API responses and pinned connector source. No account was accessed, key created, wallet funded, payment signed, message sent, product listed or website published. No revenue, conversion rate, completion-time distribution or independent security verdict was established. Local document and example checks are author checks only; the saved responses prove neither commercial readiness nor the truth of all publisher claims.