Skip to main content
Docket returns only the tools that the caller’s current scopes and grants allow. Tool availability can change after consent or grant changes, so handle notifications/tools/list_changed.

​
Tools

The work and planning tools are workspaces, find, list_work, list_resources, get_resources, brief, capture, organize, update, milestones, comment, report_status, link, archive, plan_day, undo, retrospect, view_workload, define_process, schedule_process, repeat_task, define_labels, define_template, list_templates, list_work_schedules, manage_work_schedule, plan_start, plan_read, plan_draft, plan_commit, and track. The agent, session, connector, and directive tools are run_agent, manage_session, link_external, acknowledge_directive, pause_athena_assignment_trigger, and remove_athena_assignment_trigger. get is the compatibility generic entity read. Prefer the semantic readers when a client knows the entity type: get_tasks, get_projects, get_programs, get_initiatives, get_cycles, get_teams, get_updates, get_comments, get_sessions, get_agents, get_views, and get_organizations. review_work_destination reviews a proposed work destination before writing. It does not create or move work on its own.

​
Daily workload

view_workload reads your visible plans and tracked time in one workspace. Supply orgId, a local date in YYYY-MM-DD form, and an IANA timezone, such as America/Los_Angeles. The optional availableHours sets this view’s full-day budget from 0 to 24 hours and defaults to 8. Overlapping tracked time counts once, and the result identifies work with unknown estimates. Headroom compares the workload with that daily budget; it does not measure free calendar time. The view excludes meetings and other workspaces. Reading it does not change plans or your saved availability.

​
Writing

Work edits in this table record an undoable change set. Call undo once and Docket reverses forty edits.

​
Time and reflection

​
Repeating work and processes

​
Work schedules

Use list_work_schedules with orgId and query.action: "list" to discover visible recurring work. Filter by ownerProgramId when reviewing a Program. query.action: "detail" with scheduleId reopens its current private draft; "history" returns a bounded run page. Pass nextCursor back with the same query to continue. Results are under data. manage_work_schedule accepts one command intent. "create" supplies a schedule with a published Task/Project template, private location draft, trigger and effective date. "revise" supplies scheduleId and a revision with the exact expectedRevisionId just reviewed. Revisions apply only from their future boundary; existing work and run history retain their identities. "pause", "resume" and "end" need scheduleId; ending is permanent. "run" supplies scheduleId and run.scheduledFor as a civil YYYY-MM-DD date. Calendar and completion schedules use their saved date identity, so omit occurrenceKey. Manual/event runs may carry a stable key. "retry" supplies the schedule and occurrenceId from history. A failed run returns an application-owned failureCode; canRetry indicates whether retry is available. Retries keep their accepted template versions and do not duplicate work. Results are under data. A Program template can define up to 20 defaultSchedules through define_template with action: "draft". Each outline uses relative cadence and parent assignment rules, without literal people, teams, destinations or provider identifiers. Omission preserves existing defaults; [] clears them. New Programs receive independent schedule copies. Editing an outline leaves existing Programs’ schedules alone; use manage_work_schedule to revise those copies.

​
Create work from a template body

Agents writing tasks, projects, initiatives, or programs should generally look for a relevant template before composing a description. Docket sends this instruction during MCP initialization, in the system prompt, and in the creation tool descriptions. Call list_templates with orgId and the matching targetType. Follow nextCursor when needed. The full literal Markdown body is payload.description. The template’s top-level description only explains when to use it. Read the body, keep its headings and instructions, and fill its sections with the work details. Do not replace it with an invented format or treat attaching an ID as using the template. For example, a Project template with ## Outcome, ## Scope, and ## Evidence should produce a project description with those sections filled in. Use the same rule for a Task, Initiative, or Program template. If none fits, the person requests freeform work, or quick capture needs no outline, proceed without one. Milestones, Cycles, and Teams have no work templates. The creation paths accept the body in these places: apply_template copies missing fields. It does not write the content of the sections, replace an existing body, or create child work. Setting a node’s templateId alone copies nothing. Templates may carry secondary property defaults; preserve explicit values. An explicit empty label list keeps a repeating task unlabelled, deleted default labels are dropped, and a team template must match the repeating task’s team. Personal and team templates remain permission-filtered. capture, organize, repeat_task, and MCP plan_commit require an explicit template decision when eligible saved templates exist. Select a relevant template or provide withoutTemplateReason when none fits, the person requests freeform content, or quick capture needs no outline. An undecided call returns isError: true with code: "template_selection_required" and visible choices before creating any work. The check considers the entity kind, destination team, and caller visibility. It does not seed templates; first catalog reads still install shipped defaults. Reading the returned catalog requires work:read in addition to the creation tool’s work:write. Applying a selected template also requires work:read. A deliberate freeform creation can use a write-only token. Each unresolved choices entry names a catalogId. The matching catalogs entry lists templateIds into the shared templates array, so each full payload appears once. Read its payload.description before choosing it. A write-only client receives insufficient_scope without saved template content. MCP plan confirmation also requires read scope before returning an unapplied template body. Plan confirmation preserves applied property defaults and explicit overrides, including summary, lifecycle status, health, initiative update cadence, program visibility, and task labels. Projects can carry labels from their owning team. Exclusive label groups use the original default label order, even when a group becomes exclusive after the template was saved. For example, create a populated event project with organize:
Read placed[0].description, fill its sections, and call update with entity: "project", scope: { "ids": ["<returned-project-id>"] }, and set: { "description": "<completed Markdown>" }. Nonempty Markdown remains literal through this edit. Creation and completion are separate writes, so an interrupted agent can leave a populated outline behind. Agents that already know the full body may provide the completed description in the creation call instead. Templates supply defaults rather than locking fields. Manual dates, placement, owners, leads, priorities, and labels remain available. Empty bodies and label lists explicitly suppress those defaults. Invalid saved statuses or label scopes fail rather than silently substituting other values; an explicit override can repair the creation call. Matching existing work never reapplies its template, overwrites its body, or adds default labels. Planning remains editable before confirmation. Apply templates through plan_draft, then fill sections through set_fields. MCP plan_commit checks selected nodes and their unconfirmed ancestors. It accepts withoutTemplateReason for untemplated nodes. A node that only names a template without applying its available body returns template_application_required before confirmation. The human canvas does not require a template choice or a freeform reason. Both confirmation paths validate selected template visibility, kind, and destination team. Applying a template records copied label defaults so deleted inherited labels can be dropped even after the template changes. Explicit label edits clear that record and remain strict. list_templates needs work:read and workspace view access. It initializes shipped defaults on the first template read, following the same rule as the template picker. define_template authors the starting body and composed child work. Use action: "draft" with blueprint to create or replace the child definition; omitting it preserves the existing children, and an explicitly empty graph clears them. Existing draft edits require the returned revision as expectedRevision. Discover the saved definition with list_templates, then use action: "publish" and the reviewed revision to share an immutable version. Publication and archive calls refuse simultaneous draft edits. Legacy writes without action retain their existing behavior and cannot author a blueprint. Creation expands a published template transactionally, including nested work, with a maximum of 500 new items across the creation. Reusable children can use relative dates and parent-based responsibility rules; workspace-specific assignments belong on the actual work. define_process and schedule_process separately define recurring work and its schedule. Legacy process definitions are private to their author and current workspace managers. A manager of a Program can manage its schedules without gaining access to another author’s private process body. Schedule history and generated-work links also respect current work visibility.

​
Labels and templates

Put labels on work with update: set.labels takes add and remove, or replace on its own. A label limited to one team only goes on that team’s work, and anything else is reported as label_out_of_scope. Creating a label or a template needs contribute access. Renaming, recoloring, regrouping, or rescoping a label, and any change to a label group, needs manage access. An entry the caller may not write comes back in skipped while the rest of the call applies. Undoing a created label or group deletes it only while nothing uses it, and reports it as in_use otherwise. define_labels and define_template do not delete or merge labels and templates. Use the settings pages for that.

​
Agents, sessions, and connectors

send_email requires work:write, an active enrolled channel and an authenticated Athena session executing the approved action. The owner reviews the recipient, subject, complete body and immutable attachment list in Docket. Email replies cannot approve sends, and ordinary external MCP callers cannot send directly. Received UTF-8 text, Markdown and CSV files can be attached, up to five files and 64 KiB per file.

​
Scopes per tool

See Authentication for requesting and stepping up scopes. work:read gates reads. work:write gates work mutations and time tracking. agents:run gates agent sessions and Athena assignment controls. connectors:link gates external linking. offline_access only allows token refresh. Every call still checks the person’s current Docket grant.

​
Library resources

Use list_resources to discover linked resources and attachments. Supply orgId for one workspace, or omit it to search every workspace the authenticated user can access. Registered agents remain restricted to their own workspace and grants. These tools require work:read and the existing MCP product access in each workspace. query defaults to an empty string, which browses by recency; a nonempty query uses search ranking. kinds accepts external_resource and attachment; omitted or empty selects both. limit defaults to 50 and accepts 1–100. Pass nextCursor as cursor with the same workspace, query and filters. Search indexing can lag behind writes. A stale page can contain fewer items, including none; continue while nextCursor is present. Use get_resources with 1–10 refs, each containing orgId, kind and id, to read current details. Each result has status: "ok" with resource, or status: "not_found" for both missing and inaccessible resources. Details include saved metadata, a source URL, permission-filtered usedIn containers and usedBy references, and explicit content availability. These reads check live source rows and access even when the item has not been indexed yet. A batch scope or product access failure remains a tool error rather than a per-item miss. The uri on a result supports the same detail read through resources/read:
Uploaded files with content.status: "available" provide a content URI and MIME type. Read that URI through resources/read to receive an MCP base64 blob:
Content reads recheck current access and enforce the 4 MiB upload ceiling against declared and actual file sizes. Details report unavailable for absent stored bytes and too_large for oversized files; their content URIs cannot be read. Linked resources and other attachment kinds report unsupported: saved previews do not grant access to the source document. This interface does not search providers live, scrape web pages, or convert documents. Linked metadata retains Library’s workspace visibility. Attachments follow their current subject’s visibility, and usage lists omit work the caller cannot read. Credentials, storage keys, arbitrary attachment metadata and internal integration identifiers are excluded.

​
Resources

Use these caller-scoped resources for discovery and Hub views: Read one entity through:
type is task, project, program, initiative, cycle, team, update, comment, session, agent, view, or org. Docket returns an unreadable resource as not found. MCP Apps clients can also render ui://docket/* resources. Other clients receive structured tool and resource results. Results from the get_* tools and update can include _meta["docket/render"], a display model the app draws from. Clients that do not render apps can ignore it.

​
Prompts and notifications

The server registers docket_system, task_brief, and standup prompts. It supports resource subscriptions and emits notifications/resources/updated as a best-effort signal. Re-read the resource after the signal because Docket does not replay a notification stream. The server also advertises resources.listChanged, prompts.listChanged, completions, and logging. Experimental MCP task support depends on the deployment configuration and is not a public REST API capability.