What is an MCP server for awork?
An MCP server for awork connects AI agents to your awork workspace via the open Model Context Protocol. The AI model can then access the awork Public API in a standardised way, query projects, create or move tasks, analyse time entries and check utilisation per team — all within clearly defined tools and permissions.
awork is a Hamburg-based project management tool — a good fit for Workflow Agentur (based in Hamburg) and especially popular with agencies, consultancies and project-driven mid-sized companies that want a modern, German tool as an alternative to Asana, ClickUp or Monday. According to its DPA, awork runs in Azure data centres in Frankfurt am Main and Berlin, with the DPA as standard — a good basis for a privacy-compliant setup.
awork offers its own MCP server: endpoint https://api.awork.com/api/v1/mcp, sign-in via OAuth 2.1 (including Dynamic Client Registration) or via API key as a bearer token. According to the awork docs, the server works with the same resources, permissions and rate limits as the Public API. For a quick start with Claude or ChatGPT, this is the direct route.
We use our own MCP server when you need more control: fixed, defined tools instead of free API access, approval steps before writing, a separate log of every access, or a model on your own infrastructure. Both routes use the awork Public API v1 (REST/JSON).
In short: awork + MCP means: “How is the Mustermann project doing?” — the agent pulls status, open tasks, booked vs. budgeted hours and latest activity straight from awork and gives a compact answer.
Use cases: what can an awork MCP server do in practice?
- Project status reports by voice “Give me the status of all active customer projects” — for each project, the agent pulls from awork: progress, open tasks, hours used vs. planned, next deadlines. Output as a clean text block or as a weekly report for management.
- Automatic task routing A new request arrives by email or form. The agent classifies it, assigns it to the right project, creates a task in awork, assigns it to the responsible person and sets a realistic deadline based on current utilisation.
- Time-tracking analysis “Who has booked something this week — and where are hours missing?” The agent compares the time entries against capacity and target hours, shows gaps and suggests sensible late bookings. Employees confirm the suggestion with one click.
- Onboarding new projects A new customer signs the quote? The agent creates the project in awork, clones the matching project template, assigns team members, creates milestones and sets up the first time-booking categories — in seconds instead of long click work.
- Utilisation & capacity planning Before accepting a new project, sales asks the agent: “Do we still have 60 hours of frontend free in June?” — the agent pulls target utilisation from awork and answers concretely.
- Escalating overdue tasks The agent runs daily across all awork tasks, identifies overdue tasks, writes a friendly nudge to the responsible person and escalates to the project lead according to defined rules — nothing slips through any more.
How the integration works
Architecture:
AI agent ↔ MCP server (official from awork or own EU host) ↔ awork Public API v1 (REST/JSON, OAuth or API key)
Concrete steps:
- API access & token: According to awork, an API key is not user-specific and has admin access to the workspace. Minimal permissions are only available via OAuth: the token then applies per person and respects their roles. If we use an API key, we limit the permissions in our own MCP server through fixed, defined tools.
- Tool definitions: Typical tools:
list_projects,get_project_status,create_task,update_task,list_time_entries,get_team_capacity. Each with a JSON schema. - Data minimisation: The agent gets only the projects and fields the use case really needs — confidential customer projects can be excluded.
- Write operations & approval: Task creation and status changes are fine to run directly in most setups. Time bookings typically happen as a suggestion with confirmation by the employees.
- Webhook connection: Optional — on new tasks, status changes or completed projects, the agent can act reactively, for example to trigger the next workflow step.
GDPR, hosting & security
According to its DPA, awork runs in German Azure data centres. This applies to the awork data itself; where the AI model runs is decided by the AI provider you choose. Our standard for awork MCP:
- EU hosting for the MCP server, no US edge.
- OAuth per person, where possible; an API key with admin access is stored only encrypted on the MCP server and rotated regularly.
- Data minimisation: Even within permitted scopes, we filter out fields the specific use case does not need — hourly rates and internal comments are excluded by default.
- DPA with the AI provider, EU data residency (Claude via AWS Bedrock EU, Azure OpenAI in an EU region, etc.).
- Logging: Every tool call is documented with timestamp, affected project and triggering person — the audit trail can be traced at any time.
- Works council involvement: For employee-related analyses (utilisation per person), we provide a template for informing the works council.
Typical setups
- Agency: Project status reports + automatic task routing from the inbox. Realistic to implement as a clearly defined package.
- Consultancy: Utilisation + capacity planning + time-tracking assistant. Realistic as a separate stage.
- Engineering team: awork as the project layer, MCP server as a bridge to Slack and Outlook — tickets from chat become awork tasks directly.
What does it cost?
- Use-case-driven approach: First one concrete workflow in production — then expansion.
- First results with one clearly defined use case are realistic.
Related guides
Frequently asked questions
Which awork API does the MCP server use?
The official awork Public API v1 (REST/JSON). Access via OAuth with the respective person’s permissions or via API key with admin access to the workspace. It covers projects, tasks, time entries, teams, tags and templates.
Is there an official awork MCP server?
Yes. awork runs its own MCP server at https://api.awork.com/api/v1/mcp. Sign-in works via OAuth 2.1 (also with Dynamic Client Registration) or via an API key as a bearer token. With OAuth, the agent acts with the permissions of the signed-in person; according to awork, an API key is not user-specific and has admin access. We build our own MCP server if you need fixed tools instead of free API access, a separate log or a model on your own infrastructure.
Can awork be hosted in a GDPR-compliant way?
Yes, if the chain is right: according to its DPA, awork processes the data in Azure data centres in Frankfurt am Main and Berlin, and a DPA is standard. For the AI connection, an EU-hosted MCP server and an AI provider with a DPA and EU data residency are added. With the official awork MCP server, the terms of your AI client also apply.
Can the AI agent create time entries?
Yes. In practice we work with a suggestion model: the agent creates time-booking suggestions based on calendar data, Slack activity or meeting notes, and employees confirm with one click.
Does this work with awork webhooks?
Yes. The MCP server can react to events such as “new task”, “status change” or “project completed” — for example to trigger follow-up workflows.
Do agents see all projects in the workspace?
No. With OAuth, the agent sees only what the signed-in person is allowed to see. An API key, by contrast, has admin access to the workspace according to awork; in that case we limit projects and fields in our own MCP server per use case. Confidential projects or internal packages can be excluded that way.
Want an MCP server for your system?
A 30-minute initial consultation — we check whether your systems are MCP-ready and estimate the project effort.
Book an AI Check arrow_forward