MCP Server

The Model Context Protocol (MCP) is an open standard created by Anthropic for connecting AI coding tools to external services. It lets your AI assistant call tools, read resources, and follow guided prompts from a locally running server — no copy-pasting commands or switching windows.

The Qwick Cert MCP server exposes 15 tools, 6 resources, and 5 guided prompts that let your AI assistant sign Windows executables, inspect PE files, manage billing and approvals, check signing policies, manage API keys and team members, troubleshoot configuration issues, and run security audits — all in natural language from your editor.

Any client that implements the MCP specification will work. The following have been tested:

Four steps to get code signing in your AI assistant:

1. Install

npm install -g @qwickcert/cli @qwickcert/mcp

2. Authenticate

qwick auth login

This opens a browser window for OAuth. The token is saved to ~/.qwick/config.json and shared between the CLI and MCP server automatically.

3. Configure your AI client

Add the MCP server to your client (see the Configuration section below for per-client instructions).

4. Use it

Open your AI assistant and ask it to sign a file. The MCP server handles the rest.

> Sign all the exe files in my dist/ folder

The assistant will call qwickcert_sign_files with the matched file paths,
compute digests locally, send them to the API, and embed the returned
signatures — all without you touching a terminal.

The JSON configuration format is the same across all clients. Only the config file location differs.

Claude Code (CLI)

No config file needed — run a single command:

claude mcp add qwickcert -- npx -y @qwickcert/mcp

Claude Desktop

Add to your config file:

{
  "mcpServers": {
    "qwickcert": {
      "command": "npx",
      "args": ["-y", "@qwickcert/mcp"]
    }
  }
}

Cursor

Add to one of these locations:

Windsurf

Add to .windsurf/mcp.json in your project root.

Cursor and Windsurf use the same JSON format as Claude Desktop shown above.

Environment variables

To pass environment variables to the MCP server, add an env block to your config:

{
  "mcpServers": {
    "qwickcert": {
      "command": "npx",
      "args": ["-y", "@qwickcert/mcp"],
      "env": {
        "QWICK_API_URL": "https://staging.qwickcert.com"
      }
    }
  }
}

The MCP server reads auth tokens stored by the Qwick Cert CLI at ~/.qwick/config.json. There is no separate authentication step — run qwick auth login once and both the CLI and MCP server share the same session.

JWT tokens are automatically refreshed when they near expiry. API keys (qwick_ak_*) are also supported and never expire unless a TTL is configured at creation time.

The server exposes 15 tools that your AI assistant can call. Tools marked read are safe and idempotent. write tools modify files or create resources.

Calls qwickcert_sign_files with files matching C:/build/dist/*.exe.
Returns per-file status, operation IDs, and timing.

Calls qwickcert_verify_signature. Returns:
- Signature status: Valid
- Signer: Acme Corp (issued by Microsoft ID Verified CS EOC CA 01)
- Timestamp: 2026-03-04T10:32:00Z (valid)

Calls qwickcert_check_status. Returns:
- Auth: Authenticated as dev@acme.com
- Org: acme-corp (Pro plan, 3/5 seats used)
- Azure: Provisioned, certificate profile "desktop-app" active
- Project: .qwickrc.json found, project slug "my-app"

Calls qwickcert_signing_history with since set to the start of the current week.
Returns a table of operations with file names, statuses, signers, and timestamps.

Calls qwickcert_session_status. Returns:
- Active sessions: 2/2 (at capacity)
- Queue depth: 1
- Oldest session started 45s ago by ci-bot@acme.com

Calls qwickcert_setup_project with project "desktop-app".
Creates .qwickrc.json with the profile, detected file patterns, and verify enabled.

Calls qwickcert_manage_apikey with action "create", name "github-actions-release",
and permissions ["sign"]. Returns the key (qwick_ak_...) — shown once, never retrievable again.

Calls qwickcert_troubleshoot. Returns a categorized diagnostic report:
- Auth: OK (token valid, expires in 47 min)
- signtool: WARN (not found — needed for verify only, not signing)
- API: OK (api.qwickcert.com reachable, 120ms latency)
- Azure: OK (certificate profile active)
- Project: ERROR (no .qwickrc.json found in current directory)

Calls qwickcert_team_overview. Returns:
- 3/5 seats used (Pro plan)
- alice@acme.com — Admin (active)
- bob@acme.com — Member (active)
- carol@acme.com — Member (pending invite)

Calls qwickcert_policy_check with ip_address "203.0.113.42". Returns:
- IP allowlist: PASS (203.0.113.42 matches CIDR 203.0.113.0/24)
- Time window: PASS (current time within Mon-Fri 06:00-22:00 UTC)
- File restrictions: 2 rules active (.exe and .dll only)

Calls qwickcert_inspect_file. Returns:
- MyApp.exe: x64, PE32+, Windows GUI, NOT signed, ready to sign
- Helper.dll: x64, PE32+, DLL, already signed (cert size: 4096 bytes)

Calls qwickcert_billing_usage. Returns:
- Plan: Pro ($99/yr)
- Members: 1/1 used
- Signings (30 days): 142 / No platform cap
- Avg duration: 2.3s
- All-time total: 1,847 operations

Calls qwickcert_approval_requests with action "list". Returns:
- 2 pending requests
- build/MyApp.exe — requested by dev@acme.com at 10:32 AM
- build/Updater.exe — requested by dev@acme.com at 10:33 AM

Calls qwickcert_setup_status. Returns:
- ✓ Organization Created
- ✓ Billing Subscription (Plan: pro)
- ✓ Azure Signing Account Imported
- ⟳ Identity Validation — In Progress
- ○ Certificate Profile Ready — Pending

Calls qwickcert_org_manage with action "invite", email "alice@acme.com", role "signer".
An invitation email has been sent. Alice can accept it to join your organization.

MCP resources provide read-only context that your AI assistant can reference at any time without an explicit tool call. Resources are loaded automatically when the assistant needs background context.

Guided multi-step workflows that your AI assistant can invoke. These act like slash commands — they inject a structured plan into the conversation so the assistant follows a proven sequence of tool calls.

These examples show what happens behind the scenes when you ask your AI assistant to perform common tasks.

Signing workflow

Sign all the executables in my dist folder and verify them

I'll sign those files for you. Let me check your setup first.

> Called qwickcert_check_status
> Auth OK, org "acme-corp", project "desktop-app"

> Called qwickcert_sign_files
> files: ["C:/project/dist/MyApp.exe", "C:/project/dist/Updater.exe"]
> verify: true

Signed 2 files in 4.2s — both signatures verified.
- MyApp.exe — operation op_a1b2c3 (completed)
- Updater.exe — operation op_d4e5f6 (completed)

Troubleshooting workflow

My signing keeps failing. Can you figure out what's wrong?

Let me run a full diagnostic.

> Called qwickcert_troubleshoot
> Auth: OK — token valid, 47 min remaining
> signtool: WARN — not found (verify only, not needed for signing)
> API: OK — 120ms latency
> Azure: OK — certificate profile active
> Project: ERROR — no .qwickrc.json found

> Called qwickcert_signing_history
> Last 5 operations: all failed with QWICK_POLICY_801

> Called qwickcert_policy_check
> IP allowlist: FAIL — your IP 98.51.100.12 is not in the allowlist

The issue is a policy violation. Your IP address is not in your
organization's signing allowlist. Ask your admin to add 98.51.100.12,
or use qwickcert_policy_check to verify after they update it.

CI setup workflow

Set up code signing for my GitHub Actions release pipeline

I'll configure the project and create a CI key.

> Called qwickcert_setup_project
> project: "desktop-app", files: ["dist/**/*.exe"], verify: true
> Created .qwickrc.json

> Called qwickcert_manage_apikey
> action: "create", name: "github-actions-release"
> permissions: ["sign"]

Done. Here's your setup:

1. .qwickrc.json created with the "desktop-app" profile
2. API key created: qwick_ak_live_abc123... (copy it now — shown once)
3. Add it as QWICK_API_KEY in your repo's GitHub Secrets
4. Use qwickcert/sign-action@v1 in your workflow

The MCP server signs files without exposing your binaries or credentials. Here is what that means for your security posture:

The MCP server runs as a local STDIO process alongside your AI client. It reads the same auth tokens stored by the Qwick Cert CLI, so there is no separate authentication flow.

┌──────────────────────────┐
│  AI Client               │  Claude Code, Cursor, Windsurf, etc.
│  (your editor)           │
└────────┬─────────────────┘
         │ MCP Protocol (STDIO — local process, no network)
         │
┌────────▼─────────────────┐
│  @qwickcert/mcp          │  Reads ~/.qwick/config.json for auth
│  (local MCP server)      │  Computes PE digests (SHA-256) locally
└────────┬─────────────────┘
         │ HTTPS (Bearer token, 32-byte digest payload)
         │
┌────────▼─────────────────┐
│  Qwick Cert API          │  api.qwickcert.com
│  (Vercel)                │  Validates auth, enforces policies
└────────┬─────────────────┘
         │ Azure REST API (service principal, server-side only)
         │
┌────────▼─────────────────┐
│  Azure Trusted Signing   │  Signs digest, returns PKCS#7 blob
│  (Microsoft)             │  + RFC 3161 timestamp
└──────────────────────────┘

The PKCS#7 signature blob travels back up the chain and is embedded into the PE file by the local MCP server. At no point do file contents or Azure credentials leave your machine.