BeYourCover MCP Server

Connect

claude.ai and Claude Desktop — sign in, no key

Add the URL as a custom connector. The client discovers our authorization server, registers itself, and sends you to a BeYourCover sign-in and approval screen. No API key to copy. To disconnect a client, remove the connector in that client.

Connector URL:  https://beyourcover.com/api/mcp

Claude Code — API key

Fastest for developers. Uses the same byc_sk_ key as the REST API, created in your dashboard.

claude mcp add --transport http beyourcover \
  https://beyourcover.com/api/mcp \
  --header "Authorization: Bearer byc_sk_your_api_key_here"

Any client that only accepts a URL

Bridge to it with mcp-remote, passing the key as a header:

{
  "mcpServers": {
    "beyourcover": {
      "command": "npx",
      "args": [
        "-y", "mcp-remote",
        "https://beyourcover.com/api/mcp",
        "--header", "Authorization:${BYC_AUTH}"
      ],
      "env": { "BYC_AUTH": "Bearer byc_sk_your_api_key_here" }
    }
  }
}

What you need

Connecting works with any BeYourCover account, so you can add the server and read what it offers before committing to anything. The tools themselves need an active plan. An API plan gives credits for the MCP server and the REST API only — API 150 from $49 a month, with 150 monthly credits. A workspace plan — Starter from $79 a month, with 150 monthly credits — adds the team workspace for agencies and publishers: the web app, marketing kits, brand kits, client review links and seats.

The MCP server and the REST API handle the cover work: books, covers, edits, print wraps and audiobook covers. The marketing kit — the launch campaign built from a book's approved cover — runs in the browser only, so an agent cannot generate it. An agent can make the cover; you build the kit from it on the book's kit page. A book opened in the kit includes one print wrap, one audiobook cover and one text-free cover a month, and the tools honour them: the book's first of each costs no credits, and the agent's reply says it was included.

Without a plan the agent still lists every tool and its schema, then reports that the account has no active plan when you ask it to do the work. If you do have a plan and still see that, check that you signed in with the account holding it — and, on a team, that your seat is active.

On a team, a reviewer seat gets the read tools only: listing, job status, credits, templates, reading a wrap, downloads and the wrap calculator. The tools that spend credits or change a cover tell the agent that reviewers cannot use them.

Tools (22)

Task-shaped, not a one-to-one mirror of the REST endpoints. Costs are in generation credits; reading, listing and calculating are free.

How generation works

Generation is asynchronous. A create tool returns a jobId, and the agent calls get_generation_status, which waits up to 25 seconds for the job before it answers. Most covers are ready after one or two calls, so the agent can show them without handing back to you mid-job. A script that polls on its own timer passes wait_seconds: 0.

To use an image from the conversation — a cover you like, a photo, or a finished cover to import — the agent gives you an upload link. Open it, drop the file, and tell the agent it is uploaded. The link works for 15 minutes and costs nothing. An agent with a shell and open network access can send a local file itself instead.

Finished covers come back as inline image content — a downscaled JPEG preview — alongside a one-hour signed URL serving the full-resolution original. Whether the preview is displayed is up to the client: Claude Code renders it, while Claude Desktop and claude.ai do not currently surface tool-result images, so there you get the link. The link is always present, so nothing depends on the image being rendered.

Pass include_images: false (or include_image: false on download_cover) to skip the images on programmatic runs. Print-resolution assets are always URL-only — far too large to inline.

Print wraps

Hand an agent a finished cover, your trim size and page count, and your back-cover copy. create_full_wrap generates the back artwork, lays out the text, extends the front to the full print panel, and returns the wrapId with its preview, full-resolution flat and print-ready PDF, plus any layout warnings. Unless you ask for other spine text, the spine shows the book's title and author in capitals, as in the editor.

Changing your mind afterwards is free. Ask the agent to update the wrap rather than make a second one: update_wrap_text reworks the text, the spine colour and — on a solid-back wrap — the back-cover colour, at no charge. Only the fields you name change. extend_wrap_front re-runs the front extension free if the artwork came back with a visible seam.

Wraps an agent creates are real designs: they appear in the wrap editor named API, so you can open one and adjust it by hand. It works the other way too — a wrap you laid out yourself keeps your own text blocks, images and arrangement when an agent changes its copy. Full detail in the full wrap guide.

Authentication

Two credentials are accepted. An API key (byc_sk_, the same one the REST API takes) in an Authorization: Bearer header, or an OAuth 2.1 access token for native connectors.

OAuth uses the authorization-code flow with PKCE and supports dynamic client registration, so a connector configures itself from /.well-known/oauth-protected-resource with nothing pre-shared. The full walkthrough for an agent lives at /auth.md.

A missing or invalid credential returns 401 with a WWW-Authenticate header that restarts discovery. A valid credential on an account without a plan does not — it lists tools normally and refuses the work with a readable reason, so a client never loops on a token that was never the problem.

Machine-readable resources

• /server.json — the MCP registry manifest
• /auth.md — how an agent obtains and uses a credential
• /.well-known/oauth-protected-resource — RFC 9728 protected-resource metadata
• /.well-known/api-catalog — RFC 9727 linkset indexing every API here
• /llms.txt — site map for LLMs
• /openapi.json — OpenAPI 3.1 spec of the REST API
• /api-docs.md — the REST reference as Markdown

The API catalog is an RFC 9727 linkset. Its entries point at each API's spec (service-desc), docs (service-doc), health check (status) and auth guide (service-meta). Every page also sends Link: </.well-known/api-catalog>; rel="api-catalog".

Markdown for agents

Every public page answers Accept: text/markdown with the page as Markdown, with YAML frontmatter (title, description, canonical URL). The response carries Vary: Accept and x-markdown-tokens, an estimate of its size. A wildcard Accept never returns Markdown, so browsers get HTML. Signed-in app pages and legal pages stay HTML only. The user guides also keep permanent .md URLs.

curl -H "Accept: text/markdown" https://beyourcover.com/
curl https://beyourcover.com/docs/full-wrap-covers.md

GET /api/v1/health

The one REST endpoint that needs no key. It reports that the API serves requests. It does not check the database or the image providers, so a 200 does not promise that a generation will succeed. Responses are never cached.

curl https://beyourcover.com/api/v1/health
{
  "status": "ok",
  "service": "BeYourCover Partner API",
  "version": "1.1.0"
}

For the REST API — endpoints, webhooks, error codes and the OpenAPI spec — see the API documentation. For the account-holder's view of connecting an agent, see the plans and teams guide.