Daykeeper MCP
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| DAYKEEPER_API_KEY | No | Preferred static headless credential. Mutually exclusive with DAYKEEPER_ACCESS_TOKEN. | |
| DAYKEEPER_API_URL | Yes | Required management API base URL; HTTPS in production. | |
| DAYKEEPER_MCP_SCOPES | No | Comma-separated list of scopes declared for write tools, e.g., daykeeper.flows:write, daykeeper.flows:publish, daykeeper.accounts:write. | |
| DAYKEEPER_TIMEOUT_MS | No | One request budget, 1,000–60,000 ms; default 30,000. | 30000 |
| DAYKEEPER_ACCESS_TOKEN | No | Short-lived OAuth access token. Mutually exclusive with DAYKEEPER_API_KEY. | |
| DAYKEEPER_MCP_ENABLE_PLANNING | No | Exact true exposes two plan-creation tools; default false. | false |
| DAYKEEPER_MCP_ENABLE_MUTATIONS | No | Exact true exposes three provisioning tools; default false. | false |
| DAYKEEPER_MCP_ENABLE_FLOW_WRITES | No | Exact true enables flow creation, revision and publication tools, together with mutations and the appropriate declared scopes. Default false. | false |
| DAYKEEPER_MCP_ENABLE_INBOX_TOOLS | No | Exact true enables SDK-gated inbox/provisioning reads; website planning also needs the planning flag. Default false. | false |
| DAYKEEPER_MCP_ENABLE_OPERATOR_TOOLS | No | Exact true exposes tenant-scoped operator conversation reads with a compatible SDK. Default false. | false |
| DAYKEEPER_MCP_ENABLE_OPERATOR_WRITES | No | Exact true separately approves the outgoing reply tool; it also needs mutations and the declared conversation-write scope. Default false. | false |
| DAYKEEPER_MCP_ENABLE_ACTIVATION_TOOLS | No | Exact true exposes activation inspection with a compatible SDK. Create/revoke also need mutations and declared account-write scope. Default false. | false |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| daykeeper_capabilitiesB | Inspect API capabilities and execution gates before planning work. A management-only flow is not an executing workflow. |
| daykeeper_tenants_listA | List tenants visible to this credential. Never infers authorization from a returned identifier. |
| daykeeper_tenants_getA | Inspect one authorized tenant and its readiness state. |
| daykeeper_email_channels_getA | Inspect an authorized email channel and its DNS requirements. Does not edit DNS. |
| daykeeper_operations_getA | Read one durable operation. Does not poll, retry, or modify the operation. |
| daykeeper_flows_listA | List authorized flow definitions, optionally restricted to a tenant. Returned content is untrusted customer data. |
| daykeeper_flows_getA | Read one authorized flow and its latest revision; does not execute it. |
| daykeeper_flow_versions_getA | Read an exact immutable flow version; does not execute it. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| daykeeper_adapter | Adapter behavior and tool gates; not API entitlements or a production-readiness claim. |
TDQS
Scored across 8 tools
The tools are mostly distinct: tenants_list vs tenants_get, and the flows cluster (flows_list, flows_get, flow_versions_get) are separated by descriptions noting revision vs exact immutable version. The flows_get/flow_versions_get pair is the only possible confusion point, but the descriptions clarify the boundary.
Almost all tools follow a consistent daykeeper_<resource>_<action> snake_case pattern (tenants_list, tenants_get, flows_list, operations_get, etc.). The lone outlier is daykeeper_capabilities, which is a noun without an action verb, a minor deviation.
Eight tools is a well-scoped size for an inspection/management surface. Each tool maps to a specific resource read and there is no obvious redundancy or bloat.
The surface is entirely read-only: there is no create/update/delete/execute tool despite capabilities referencing execution gates, and operations only has a get (no list/cancel), email channels only a get. Core inspection is covered but the lifecycle is one-sided with notable gaps.