noticed

log_interaction

Record a touchpoint — say WHAT it was with type: 'in_person', 'call', or 'message'. Everything else is optional detail that defaults sensibly. Builds the relationship timeline and feeds recency and relationship strength. Each call appends a new event. Works on any search_people hit — if they're not in your network yet, they're added first. NOT for notes — a note about someone is a memory, so use add_memory instead.

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": {
      "person_id": "<person_id>",
      "type": "<type>"
    },
    "name": "log_interaction"
  }
}

Input Schema

Name	Required	Description
`tags`	No	Event/context tags for THIS touchpoint — WHERE / WHEN you met: an event, a place, a trip (e.g. 'friendly-machines-2026', 'event:agents-day', 'berlin'). Put them here, on the interaction, not on the person — they describe the meeting, not a durable trait, and are surfaced back on the person view as aggregated context. Use update_person's tags only for lasting traits of the person.
`type`	Yes	What the interaction was: 'in_person' (you were physically together), 'call' (a live conversation — phone or video), or 'message' (an asynchronous written exchange).
`format`	No	Group size, for in_person and call only — 'one_to_one' (default) or 'group'. A group counts for less than a 1:1. A message has no size.
`channel`	No	Where it happened. For a call: 'phone' (default) or 'video'. For a message: 'email' \| 'linkedin' \| 'x' \| 'whatsapp' \| 'sms'. Not used for in_person.
`payload`	No	Optional freeform details (e.g. { topic: 'fundraising' }).
`direction`	No	Messages only — 'outbound' (you sent it) or 'inbound' (they sent it). Set it whenever you know; it is what lets a real back-and-forth be told apart from a message that was never answered. Omit it when you genuinely don't know: the message is still recorded and still counts, it just carries no direction verdict. Never guess. A call or an in-person meeting is a two-way event and carries no direction.
`person_id`	Yes	The person this interaction is with.
`occurred_at`	No	When it HAPPENED (ISO timestamp) — resolve relative dates like 'yesterday' to a timestamp. Omit → defaults to now. Pass null only when a past interaction's date is genuinely unknown — the timeline then shows only when it was recorded.

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

Previous value: -"When it HAPPENED (ISO timestamp). Omit → defaults to now. Pass null for undated items (e.g. open-ended follow-ups) — the timeline then shows only when it was recorded."New value: +"When it HAPPENED (ISO timestamp) — resolve relative dates like 'yesterday' to a timestamp. Omit → defaults to now. Pass null only when a past interaction's date is genuinely unknown — the timeline then shows only when it was recorded."

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.4/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), but the description adds meaningful behavior beyond them: 'Each call appends a new event' (explains the non-idempotent consequence — duplicates if re-called), the implicit network-insert side effect, and downstream effects on 'recency and relationship strength'. It stops short of describing the response or failure modes, but for a low-risk append tool this is substantial added context.

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

Conciseness5/5

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

Five short sentences, front-loaded with the core action and the required discriminator first, then consequences, then the precondition, then the exclusion last. Nothing is redundant with the schema and no sentence is filler.

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?

With 8 params at full schema coverage, an output schema present, and annotations declaring the safety profile, the remaining burden on the description is purpose, side effects, and sibling routing — all of which it covers. Only the response shape and behavior on invalid person_id are unaddressed, which the output schema partly absorbs.

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 description coverage is 100%, so per-parameter semantics are fully carried by the schema itself. The description adds only the framing that `type` is the one thing you must decide and 'everything else is optional detail that defaults sensibly', which is mild but genuine guidance on minimal invocation. Baseline 3 is correct given the schema already documents defaults, enums, and field interactions in depth.

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 ('Record a touchpoint'), names the discriminator field (`type` with its three enum values), and explicitly distinguishes itself from the nearest sibling: 'NOT for notes ... use add_memory instead.' An agent can identify and separate this tool from add_note/add_memory without opening a 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?

Gives when-to-use ('Record a touchpoint'), when-not-to-use ('NOT for notes'), and the named alternative ('use add_memory instead'). It also states a precondition-free entry point ('Works on any search_people hit — if they're not in your network yet, they're added first'), so an agent knows it needn't call add_to_network first.

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?