FlowCastle

update_pulse_item

DestructiveIdempotent

Change one Pulse item's state. Every action changes the queue for the WHOLE workspace — an item belongs to the workspace, not to whoever called the tool, so dismissing a recommendation hides it from every member and records who decided that. acknowledge closes an attention item as seen, with no reason and no note — it is the only hand-close an automatic item accepts. resolve closes with a resolutionCode and is refused for an automatic item. Both need the permission for the item's source (manage_broadcasts for a broadcast, manage_automation for a flow, sequence or operation), and a critical item that is not manual by policy can be closed only by an owner or admin (a workspace key counts as owner); resolve on such an item also needs a note. Closing a card does not fix its cause, and it hides the problem: an item closed by hand is NOT raised again for 14 days, even while its detector still observes the condition. Only an anomaly the platform closed itself (resolutionCode source_condition_cleared) reopens at once when the condition returns. A dismissed recommendation returns by itself after the same cooldown. Does not apply a recommendation's proposed change — that is a dashboard action.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "itemId": "<itemId>",
      "action": "<action>"
    },
    "name": "update_pulse_item"
  }
}

Input Schema

Name	Required	Description
`note`	No	Free-text note stored with a `resolve`. Required when resolving a critical item that is not `manual` by policy. Ignored by `acknowledge`, which stores no note.
`action`	Yes	acknowledge: close an attention item as seen (the only hand-close an `automatic` item accepts). resolve: close it with a reason (refused for an `automatic` item). dismiss/restore: hide or unhide a recommendation for the workspace. snooze: hide it from the workspace queue until a time.
`itemId`	Yes	Required. Pulse item id, as returned by list_pulse_items.
`reason`	No	Optional reason recorded with a `dismiss`, so a teammate can see why it was waved off.
`snoozeUntil`	No	Required for `snooze`. ISO 8601 timestamp in the future, e.g. "2026-09-15T09:00:00Z".
`applicationId`	No	Application (workspace) id. Optional: an application-scoped key (app_...) defaults to its own application, but a personal key (usr_...) has no default and omitting it fails with MCP_APPLICATION_REQUIRED. Call list_applications to get the id.
`resolutionCode`	No	Required for `resolve`. reviewed = looked at it, no_action_needed = not a real problem, fixed_elsewhere = handled outside the platform.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 9, 2026

changedInput schema / properties / action / description

Previous value: -"acknowledge: close it as seen. resolve: close it with a reason. dismiss/restore: hide or unhide a recommendation for the workspace. snooze: hide it from the workspace queue until a time."New value: +"acknowledge: close an attention item as seen (the only hand-close an `automatic` item accepts). resolve: close it with a reason (refused for an `automatic` item). dismiss/restore: hide or unhide a recommendation for the workspace. snooze: hide it from the workspace queue until a time."

changedInput schema / properties / note / description

Previous value: -"Free-text note stored with a `resolve`. Required when overriding a critical item."New value: +"Free-text note stored with a `resolve`. Required when resolving a critical item that is not `manual` by policy. Ignored by `acknowledge`, which stores no note."

AddedSep 9, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Far beyond the annotations: it discloses that actions mutate a whole-workspace queue, record the decider, hide the item from every member, and that a hand-closed item is suppressed for 14 days even while the detector still fires, with the sole immediate-reopen exception (`source_condition_cleared`). These consequences of a destructive mutation are exactly the context annotations cannot carry.

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 core verb and scope, and every clause carries operational weight (cooldowns, permissions, exclusions). It is dense to the point of being a single block paragraph, which costs some scannability, but there is no filler or repeated name/title restatement.

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?

For a destructive mutation with no output schema, the description covers side effects, workspace blast radius, permission gating, failure conditions, and the reopen/cooldown lifecycle. An agent has everything needed to choose an action and predict the outcome without a return-value contract.

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

Parameters4/5

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

Schema coverage is 100% and the schema already documents the action enum, note, reason, snoozeUntil, and resolutionCode, so the baseline would be 3. The description adds cross-parameter conditional logic (note requirement on critical non-manual resolves, permission coupling per item source) that the per-field schema text cannot express on its own.

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?

States a specific verb and resource ("Change one Pulse item's state") and enumerates the five mutation modes with their meanings, which separates it cleanly from read-side siblings like get_pulse_item and list_pulse_items. The final sentence explicitly excludes applying a recommendation's proposed change, drawing a hard boundary against the dashboard/apply path.

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?

Gives per-action selection rules: `acknowledge` is the only hand-close an `automatic` item accepts, `resolve` is refused for `automatic` items, and dismiss/restore/snooze are scoped to recommendations. It also names the required permissions per source type and the owner/admin escalation for critical non-manual items, so an agent can decide feasibility before calling.

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

All FlowCastle tools Inspect

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.