Skip to main content
Glama
Sign In

StateLode

by dev.statelode
OverviewDiscussionsAdmin

task_mutate

Mutate a task or sprint. Input is { action, payload, workspaceId? }; payload fields depend on action. Actions (→ marks required payload fields; the rest are optional). dueAt is ISO-8601, e.g. 2026-09-20T17:00:00Z:

  • create → projectId, title; optional: description, priority, status, owner, worker, assignee, tags[], acceptanceCriteria[], dueAt. A new projectId is created by this call (see Projects).

  • update → id, updatedAt; optional: title, description, priority, worker (your agent name claims the work; null releases it), owner (member email = the responsible human; null clears), assignee (legacy), tags[], acceptanceCriteria[], dependsOn[] (task ids; replaces, [] clears), dueAt (null clears it).

  • move → id, updatedAt, status (a key from task_search workflow.statuses, or a category).

  • comment → id, note; optional: notify=true for a meaningful agent progress update. Routine comments do not notify.

  • block → id, updatedAt, reason (sets status=blocked).

  • sprint_create → name and projectId; or scope:"workspace" (+ optional projectIds[], default every project) for a cross-project sprint; optional: goal. A new projectId is created too (see Projects).

  • sprint_assign → id, updatedAt, sprintId (sprintId=null removes the task from its sprint).

  • sprint_activate → sprintId (one active sprint per project, plus one workspace sprint).

  • sprint_complete → sprintId (closes it).

  • project_policy_update → projectId, expectedVersion, content, changeSummary (publishes a new policy version; requires projects:write). Projects: there is no project_create action and none is needed — create and sprint_create auto-create the project when given a projectId this workspace lacks, echoing projectCreated: true. A statelode.json slug missing from statelode://workspace is a forward declaration, not an error: just create the task, and never ask a human to pre-create it in the dashboard. (Only task_search rejects an unknown projectId; reads must not mint projects.) If implicit creation returns project_workspace_collision, this slug already exists in another readable granted workspace. No write occurred. Resolve the intended project with the human and persist workspaceId in the repository pin; do not blindly retry using the default workspace. An explicit workspaceId permits intentionally separate projects with the same slug. Project creation workspace precedence: explicitly named workspaceId, then the repository-pinned workspaceId in statelode.json, then the human-selected default from statelode://workspace. One accessible workspace needs no prompt. If multiple workspaces have no explicit or pinned/default signal, ASK the human and retry with workspaceId; the server rejects silent guesses. Before create/sprint_create, state the selected workspace and offer a quick switch. Explicit input always overrides defaults. Ungranted ids are rejected. Attribution comes from the bearer token. Scheduling: dueAt is the only forward-looking field — createdAt/updatedAt both record the past. An unscheduled task is not the same as one due now, so set dueAt only when a real deadline exists. Enums: priority = urgent|high|medium|low. status = a workflow key from task_search workflow.statuses[].key (projects define their own columns; keys are stable, names are labels and are rejected) or a category backlog|active|in_progress|review|done|archive|blocked, which lands in that category's first column. Owner and worker are separate: owner is the responsible human (a member email from statelode://workspace), worker is the agent doing the work. Claiming sets worker and never replaces the owner; an unowned task you claim or create is owned by your human supervisor. Legacy assignee still works: a member email/name sets owner, any other string (for example "codex") sets worker. Optimistic locks: update/move/block/sprint_assign require the task's last-seen updatedAt; on mismatch STALE_WRITE carries the fresh task. project_policy_update requires the last-seen expectedVersion; on mismatch STALE_PROJECT_POLICY carries the fresh policy. Sprints and project policy are managed through this existing tool, never extra tools. Responsibility guidance: Team lead, Contributor, and Observer describe how an agent should collaborate on behalf of its human supervisor; they do not authorize or forbid actions. The credential scopes returned in delegation.capabilities are the permission boundary. Any Delegate with the required scope may search, update, create, assign, review, manage sprints, or publish policy. Planning: represent a plan as a sprint goal plus concrete tasks. Call sprint_create, create each task with a human member email from statelode://workspace, then sprint_assign each task. There is no separate plan tool. Squads (only where the workspace uses them; repeated in the server instructions): a write in another squad's lane returns SQUAD_BOUNDARY (or, in advisory mode, a warning) carrying suggestedRequest — send it unchanged as request_create and let that squad decide.

  • request_create → toSquad (slug), projectId, title; optional: description, acceptanceCriteria[], priority, neededBy, blockingTaskId (your task that waits: accepting wires the dependency, and finishing the work unblocks it).

  • request_respond → id, decision: accept | decline | needs_info (the receiving squad's leads) or answer | cancel (the requester); note is required to decline, ask or answer; on accept, optional owner, priority, dueAt. task_search with requests:"incoming"|"outgoing" lists requests instead of tasks.

Input Schema

NameRequiredDescriptionDefault
actionYes
payloadYesAction-specific fields — see the tool description for each action's required/optional payload.
workspaceIdNoGranted workspace id. Explicit input overrides the repo pin/default. Required for project creation when a multi-workspace grant has no human-selected default.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes far beyond the annotations, which only declare readOnly=false, destructive=false, idempotent=false. It documents optimistic-lock contract (updatedAt/expectedVersion, STALE_WRITE/STALE_PROJECT_POLICY carrying fresh state), null-clears semantics (dependsOn [], dueAt null, worker/owner null), project auto-creation and projectCreated:true, project_workspace_collision with no-write guarantee, SQUAD_BOUNDARY with suggestedRequest, and that attribution comes from the bearer token. No claim conflicts with destructiveHint=false since clearing is disclosed as explicit null input.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the { action, payload, workspaceId } shape and a bulleted action table where every bullet earns its place. It is still very long, and the Responsibility guidance paragraph (Team lead/Contributor/Observer) plus the self-referential note that squads are 'repeated in the server instructions' dilute focus without adding invocation value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, yet the description supplies the return signal an agent needs: projectCreated, STALE_WRITE/STALE_PROJECT_POLICY error payloads, project_workspace_collision meaning, and suggestedRequest. For a 12-action, nested-payload mutation tool spanning tasks, sprints, policy and squad requests, little is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is only 67% and the payload is a freeform additionalProperties object with a single pointer back to the description, so the description carries the full burden — and it does, enumerating required vs optional payload fields for all twelve actions. It also disambiguates owner vs worker vs legacy assignee and constrains status to workflow keys or categories.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

A specific verb (

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit per-action routing plus negative guidance: no project_create exists, no separate plan tool, task_search with requests:"incoming"|"outgoing" is named as the read counterpart for squad requests. Workspace precedence rules spell out exactly when to ask the human versus proceed, which is real when-to-use guidance rather than inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All StateLode toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources