---
title: MCP Server
description: Use Verifycate from ChatGPT, Claude, Codex, and other MCP clients
group: Guides
---

# MCP Server

# MCP Server

Verifycate exposes its developer interface as a remote Model Context Protocol
(MCP) server. Agents can create certificates, design and publish templates,
import recipients, issue and send certificates, process requests and
corrections, inspect analytics, and manage supporting resources.

## Endpoint

```text
https://api.verifycate.com/mcp
```

The server uses stateless Streamable HTTP. Authenticate with the same workspace
API key used by the REST interface:

```http
Authorization: Bearer vc_...
```

Create a key in the Verifycate dashboard under **Workspace → API Keys**. The
key is bound to one workspace. Tool calls cannot switch to a different
workspace, even if an agent supplies another workspace slug.

## Permissions

- `certificates:read` enables certificate, recipient, request, and correction
  read tools.
- `certificates:write` enables creating certificates, importing recipients,
  issuing, sending, and workflow decisions.
- `templates:read` enables reading certificate and email templates.
- `templates:write` enables updating, forking, and publishing templates.
- A key with an empty permission list has full access and is required for
  operations outside those groups, such as media, analytics, skills, and
  webhooks.

Use a narrowly scoped key whenever the agent does not need the complete tool
catalog. Verifycate checks permissions again for every tool invocation.

## Example client configuration

Clients that accept a remote MCP URL and bearer token should be configured with
the endpoint above and an `Authorization` header. For example, an MCP client
configuration commonly looks like:

```json
{
  "mcpServers": {
    "verifycate": {
      "url": "https://api.verifycate.com/mcp",
      "headers": {
        "Authorization": "Bearer vc_your_key"
      }
    }
  }
}
```

Do not commit this configuration with a real API key. Prefer the client's
secret or environment-variable support when available.

## End-to-end agent workflow

An agent can complete a certificate campaign in this order:

1. Call `create_certificate` with the certificate details and attribute
   definitions.
2. Call `update_certificate_template` with a canvas JSON document, then
   `publish_certificate_template`.
3. Call `import_recipients` with names, email addresses, and attribute values.
4. Inspect the returned pending issues and call `issue_certificate` for one
   recipient, or `send_pending_certificates` for the whole pending batch.
5. Use `list_issues`, `get_recipient`, and the analytics tools to inspect the
   result.

Sending, issuing, rejecting, deleting, and webhook calls are marked as
consequential operations. Review the agent's arguments before approving them.

## Template design

The template tools use the same JSON canvas accepted by the dashboard. An agent
should first call `get_certificate_template`, preserve fields it does not need
to change, and then submit the complete updated `template` object to
`update_certificate_template`. Images must use uploaded storage paths or HTTPS
URLs; base64 image data is rejected.

Use `get_upload_url`, upload the file with HTTP `PUT`, call `confirm_upload`,
and then reference the returned path in the template. Not every chat client can
perform the direct binary upload step, so an existing HTTPS asset URL may be
more convenient.

## Safety notes

- The server never returns or accepts an API key as a tool argument.
- Certificate and recipient data returned to the agent may contain personal
  information. Use only clients approved to process that information.
- Read the current certificate and template before asking an agent to update
  them.
- Prefer single-recipient issuance while testing. Bulk send can send every
  pending certificate in the selected certificate.