Skip to main content
Glama
borgels

mcp-server-productive

by borgels

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
MCP_HTTP_TOKENNoBearer token required for the HTTP transport when PRODUCTIVE_TRUST_FORWARDED_USER is true.
PRODUCTIVE_API_TOKENNoA Productive API token (Settings → API integrations in Productive; it inherits the creating user's permissions). Required for shared token mode; deliberately unset when using per-user auth.
PRODUCTIVE_AUDIT_LOGNoPath to append one JSON line per mutation attempt, including the ones policy refused. Request bodies are deliberately not recorded.
PRODUCTIVE_STORE_PATHNoPath to the store file for encrypted per-user tokens. Persist on a volume.
PRODUCTIVE_ENABLE_ADMINNoEnable admin resources: people, memberships, permission sets, teams, invitations, custom fields, webhooks, integrations, approval and time-tracking policies. Off by default.
PRODUCTIVE_ENABLE_WRITESNoMaster switch for writes. Nothing is mutated without it. Off by default.
PRODUCTIVE_PER_USER_AUTHNoSet to true to enable per-user token linking (recommended). Each person links their own Productive token.
PRODUCTIVE_ENABLE_DELETESNoEnable deletes, on top of the tier gate. Off by default.
PRODUCTIVE_ENCRYPTION_KEYNoEncryption key (min 16 chars) used to encrypt stored per-user tokens at rest with AES-256-GCM. Keep it stable or stored tokens become undecryptable.
PRODUCTIVE_PREPARE_SECRETNoHMAC-SHA256 signing key for staged two-step operations. When unset, a random key is generated at start-up, so staged operations do not survive a restart and are not valid across replicas.
PRODUCTIVE_ORGANIZATION_IDNoThe numeric id of your Productive organization (from your Productive URL). Required in both authentication modes, and never a tool argument.
PRODUCTIVE_PUBLIC_BASE_URLNoPublic base URL for generating /productive/enroll links. Route /productive/* on this URL straight to the container, bypassing the MCP gateway.
PRODUCTIVE_DENIED_RESOURCESNoNarrow an instance by denying resources. Applies to reads as well as writes.
PRODUCTIVE_ALLOWED_RESOURCESNoNarrow an instance to an allowlist of resources. Applies to reads as well as writes.
PRODUCTIVE_ENABLE_FINANCIALSNoEnable financial resources: invoices, line items, payments, bills, expenses, purchase orders, proposals, contracts, prices, rate cards, salaries, overheads, tax rates, bank accounts, subsidiaries. Off by default.
PRODUCTIVE_REQUIRE_EMAIL_MATCHNoSet to true to refuse linking a token whose owner's Productive email differs from the caller's directory address. Off by default.
PRODUCTIVE_TRUST_FORWARDED_USERNoRead the X-MCP-User header to identify the caller. Only enable behind a gateway that sets the header from a validated token and strips a client-supplied copy. The HTTP transport refuses to start with this on unless MCP_HTTP_TOKEN is set too.

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

CapabilityDetails
tools
{
  "listChanged": true
}

Tools

Functions exposed to the LLM to take actions

NameDescription
productive_search_capabilitiesA

Find the right resource, tool or guide for a subject. Start here: Productive names its resources its own way (a budget is a deal, a person is a person, a board column is a workflow_status), and guessing wastes calls. Returns matching tools, workflow guides, and resources with the operations each supports.

productive_describe_resourceA

The exact contract for one resource, derived from Productive's own OpenAPI document: every filter field, the operators any field accepts, sort keys, report group keys, includable relationships, the writable attributes for create and update with the required ones marked, and any named actions. Read this before writing — it is the difference between a write that lands and a 200 that changed nothing.

productive_check_connectionA

Verify the token and organization and report what this deployment may do. Also names the person the token belongs to — every change Productive records is credited to them, whoever asked — and the caller identity, when a gateway forwards one.

productive_describe_custom_fieldsA

List the organization's custom fields with the id each value is written under, the object it applies to, and its options. Custom-field values are keyed by numeric id, not by display name — a name used as a key is accepted with 200 and stored nowhere.

productive_listA

List any Productive resource with server-side filtering, sorting, includes and paging. Also how the 26 report endpoints are read: use resource "reports/time_reports" (and the rest) with group to get aggregated rows instead of records. Results are flattened out of JSON:API — attributes hoisted, included records inlined into their relationship — with total and nextPage so a page is never mistaken for the whole answer.

productive_getA

Read one record by id, optionally pulling related records in the same call rather than following relationship stubs one at a time.

productive_createA

Create a record on any writable resource. Required attributes are checked first, and so is every attribute name. On a financial or administrative resource this returns a staged operation to review rather than creating anything — pass it to productive_commit_operation to go through with it.

productive_updateA

Update a record. PATCH semantics, verified live: attributes you omit keep their values, so there is no need to resend the whole record. On a financial or administrative resource this returns a staged operation instead of writing.

productive_deleteA

Delete a record. Needs its own switch beyond ordinary writes, and always returns a staged operation first. Many Productive types are meant to be archived rather than deleted — check productive_describe_resource for an archive action before reaching for this.

productive_run_actionA

Run one of Productive's named verbs: archive, restore, close, open, approve, reject, copy, finalize, send, reposition and the rest. Actions named bulk_* act on every record the filter matches rather than one, and refuse to run without an explicit filter. productive_describe_resource lists the actions a resource has.

productive_track_timeA

Log a time entry without looking up what Productive insists on. Time is stored in MINUTES — pass hours and it converts. The service (the budget line the work bills to, not the task) is resolved from the task when not given, and the person is resolved from the authenticated caller, so time lands on the right person even though the server holds one shared token.

productive_commit_operationA

Execute a write that a prepare step staged. Pass the operation object back exactly as it was returned: it is hashed, and an altered operation is refused rather than run. Show the change to the person who asked for it before committing.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.3/5.0

Scored across 12 tools

Disambiguation5/5

Each tool targets a distinct operation: reading one record, listing, creating, updating, deleting, running a named action, staging/committing writes, tracking time, or performing a meta/introspection task. Even the closer pairs like get/list and describe_resource/describe_custom_fields are clearly separated by resource scope and purpose.

Naming Consistency5/5

All tools follow the snake_case productive_<verb> pattern, with most using verb_noun (productive_check_connection, productive_run_action) and a few using bare verbs (productive_get, productive_list). This is consistent and predictable, with no style mixing or vague duplicate verbs.

Tool Count5/5

Twelve tools is well within the ideal scope for a broad API integration server. The set covers generic CRUD, named actions, time tracking, staged writes, and meta/discovery tools without ballooning into redundant or overly granular endpoints.

Completeness5/5

The server provides full lifecycle coverage: read, list, create, update, delete, run actions, and commit staged operations, plus support for custom fields and resource contracts. The meta tools fill the gaps that typically cause agent failures, such as knowing resource-specific filters, writable attributes, and custom-field keying.

Maintenance

ActivityMaintained
ResponsivenessNo issues