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

https://api.verifycate.com/mcp

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

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:

{
  "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.