DEV Community

Cover image for We built an MCP server for employment contracts — remote HTTP, QES/eIDAS, 12 tools
Timo Hähne
Timo Hähne

Posted on • Originally published at staffsign.de

We built an MCP server for employment contracts — remote HTTP, QES/eIDAS, 12 tools

#mcp #api #ai #productivity

If you've been building AI agent workflows, you've probably hit this wall: your agent can reason, plan, and execute — but connecting it to external systems still means writing custom API wrappers, auth logic, and error handling for every service.

MCP (Model Context Protocol) solves this through standardization. A service that exposes an MCP server gives any MCP-compatible agent direct tool access — no custom integration needed.

We built staffSign — a digital employment contract API for HR and staffing agencies in the DACH region — with this in mind. The primary interface isn't a UI. It's the MCP server.

The setup (Claude Desktop / Cursor / Claude.ai) 

{
  "mcpServers": {
    "staffsign": {
      "url": "https://www.promotionbasis.de/api/mcp",
      "headers": { "X-Api-Key": "<your-api-key>" }
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

Remote HTTP server — nothing to install, no mcp-remote needed.

12 tools across two areas

Contract lifecycle: create_contract, send_contract, get_contract, search_contracts, cancel_contract, delete_contract

Template management: create_contract_template, update_contract_template, get_contract_template, search_contract_templates, activate_contract_template, archive_contract_template

A typical agent workflow 

candidate accepts offer in ATS
→ agent: create_contract(templateId, participants, signatureLevel="QES")
→ agent: send_contract(contractId)
→ candidate signs on phone (QES — eIDAS qualified, legally binding in all EU countries)
→ webhook: contract.signed → agent triggers onboarding
Enter fullscreen mode Exit fullscreen mode

Full workflow in under 2 minutes, no human in the loop.

What's notable from an MCP perspective

  • Remote HTTP — direct url + headers config, no stdio wrapper needed
  • QES (eIDAS) — qualified electronic signature, legally binding across all EU countries, included by default
  • Idempotency keys on all POST endpoints — safe for agent retry logic
  • Structured error responses with recovery hints
  • Webhook events for event-driven pipelines

Why we built the MCP server as the primary interface

Most employment contract tools are built around a UI. We made a different bet: within 2-3 years, most integrations will be done by AI agents, not humans writing custom code. So we built the MCP server first, not as an afterthought.

Pay-per-use from €3/contract, no subscription. Docs: staffsign.de/docs

Happy to answer questions about the remote HTTP setup, the QES/eIDAS angle, or the MCP design decisions.

Top comments (0)