MCP Server | 1099Policy

The 1099Policy MCP server lets an AI assistant work with your 1099Policy account in plain language: the same contractors, jobs, quotes, assignments, policies, certificates, invoices, and team members your developers reach through the REST API. Ask it who has active coverage and who does not, whether a contractor meets a client's insurance requirements, why an uploaded certificate was flagged, who was sent an application and never finished it, or what it would cost to cover someone on a job. If you allow it, it can also create jobs, send application links, bind and cancel coverage, and manage who is on your team.

It works with any MCP client — Claude (claude.ai, Desktop, and Claude Code), ChatGPT, Cursor, VS Code, Windsurf, JetBrains IDEs, Zed, Continue, Cline — and with server-side agents that hold an API key.

The server is hosted by 1099Policy. There is nothing to install, no package to download, and no key to paste. You point your client at one URL:


https://mcp.1099policy.com/mcp

and approve the connection in your 1099Policy dashboard, where you are already signed in.

This page covers connecting and securing the assistant. The tool reference lists every tool with its inputs and returns, and troubleshooting covers what to do when something does not work.

Quick start

Add https://mcp.1099policy.com/mcp to your client (steps per client below).
Ask it anything — the first request opens your browser on the 1099Policy dashboard's approval screen.
Choose the organizations it may reach, live data or sandbox, and read-only or make changes. Click Allow access.

That is the whole setup. The connection persists; the client renews its own access from then on.

Connecting

Claude (claude.ai and Claude Desktop)

Settings → Connectors → Add custom connector. Give it a name (1099Policy) and paste the URL. Claude Desktop and claude.ai share the connection.

Claude Code

bash

claude mcp add --transport http 1099policy https://mcp.1099policy.com/mcp

The first tool call opens your browser to approve the connection.

ChatGPT

Settings → Connectors → Create. Turn on developer mode if the option is not shown. Name it, paste the URL as the MCP server URL, and choose OAuth as the authentication method. Custom connectors are available on the ChatGPT plans that include them.

Cursor

Settings → Tools & MCP → Add custom MCP, or add the server to ~/.cursor/mcp.json:

json

{
  "mcpServers": {
    "1099policy": { "url": "https://mcp.1099policy.com/mcp" }
  }
}

VS Code

bash

code --add-mcp '{"name":"1099policy","type":"http","url":"https://mcp.1099policy.com/mcp"}'

or in .vscode/mcp.json (workspace) or your user mcp.json:

json

{
  "servers": {
    "1099policy": { "type": "http", "url": "https://mcp.1099policy.com/mcp" }
  }
}

Windsurf

In ~/.codeium/windsurf/mcp_config.json:

json

{
  "mcpServers": {
    "1099policy": { "serverUrl": "https://mcp.1099policy.com/mcp" }
  }
}

JetBrains IDEs, Zed, Continue, Cline, and other clients

Add a remote (streamable HTTP) MCP server with the URL above, in the shape your client's documentation gives. Most clients accept the standard form:

json

{
  "mcpServers": {
    "1099policy": { "url": "https://mcp.1099policy.com/mcp" }
  }
}

Sign-in opens the browser the same way for every client. Clients that receive the sign-in on your own machine (a local port, or a cursor://, vscode://, windsurf://, jetbrains://, zed:// link) and the hosted clients listed above are recognised by name on the approval screen; any other client still connects, and is labelled as unverified there.

Approving a connection

The first time your assistant reaches the server, your browser opens Connect an assistant in the 1099Policy dashboard. If you are not signed in, sign in first; the page then shows:

Who is asking. The client's name and where the access will be sent — for example Claude is requesting access to your 1099Policy account. Access will be granted to https://claude.ai. Anyone can build an MCP client, so a client 1099Policy does not recognise is shown with a warning — is not a verified 1099Policy integration, and chose that name itself — and the button reads Allow anyway. Only continue if you started the connection from that application yourself.

Which organizations? If you belong to more than one, tick any number. A separate key is created for each, and each can be revoked on its own. The assistant can switch between them in conversation. With a single organization this step is skipped.

Which data should it see? Live data — your real contractors and policies — or Test data, the sandbox, where nothing is real. Choose the sandbox to try things out or to let someone evaluate the connector without touching production.

What should it be allowed to do? Read only — look at data, nothing else — or Make changes — add and remove people, create records, bind and cancel coverage. Clients only ever ask for read access. Write access exists only because you chose it here; a client cannot obtain it by asking. A read-only connection is served the read tools only; the write tools are not even visible to it.

Click Allow access. The page shows Account connected and you can close it. Approving creates an API key that exists for this connection alone. It carries the same access as your other API keys, so only approve an assistant you trust with your account — but it is separate from them, and revoking it touches nothing else.

Managing connections

Developers → Connected assistants in the dashboard lists every assistant connected to the current organization: which client, when it connected, and a Disconnect button. Disconnecting revokes that connection's key immediately; the assistant's next request fails with an authorization error, and anyone using it has to connect again. Your other keys and connections are unaffected.

To change what a connection may do — read-only to make changes, or the other way — disconnect it and connect again, choosing differently on the approval screen.

Working with several organizations

If you approved more than one organization, the connection holds a key for each. Ask which organizations am I connected to? to see them and which is active; switch to Northwind changes the active one, and every other tool then acts on it. Data never crosses organizations: each request reads or writes the active organization only.

The switch persists for the connection, including when your client silently renews its access token.

A connection made with an API key (see Headless use) is bound to the one organization that key belongs to and has no switcher.

Authentication

OAuth (the browser flow)

The server is an OAuth 2.1 authorization server as well as an MCP server. Discovery documents live at:

https://mcp.1099policy.com/.well-known/oauth-protected-resource
https://mcp.1099policy.com/.well-known/oauth-authorization-server

A compliant client configures itself from the URL alone: an unauthenticated request to /mcp returns 401 with a WWW-Authenticate header that points at the metadata and names the scope to request. The server supports:

PKCE with S256 — required on every authorization.
Dynamic Client Registration (/register) — your client registers itself; there is no client ID to create. Redirect targets may be https://, a loopback address (http://localhost, http://127.0.0.1, any port), or a native app's own scheme such as cursor:// or vscode://.
Client ID Metadata Documents — a client that identifies itself with a hosted metadata document (as Claude Code does) is accepted without registering.
Scopes t99:read and t99:write. Clients request t99:read; whether t99:write is granted is decided by your choice on the approval screen, regardless of what was requested. The token response states the scope that was actually granted.
Tokens. An access token lasts one hour; a refresh token lasts thirty days and is single-use — each refresh returns a new one. Your client does this on its own.

Headless use: API key as bearer token

A server-side agent, a scheduled job, or CI has no browser. Present a 1099Policy secret key as a bearer token instead. Create one in the dashboard under Developers → API keys. The key's prefix selects the environment — t9sk_live_… for live data, t9sk_test_… for the sandbox — and the key's own permissions apply to every tool.

json

{
  "mcpServers": {
    "1099policy": {
      "url": "https://mcp.1099policy.com/mcp",
      "headers": { "Authorization": "Bearer t9sk_your_key" }
    }
  }
}

Treat the key like any other secret: an environment variable or secret store, never client-side code, an agent prompt, or a public repository.

Direct HTTP calls

The endpoint speaks standard MCP JSON-RPC over streamable HTTP. Each request stands alone — no session or initialize handshake is required — so a single curl works:

bash

curl https://mcp.1099policy.com/mcp \
  -H "Authorization: Bearer t9sk_your_key" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "tools/call",
    "params": {
      "name": "checkCoverage",
      "arguments": { "contractor": "cn_Fm2eLzDnK5" }
    }
  }'

The Accept header must list both types. Tool results come back as JSON text in result.content[0].text. A failed call returns isError: true with a structured body — {"error": "not_found", "status": 404, "message": "…"} — rather than a bare HTTP error, so an agent can reason about what went wrong. Requests to the 1099Policy API time out after 30 seconds. At the transport level, a missing or invalid token is 401, a body that is not valid JSON is 400, and a body over 1 MB is 413.

To see every tool with its description and input schema exactly as the assistant sees them, call tools/list the same way. A read-only connection sees only the read tools.

Environments

1099Policy has a live environment and a sandbox. On the approval screen you choose one per connection; with an API key the prefix decides. Sandbox data is entirely separate: contractors, jobs, quotes, and policies created there are test records, application links open the sandbox application flow, and nothing is billed. Use it to evaluate the connector, to rehearse a workflow, or to give a reviewer a fully populated account without exposing real data.

Security

What the server holds. The server stores no account data. It keeps the connection itself — which client, which organizations, which environment, the granted scope — and the key minted for it. Requests are logged for security review. Your conversation with the assistant never reaches 1099Policy; only the tool calls the assistant makes do.

Least access by default. Approve read-only unless the assistant has a job that needs to change something. A read-only connection cannot bind or cancel coverage, send links, or touch your team, whatever it is told to do.

Confirmation on writes. Every write tool is annotated so that clients which honour MCP annotations — Claude does — ask you before running one. Keep that on. A write is reported as done only when the API says it is.

Check who is asking. The approval screen names the client and its redirect. If you did not start the connection from that application, or the name does not match where the access is going, do not approve it.

Revoke, do not rotate. Each connection has its own key; ending it is one click in Developers → Connected assistants and affects nothing else.

Other MCP servers. Be deliberate about which servers you run alongside this one. Anything that can read the conversation can read what this connector returns. Tool names here are not prefixed, so if an HR, payroll, or CRM server is also attached, listContractors and listInvoices mean 1099Policy contractors and premium invoices; if the assistant picks the wrong server, say which one you mean.

Questions

Email integration@1099policy.com. Privacy policy: 1099policy.com/legal/privacy.