noticed

list_actions

Read-onlyIdempotent

Every OPEN follow-up / action across your WHOLE network in one call, each attached to the person it belongs to — ordered like /home (soonest remind_at first, undated last). scope:'team' returns consent-gated open actions across every Team you're in, attributed to their owner; pass team_id to narrow to one Team. Pass goal_id to keep only Actions for confirmed people in that Goal; a Team sweep with goal_id reads the Team that owns the Goal. Use this to sweep all your to-dos (e.g. "what are all my open actions?") instead of calling get_person per person. Pass undated:true to see only the open-ended ones (no remind_at). Optionally scope to one person_id or cap the count with limit. Snoozed actions are excluded until they resurface. Read-only — for one person's actions use get_person → relationship.actions.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_actions"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Max actions to return (bounded). Omit for all.
`scope`	No	'own' (default) — your open actions. 'team' — consent-gated open actions across a Team.
`goal_id`	No	Only Actions for confirmed people in this Goal (the id from list_lists/get_list). For scope:'team', the Goal must belong to the selected Team.
`team_id`	No	For scope:'team' — one team's team_id from account_status.teams. Omit it to read every team you're in.
`undated`	No	Only actions with no remind_at (open-ended follow-ups). Omit for all open actions.
`person_id`	No	Scope to one person's open actions (their id from search_people / get_person).

Output Schema

Name	Required	Description
`ok`	Yes	Whether noticed completed the operation.
`data`	No	The operation result when ok is true.
`error`	No	A human-readable error when ok is false.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 3, 2026

changedInput schema / properties / team_id / description

Previous value: -"For scope:'team' — the team_id from account_status.teams. Optional when you belong to exactly one team; required otherwise."New value: +"For scope:'team' — one team's team_id from account_status.teams. Omit it to read every team you're in."

Changed1 schema field changedNov 3, 2026

changedInput schema / properties / team_id / description

Previous value: -"For scope:'team' — the organizationId from account_status.teams. Optional when you belong to exactly one team; required otherwise."New value: +"For scope:'team' — the team_id from account_status.teams. Optional when you belong to exactly one team; required otherwise."

Changed1 schema field changedAug 22, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": true,
+  "properties": {
+    "data": {
+      "additionalProperties": true,
+      "description": "The operation result when ok is true.",
+      "properties": {
+        "actions": {
+          "items": {
+            "additionalProperties": true,
+            "properties": {
+              "action_id": {
+                "type": "string"
+              },
+              "id": {
+                "type": "string"
+              },
+              "person_id": {
+                "type": "string"
+              },
+              "remind_at": {
+                "type": [
+                  "string",
+                  "null"
+                ]
+              },
+              "status": {
+                "type": "string"
+              },
+              "title": {
+                "type": "string"
+              }
+            },
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "total": {
+          "type": "number"
+        }
+      },
+      "required": [
+        "actions",
+        "total"
+      ],
+      "type": "object"
+    },
+    "error": {
+      "description": "A human-readable error when ok is false.",
+      "type": "string"
+    },
+    "ok": {
+      "description": "Whether noticed completed the operation.",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "ok"
+  ],
+  "type": "object"
+}

First observedAug 22, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint/idempotentHint, so the safety profile is covered; the description goes further by disclosing result ordering (soonest remind_at first, undated last), an exclusion rule (snoozed actions are withheld until they resurface), and that team scope is consent-gated and attributed to owners. What it does not cover is failure behavior when consent is missing or how bounded 'limit' truncation is signalled, which keeps it short of a 5.

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?

It is front-loaded with the primary use case and the result shape, then walks parameters in a logical order with no filler sentences. It is dense and long-ish for a list tool, and the team/goal interaction sentence is packed enough to require a second read, which costs it a point.

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 six-parameter, zero-required filtered list tool with a full output schema and complete annotations, the description covers scope selection, narrowing, exclusions, ordering, and the sibling alternative. Nothing an agent needs in order to call this correctly is missing.

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%, so the baseline is 3, and the description genuinely adds cross-parameter meaning the schema does not: omitting team_id reads every team, and with a Team sweep the goal_id must belong to the Team that owns the Goal. It also clarifies that goal_id filters to confirmed people only, which is a semantic constraint beyond the field's own text.

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?

The description opens with a specific verb and resource — every open follow-up/action across the whole network — and states the shape of the result (each attached to its person). It explicitly contrasts itself with the sibling get_person, so an agent can separate the network-wide sweep from the per-person read without inspecting either schema.

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?

It gives an explicit when-to-use rule ('use this to sweep all your to-dos ... instead of calling get_person per person') and an explicit when-not with the alternative ('for one person's actions use get_person → relationship.actions'). The scope/team_id/goal_id/undated/person_id paths are each framed as conditional refinements, so the agent knows which knob selects which behavior.

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

All noticed 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.

Resources

Need Help?