noticed

add_note

Idempotent

Write a NOTE on a person's record — content the USER gave you. Use this whenever they ask you to remember, note, or jot something down about someone ("remember Rita prefers async", "note that Ana is hiring"), or when you're transcribing what they told you. The note is theirs; you're just the keyboard. If YOU worked something out on your own that they never told you, that's a memory — use add_memory. @mention a name in content to link someone in your network. Read them back via get_person (relationship.notes).

Input Schema

TableJSON Schema

Name	Required	Description
`tags`	No	Optional tags.
`content`	Yes	The note, in the user's words. @mention a name in your network to link them.
`person_id`	Yes	The person this note is about.
`occurred_at`	No	The date this note REFERS to, if different from now (ISO timestamp). Omit to anchor to write time. Use when recording a past event, e.g. 'met at conference last week'.
`captured_via`	No	The skill capturing this — pass the active skill's slug (e.g. 'add-person', 'event-debrief') when a skill is driving the write; omit for an ad-hoc note.

Output Schema

TableJSON 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. Dates show when Glama detected each change.

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": {},
+      "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=false and destructiveHint=false, setting the write-safety profile. The description adds behavioral context: 'The note is theirs; you're just the keyboard' clarifies authorship, and 'Read them back via get_person' explains how the note is retrieved. It does not contradict annotations and adds useful nuance beyond the schema.

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?

The description is slightly longer than minimal but every sentence adds value: examples, differentiation, and omission guidance are all present. It front-loads the primary action and uses plain language, making it easy to parse without wasted words.

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?

Given the tool's moderate complexity, full schema coverage, and an existing output schema signal, the description covers when to use it, how to anchor data (occurred_at), how to link people (@mention), and how to retrieve notes. No critical guidance is missing for correct invocation.

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 all params are documented, but the description enriches meaning: it explains @mention usage in content, clarifies occurred_at as the date the note refers to with a practical example, and specifies captured_via for skill-driven writes. This exceeds the baseline of 3 by adding usage context.

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 clearly states 'Write a NOTE on a person's record' with a specific verb and resource, and explicitly differentiates from add_memory by contrasting user-provided content versus agent-derived reasoning. The examples ('remember Rita prefers async') make the scope unambiguous.

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 explicit when-to-use: 'whenever they ask you to remember, note, or jot something down' and when-not-to-use: 'If YOU worked something out on your own... use add_memory.' It also mentions alternative read-back via get_person, covering the full usage lifecycle.

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

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

B3.4/5.0

Disambiguation3/5

The tool set is organized around distinct resources, and the descriptions work hard to separate them, but several close pairs remain easy to confuse: add_memory vs memory_save vs add_note, accept_identity_match vs suggest_identity_match, and dismiss_identity_match vs mark_different_people. An agent will often need to read very subtle signals (who originated the content, pending vs initiating a merge, soft vs durable rejection) to pick the right tool.

Naming Consistency3/5

Most tools follow a clear verb_noun snake_case pattern like create_list, update_person, and delete_view, which is readable and mostly predictable. However, the memory tools break the pattern (memory_save, memory_get, memory_search instead of save_memory/get_memory/search_memory), and a few noun-style names (my_profile, network_summary, account_status) add inconsistency.

Tool Count1/5

At 57 tools, this is an extremely large surface that exceeds the calibration threshold for an extreme mismatch. The scope is broad, but many tools are micro-specialized variations of the same concept, such as four memory-related tools and seven identity-match tools, which makes the count feel inflated rather than well-scoped.

Completeness4/5

The tool set provides thorough lifecycle coverage for the core domain: people can be added, updated, searched, and removed; lists, views, actions, and scheduled tasks have create/read/update/delete; and identity matching has accept, dismiss, differentiate, and suggest paths. Minor gaps exist, such as no direct memory/note deletion or intro deletion, but agents can generally complete workflows without hitting dead ends.

Resources

Need Help?