Introducing sevk MCP

Software has always been able to call sevk through the API, SDKs, and CLI. AI agents can do the same, but making them assemble URLs, remember request shapes, and interpret every response adds glue code around work the platform already understands. sevk MCP gives agents a direct, structured way in.

Point an MCP client at one URL and give it an existing project API key. It can discover the tools that key is allowed to use, read their schemas, and call the same backend that powers the rest of sevk. There is no separate MCP account, package, or service to maintain.

Why MCP?

An agent needs more than a list of endpoints. It needs a contract it can inspect before it acts: which tools exist, what each argument means, which fields are required, and whether an operation reads data or changes it. MCP provides that contract without forcing every client to learn a sevk-specific integration.

That makes ordinary requests useful immediately. Ask an agent to find a template, inspect a campaign, estimate its audience, check quota, or review contact activity. The agent chooses from typed sevk tools instead of guessing at HTTP calls or scraping the dashboard.

Connect once

The managed MCP endpoint is https://mcp.sevk.io. Add it as a remote HTTP server in any MCP client that supports custom headers, then pass your project API key as a Bearer token. The exact configuration file varies by client, but the connection has this shape:

{
  "mcpServers": {
    "sevk": {
      "type": "http",
      "url": "https://mcp.sevk.io",
      "headers": {
        "Authorization": "Bearer <YOUR_SEVK_API_KEY>"
      }
    }
  }
}

Seventy-four focused tools

The first catalog covers the workflows an agent can use productively. It is organized around sevk, rather than copied from another email API:

• Templates, transactional emails, and broadcast campaigns
• Contacts, audiences, topics, and dynamic segments
• Inbound messages, attachments, and forwarding routes
• Activity, usage, outbound quota, and campaign analytics
• Webhook configuration and delivery checks

Tool inputs come from the same OpenAPI contract as the REST API. Cursor pagination, validation rules, response fields, and resource identifiers stay consistent across every surface.

Your API key decides what the agent sees

MCP uses the project API keys you already have. Tool discovery filters the catalog against the key's capabilities, so a read-only key never sees create, update, or send tools. A domain-scoped key stays inside its domain. Revoke or suspend a key and its next MCP request fails just like its next REST request.

This lets you choose a narrow key for an assistant that only reviews campaign performance, or a broader key for an agent that prepares templates and manages contacts. Access follows the key, not the model or the client running it.

One backend, one set of rules

MCP does not contain a second copy of sevk's business logic. Each tool calls the corresponding API route inside the same process. Authentication, project isolation, rate limits, validation, idempotency, billing, and side effects all pass through the existing route.

Results keep the HTTP status next to the data, so the agent can distinguish a successful read from a validation error, a missing record, or a rate limit. A recipient estimate, for example, comes back as a small structured result:

{
  "statusCode": 200,
  "data": {
    "count": 1284
  }
}

Real actions stay real

A tool named send_email sends an email. A webhook test makes a real signed request. Sending a broadcast starts or schedules the campaign. Descriptions and MCP annotations state those effects so clients can present the right confirmation before they call a tool.

Transactional and bulk sends require an idempotency key. If a connection drops after submission, the agent can reuse that key with the same payload and get the original result instead of creating duplicate mail. An accepted email ID still means accepted, not delivered. Delivery remains an event the agent can inspect afterward.

Built on the current MCP protocol

sevk MCP uses the 2026-07-28 protocol over stateless Streamable HTTP. Modern MCP clients can connect directly without a local package or stdio bridge. The server keeps no client session between requests, which makes it fit the same deployment and scaling model as the API.

kubilay

just a tech