noticed

create_list

Create a list — a described set of people (e.g. 'Seed investors', 'Design candidates'). The description is REQUIRED and is the goal noticed matches people against, so write it specifically ('pre-seed investors who back dev tools in Europe'): AI suggestions are off by default. Set ai_enabled=true to have noticed propose people from the network to add, which the user confirms or rejects. The title is auto-generated from the description unless you pass a name. Returns the new list_id.

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": {
      "description": "<description>"
    },
    "name": "create_list"
  }
}

Input Schema

Name	Required	Description
`name`	No	Short title for the list; auto-generated from the description when omitted.
`ai_enabled`	No	Whether noticed suggests people for this list (default false).
`description`	Yes	What the list is FOR, in the user's words — the goal noticed matches people against. REQUIRED. Be specific; a vague description means vague suggestions.
`organization_id`	No	Creates a TEAM list owned by that Team (its team_id from account_status.teams). Omit for a personal list.

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 / organization_id / description

Previous value: -"Creates a TEAM list owned by that organization (from account_status.teams). Omit for a personal list."New value: +"Creates a TEAM list owned by that Team (its team_id from account_status.teams). Omit for a personal list."

Changed3 schema fields changedSep 15, 2026

addedOutput schema / properties / data / properties / canonical_url
```
Added value: +{
+  "format": "uri",
+  "type": "string"
+}
```
addedOutput schema / properties / data / properties / review_url
```
Added value: +{
+  "format": "uri",
+  "type": "string"
+}
```

changedOutput schema / properties / data / required

Previous value: -[
-  "list_id",
-  "name"
-]New value: +[
+  "list_id",
+  "name",
+  "canonical_url",
+  "review_url"
+]

Changed1 schema field changedSep 11, 2026

changedInput schema / properties / ai_enabled / description

Previous value: -"Whether noticed suggests people for this list (default true)."New value: +"Whether noticed suggests people for this list (default false)."

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": {
+        "ai_enabled": {
+          "type": "boolean"
+        },
+        "description": {
+          "type": [
+            "string",
+            "null"
+          ]
+        },
+        "list_id": {
+          "type": "string"
+        },
+        "member_count": {
+          "type": "number"
+        },
+        "name": {
+          "type": "string"
+        },
+        "organization_id": {
+          "$ref": "#/properties/data/properties/description"
+        },
+        "pending_count": {
+          "type": "number"
+        }
+      },
+      "required": [
+        "list_id",
+        "name"
+      ],
+      "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

A3.6/5.0

Behavior3/5

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

Annotations already declare this is a non-readonly, non-destructive, non-idempotent, closed-world creation call. The description adds genuine behavior beyond that: the description field is REQUIRED and drives matching quality, AI suggestions default to off, proposed people require user confirmation, and the call returns a new list_id. These are useful additions, but deletion/cleanup implications and duplicate-name behavior remain unstated.

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 operation and resource, then the required-description rationale, then optional behaviors, then the return value. It is dense and parenthetical but every sentence carries information; minor redundancy between the description text and schema wording on ai_enabled.

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

Completeness4/5

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

An output schema exists, so the brief 'Returns the new list_id' is sufficient rather than required. For a four-parameter creation tool with full schema coverage and clear annotations, the description covers the decision-relevant behavior; only cross-tool placement (list vs view) is left implicit.

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

Parameters3/5

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

Schema coverage is 100%, so the schema already documents all four parameters, including that name is auto-generated and organization_id omits to a personal list. The description reinforces the two key ones (description as the matching goal, ai_enabled default) but adds little semantic detail the schema does not already carry, so it sits at the baseline.

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

Purpose4/5

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

Opens with a specific verb+resource ('Create a list') and immediately defines the resource as 'a described set of people', with concrete examples ('Seed investors', 'Design candidates'). It is clear against add_to_list/update_list/delete_list, though it never contrasts itself with the adjacent create_view, so full sibling differentiation is not established.

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

Usage Guidelines4/5

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

Gives actionable conditions: write a specific description because it is what matching uses, and set ai_enabled=true only if you want proposed people that the user confirms or rejects. It omits guidance on when a list is preferable to a view or when to pass organization_id for team vs personal lists, so there is no explicit when-not.

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?