Tool catalog

Show what DigitalStack can do inside an MCP client: a capability guide and live status console covering version, connected modules, the kinds of questions that can be asked, example prompts by role, and what is coming next. Makes NO DigitalStack API call and returns no customer data, so it is safe to call at any time and needs no scope. For an actual answer about a customer or project, use query_context.

Ask a question and receive an evidence-backed Operational Delivery Brief assembled live from Project Health and Project Risk authorities. Project IDs target one project; engagement IDs compose caller-visible projects; no ID means portfolio scope. Read-only. It does NOT retrieve uploaded documents, transcripts, decisions, assumptions, or requirements, and performs no semantic search.

Search the Engagement Knowledge Corpus: ranked full-text retrieval of evidence spans from ingested Context Sources bound to an authorized project or engagement. Returns exact passages with provenance (source, page/paragraph/section, provenance quality, timestamps) — evidence, not a synthesized answer. It does NOT return project health or risks, does NOT synthesize decisions, and performs NO semantic/vector search (PostgreSQL full-text only). Project queries search directly-bound sources; engagement queries fan out to caller-visible child projects (direct engagement-bound sources are not yet supported). Read-only. This is the legacy Knowledge-only tool; for cross-domain Context Platform search across evidence, adopted definitions, and decisions in one call, use the platform-native search_unified_context tool.

Cross-domain Context Platform search over the authorization-safe router. Searchable providers are Knowledge, Adoption, Decisions, Context Opportunities, and derived Context Concepts. Opportunity is advisory and included in the router’s bounded default; Concept is advisory, project-scoped, derived on read, and must be requested explicitly. Delivery, commitment snapshots, and relationships do not support search. Results include per-provider status, item authority, freshness, coverage, limitations, partial failure, and an opaque continuation cursor. Provider-local ordering; no global relevance score. Read-only.

Retrieve a named, registry-driven Context Platform projection for a subject. The only implemented public projection today is delivery.health (advisory delivery health and risk signals, with financial and staffing fields independently gated). Reserved projections (execution.*, decision.current/history, context.current_version/history) are planned and not callable. Read-only.

Retrieve one context object by its namespaced, domain-owned id, within at least one explicit domain among adoption, decision, commitment (vSOW snapshots), relationship, opportunity, and concept. Opportunity records are advisory platform-owned objects; Concepts are advisory derived projections and are never persisted. The platform never searches every provider by raw id, never infers account or workspace from the input, and preserves non-oracle not-found behavior. Read-only.

List context objects for a subject within explicitly requested domains among adoption, decision, commitment (vSOW snapshots), relationship, opportunity, and concept. Opportunity records are advisory; Concepts are project-scoped derived projections. At least one explicit domain is required to avoid accidental broad fan-out. Pagination is provider-specific inside one opaque continuation cursor; ordering is deterministic but not a universal cross-domain chronology; lifecycle and history semantics remain provider-owned. Read-only.

Read Context Engine availability, package/provider counts, freshness posture, supported capabilities, and recent packages.

List governed context packages with evidence coverage, provenance, freshness, and provider attribution.

Retrieve one governed context package with canonical source reference, provenance, freshness, and coverage.

Search persisted context contributions without invoking arbitrary model execution.

Read policy-safe evidence references and provenance without exposing raw source bodies.

Inspect provider capabilities, contribution counts, coverage, freshness, and authority boundaries.

Read the caller’s daily focus package with an evidence-backed summary, attention items, related entities, coverage, and provenance.

Record an explicit resolve, dismiss, or snooze action for a Today & My Work attention item and emit the matching webhook event.

List the workspace’s projects (engagements) with client name, status, and last-updated time. Useful to enumerate work or resolve a project name to its id.

A one-call health snapshot for a project: delivery status, alerts, phase and milestone progress, workstream states, and directional financial/staffing signals (governed by your permissions).

Record a confirmed acknowledgement for one advisory Project Health alert and emit project_health.alert_acknowledged.

List visible canonical projects/engagements through the governed public API.

Retrieve one visible canonical project/engagement identity record.

Create one canonical project/engagement identity through a confirmed, idempotent command.

Update bounded project identity and relationship fields.

Run one explicit project lifecycle status command.

Archive one project through the explicit project lifecycle command path.

List governed project membership rows for one visible project.

Add one new project member through a confirmed command. Conflicts if the user is already a member; the subject must be an active member of the project account.

Update one project member role through a confirmed command. This is the only operation that changes an existing membership role.

Remove one project member through a confirmed command.

Read bounded public project settings.

Update bounded project settings through a confirmed command.

Read one governed estimate, or list estimates for a project, with scope, effort, role demand, risks, timeline, provenance, and immutable-baseline identity.

Persist a reviewable estimate change proposal without mutating canonical estimate, staffing, schedule, or baseline state.

Submit a confirmed draft proposal for human baseline review. The MCP tool cannot freeze, approve, sign, or supersede a baseline.

Report on a project’s active (or specified) sprint: goal, totals, work items by status, blocked items, and spillover risk.

Read a project sprint-planning context and readiness score as a read-only projection.

Generate citation-gated planning intents for review. Proposal-only; it does not apply a plan or move work.

Read governed delivery milestones and workstreams for one project without moving execution coordinates.

List Delivery-owned milestones for one project with scoped work-item ids.

Retrieve one governed Delivery milestone.

List project workstreams through the execution read provider. Read-only in this slice.

Run one confirmed governed milestone status command.

Run one explicit milestone target-date command; does not resize phases or move work.

Run one explicit milestone progress command for completion percentage and/or projected date.

Read canonical DigitalStack work items using board-safe filters such as team, sprint, parent, assignee, and status bucket. Use this to find the right work item before drilling in or running Work Item Enhance.

Read the canonical DigitalStack work-item board grouped by status bucket. This is a read-only projection over Execute work items and does not move cards or mutate workflow state.

Read one source-aware Execute work item through the governed public Work Items API. Jira-backed reads hydrate authoritative description, discussion, people, hierarchy, and relationships without asking the model to infer missing facts.

Read transition history for one canonical work item without changing status, ranking, or board placement.

Inspect the current version, allowed transitions, editable fields, and supported commands before an agent proposes a work-item operation.

Add an attributable comment after explicit confirmation. If the work item is Jira-backed, DigitalStack validates and passes the comment through to Jira. DS-40 (comment sub-scope) — a ticket-backed work item (the substrate every DS-native project uses) is fully supported: the comment writes to that project's own ticket_comments, not the canonical execute_work_item_comment table. `mentions` and `evidence_refs` are refused (422 capability_unsupported), not silently dropped, for a ticket-backed item — ticket_comments has neither column. Ticket #565C — attachments: the REST endpoint accepts an optional `attachments: [{ filename, mime_type, data_base64 }]` array (images only, 25MB/file), requires a work item backed by a native DigitalStack ticket (422 ATTACHMENTS_REQUIRE_NATIVE_TICKET otherwise, which today means every case — canonical execute_work_item items have never supported attachments) and a principal bound to a DigitalStack user (422 ATTACHMENTS_REQUIRE_USER_PRINCIPAL otherwise). The response includes `attachment_ids` when attachments were supplied; it does NOT include a separate `ticket_comment_id` — the created comment IS the ticket_comments row, not a mirror of one. The `attachments` parameter is not yet exposed by the live dsmcp tool schema — this doc overlay records the target contract for whoever updates that separate gateway service; it is not something this repo can change.

Apply one allowed Execute flow-state transition after confirmation. Jira-backed work items pass the mapped transition through to Jira.

Assign, reassign, or unassign a work item after confirmation, with Jira pass-through for Jira-backed work items.

Set or clear start, due, target, sprint, or ordering fields through the scheduling command boundary. Jira due-date writeback is supported when mapped.

Set or clear work-item points after confirmation. Jira-backed estimates require a configured story-points field mapping.

Add, remove, or replace normalized labels after confirmation. Jira-backed labels are passed through to Jira.

Create a dependency or relationship after validating target visibility and cycles.

Raise, update, transition, or resolve a blocker linked to a work item after confirmation.

Pin, reprioritize, snooze, annotate, or clear a work item in focus views without mutating authoritative schedule or staffing.

Attach a commit, pull request, branch, deployment, release, build, or evidence reference to a work item through the same governed path as the app’s "Add Link" action. Refuses a duplicate (same provider + artifact_type + external_ref) with a conflict rather than creating a second link. Not idempotent by key — there is no replay ledger on this endpoint; duplicate protection is the refusal itself, so a retry after a successful call is refused, not replayed. Distinct from link_work_item_dependency, which links work item to work item, not work item to external artifact.

Atomically reserve the highest-priority claimable work item in a project under a time-bound lease, so two concurrent agents are never handed the same item. Candidates are not_started and ready items only — never blocked, and never a container — ordered critical, high, medium, low, then oldest first. A ticket with live children is a container: claiming one would reserve a folder rather than work, so parents are excluded structurally (by having children, not by declared type). `backlog` is deliberately out of scope as the unrefined pool, so a critical item sitting in backlog is a signal to refine it rather than an empty queue. A claim is a transient agent reservation, NOT an assignment: it never sets or clears the assignee. An expired lease is automatically reclaimable, so a crashed agent’s item returns to the pool without operator intervention. Deliberately not idempotent — two calls should return two different items.

Extend a lease the caller still holds, for an agent whose unit of work outlives the original lease window. Holder-only: a non-holder extending someone else’s lease would be a silent steal, so a non-holder or already-expired lease is a conflict rather than a quiet no-op.

Give up a claim the caller holds, returning the work item to the claimable pool immediately rather than at lease expiry. Releasing a claim you do not hold is reported rather than swallowed, because an agent that believes it released will not retry.

Create a work item through the source provider bound to the project, converging on the same create path as the DigitalStack UI and the public REST and GraphQL surfaces. NOT idempotent: DigitalStack does not deduplicate creates by a caller-supplied key, so a retry after a network failure may create a second item. Confirm before calling.

Set or clear a work item’s parent. DS-native items are validated against the same rules the DigitalStack UI enforces: no self-parent, parent must be in the same project and workstream, no circular reference, and a maximum nesting depth of 2 (three-level trees). A null parent clears it.

Answer "what has already happened against this ticket?" without reconstructing it from Jira, GitHub, or a previous conversation. Returns whether execution started, which session is active and its state, the latest and recent structured activity with who performed it, Launch Package availability and freshness, prior attempts, and the actions available to the caller. Read this BEFORE starting execution to discover work already in progress. A summary whose source does not exist yet is returned as explicitly unavailable with the milestone that will supply it, never as zero.

Create a governed Delivery milestone for a project. Requires an acting user: session and delegated OAuth callers are attributed as the creator, and API-key callers are refused, since a key identifies no caller.

Add one work item into a governed Delivery milestone’s scope. Requires an acting user: session and delegated OAuth callers are attributed as who added it, and API-key callers are refused, since a key identifies no caller.

Begin a durable execution session for a work item, or rejoin the existing live one. At most one live session exists per work item, so calling again RESUMES rather than creating a rival session — safe to use when reconnecting or when unsure whether work already started. Records execution state only: it advances no phase, approves nothing, and touches no provider.

Retrieve the canonical launch context for an execution session: mission, work item, acceptance criteria, execution state, the next authorized action, required outputs, applicable policies, and supporting context. Read this before starting work rather than assembling context by hand. Every section carries its own provenance and freshness, and a structured reason when absent — a section marked `filtered` exists but is outside the caller’s access, while `empty` genuinely has nothing. An absent section never means "nothing to know". Does not recompose; use refresh_launch_package for that.

Recompose the Launch Package and append a NEW immutable revision. Prior revisions are never modified, so what an actor was previously given stays auditable. Use when resuming after a gap, or when the surrounding context is believed to have changed. A partial composition is returned honestly with its warnings rather than as an error.

Read the Cognitive Runtime state for an execution session: the current Understanding summary and version, its review state, every version in history, the open and blocking questions, and the actions this caller may take. Understanding is what an actor ASSERTS they understood the work to be, which is distinct from the Launch Package, which is what the system knows. Content the caller may not see is returned marked `filtered`, never omitted: a filtered field is withheld, not absent.

Create or wholly replace the session’s Understanding draft. WHOLE-CONTENT AND ATOMIC: there is no patch or autosave tool, and a revision is a new version rather than an edit. Facts and assumptions are SEPARATE fields and every known fact must carry a citation — an uncited claim belongs in assumptions. From version 2 onward a proposed_revision_impact is stated, but DigitalStack independently computes an enforced minimum from structural change and a proposal cannot lower it. The returned fingerprint and enforced impact are the server’s.

Read one exact, immutable Understanding version with its structured content, its content fingerprint, the impact its author proposed, the minimum the system enforced and which detectors fired, its contributors, and its submission and review attribution. The fingerprint returned here is what a human reviewer’s decision binds to.

Freeze a draft for review. After this the version’s content, authorship, and enforced impact are immutable, and the previous version is superseded. Submitting does NOT accept the Understanding — a human must still review it. A replayed submit returns the already-submitted version rather than failing.

Ask for a HUMAN to review an exact submitted version. This is the agent’s move: it requests that a human act and cannot perform the act. It changes no state (a submitted version is already reviewable) and it neither accepts nor notifies. Accepting, rejecting, or requesting changes requires an interactive human session in DigitalStack and is unavailable to any credential, whatever its scopes.

List the durable open questions for an execution session, with counts in meta. Questions are PLURAL by design: there is no single "current question", because a session with three unresolved things does not have one. What a question ASKS is immutable; only its answer advances.

Record a durable question against an execution session. What a question ASKS — its text, evidence, origin, and attribution — is immutable once raised; only its answer advances. A blocking question does not prevent an Understanding being submitted or accepted: an artifact whose job is to record what is unresolved would be self-defeating if unresolved questions blocked recording it.

Answer or withdraw a question. Accepts ONLY resolution fields: the original question text, its evidence, its attribution, and its PRIORITY are not reachable here, so answering can never rewrite what was asked. Changing a question’s priority is a separate, separately audited act performed by a human in DigitalStack. resolution_impact is distinct from priority — a blocking question can resolve immaterial when the answer confirms what was assumed. Replaying the same outcome is stable; a different outcome is a conflict.

Detail on a single work item: description excerpt, status, assignee, parent/children, open blockers, and recent status transitions.

List proposal-first enhancement runs by target work item and state.

Create a proposal-first Work Item Enhance run with selected actions such as requirements, description, design, implementation plan, acceptance criteria, test plan, estimate, and risk check.

Retrieve one Work Item Enhance run with target, requested actions, drafts, artifacts, allowed actions, and apply history.

Read the operation-style status view for a Work Item Enhance run.

Run any allowlisted action on an existing enhancement run, such as code context, implementation plan, acceptance criteria, test plan, estimate, or risk check.

Run the requirements action on an existing enhancement run and return generated field-level drafts for review.

Run the description action on an existing enhancement run and return a clearer work-item description draft.

Run the design action and return an advisory design artifact without changing the work item.

Read generated code-context artifacts for a Work Item Enhance run: likely files, likely tests, implementation areas, missing context, and guardrails.

List generated field-level drafts for a run, optionally filtered by action, field, or apply eligibility.

List generated review artifacts for a run, optionally filtered by artifact type.

Read selected drafts and prepare the field-level apply preview. The actual apply remains an explicit confirmed REST command.

Apply selected reviewed drafts to the canonical work item using explicit confirmation, optimistic target versioning, and idempotency.

Aggregated risk picture for a project: delivery alerts, client-dependency blocks, and open risk/gap/request issues, with a coverage block.

List the caller’s self-scoped canonical time entries by date range, project, status, and limit.

Read one self-scoped canonical time entry.

Update one editable self-scoped time entry with optimistic versioning and explicit confirmation.

Void one editable self-scoped time entry with optimistic versioning and explicit confirmation.

Read the caller’s current canonical timer, if any.

Read the caller's privacy-safe work day, including entries, attributed sessions, conflicts, gaps, timer, draft, totals, and submission state.

Persist a proposal from fully attributed DigitalStack work sessions. Conflicts and unresolved evidence remain gaps; no actual time is created.

Apply a reviewed proposal to canonical entries with optimistic versioning, idempotency, and explicit confirmation.

Record one user-supplied time entry. It cannot silently convert inferred activity into an actual.

Start the caller's single canonical timer for an explicit target.

Pause the caller’s active canonical timer with optimistic versioning and explicit confirmation.

Resume the caller’s paused canonical timer with optimistic versioning and explicit confirmation.

Atomically stop the active timer and create exactly one draft entry.

Discard the caller’s active or paused canonical timer without creating a time entry.

Validate and submit one reviewed work day into the canonical approval lifecycle.

Recall one submitted work day while policy permits, using explicit confirmation.

List eligible team time approvals for the authenticated reviewer.

Approve or reject an eligible submission as the authenticated human approver.

List governed provider time import runs for authorized administrators.

Create a governed provider time import run with date range, idempotency, and explicit confirmation.

List governed provider reconciliation findings without exposing raw provider payloads or financial rates.

Run a reconciliation scan for a date range. It records findings only and does not mutate approved entries.

Resolve one reconciliation finding through DigitalStack policy with explicit confirmation.