Skip to main content
Glama
Sign In

Connections

by icu.connections
OverviewDiscussionsAdmin

Log a note on a contact

connections_contacts_log
Destructive

Use this when the member says they talked to, met or called someone and wants it kept on that person's record - "log a coffee with Sam", "note that Avery wants an intro to Dana". Pass the contact as id (from connections_contacts_list) or as name, with email to tell two people of the same name apart. Adds one note to the contact's timeline, dated now unless occurred_at is given, and returns the recorded touch. It only ever writes to the member's own contacts. A name that fits more than one contact writes nothing and returns the candidates to choose from. Needs the contacts:write scope.

Input Schema

NameRequiredDescriptionDefault
idNoThe contact id from connections_contacts_list. Use this when you have it.
nameNoThe contact's name, when you do not have the id. An ambiguous name writes nothing and returns candidates.
noteYesWhat happened, in the member's words (up to 4000 characters).
emailNoThe contact's email, to tell apart two contacts who share a name.
personNoLinked person to run this call as (first name). Omit to run as the connection's holder.
channelNoHow it happened (default note).
projectNoWorkspace to run this call in (id or name).
occurred_atNoWhen it happened, ISO-8601 with an offset (default: now).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / occurred_at / pattern
      Added value: +"^\\d{4}-\\d{2}-\\d{2}(T\\d{2}:\\d{2}(:\\d{2}(\\.\\d{1,9})?)?(Z|[+-]\\d{2}:?\\d{2})?)?$"
  2. Changed1 schema field changed
    • addedInput schema / properties / person
      Added value: +{
+  "description": "Linked person to run this call as (first name). Omit to run as the connection's holder.",
+  "type": "string"
+}
  3. Changed1 schema field changed
    • addedInput schema / properties / project
      Added value: +{
+  "description": "Workspace to run this call in (id or name).",
+  "type": "string"
+}
  4. Added

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses that exactly one note is appended, that it is dated now unless occurred_at is supplied, that an ambiguous name writes nothing and returns candidates, that it returns the recorded touch, and that contacts:write scope is required. These are exactly the failure modes and permission requirements an agent needs before calling a write tool.

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-loads the trigger before the mechanics, and each sentence carries distinct information (trigger, parameter routing, write semantics, ambiguity, scope). Slight redundancy with the schema on id/email disambiguation keeps it off a 5.

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 an 8-parameter, single-required write tool with no output schema, the description covers the return value, the ambiguous-match behavior, the default timestamp, and the required scope. Nothing an agent needs to invoke it correctly is missing.

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 every parameter is already documented in the schema. The description restates the id-from-list and name/email disambiguation rules and the occurred_at default, adding only marginal meaning. Baseline 3 applies — it does not explain person, project, or channel beyond the schema.

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 — adds one dated note to a contact's timeline — and grounds it in the member's own phrasing ("log a coffee with Sam"). The scope line "only ever writes to the member's own contacts" separates it from the broader note and people tools in the sibling list.

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?

"Use this when the member says they talked to, met or called someone and wants it kept on that person's record" is an explicit trigger, and it names connections_contacts_list as the place to get the id. It stops short of saying when to prefer connections_note_save or connections_intel_remember_about_person instead, so there is no exclusion set.

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

All Connections toolsInspect
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