Skip to main content
Glama
Sign In

Connections

by icu.connections
OverviewDiscussionsAdmin

Search my notes

connections_notes_search
Read-only

Use this when the member asks what they wrote, saved or noted about something, to find a note, or to see their recent notes. Returns notes from the member's Connections workspace - plain notes, open questions and saved prompts, but never the to-do list (use connections_todo_list for tasks, reminders and follow-ups instead). Each row carries its id, a short preview of its content, its labels and a link to open it; pass the id to connections_note_get to read the whole note. With no query, returns the most recently touched notes; with a query, returns the best keyword matches over the title, body and labels.

Input Schema

NameRequiredDescriptionDefault
labelNoOptional: only notes carrying this label/folder.
limitNoMax notes to return (1-100, default 20).
queryNoOptional keyword search over the note's title, body and labels. Omit this to list recent notes instead.
detailNocompact (default) = the fields needed to answer most questions. full = every field this search call carries for the note.
fieldsNoOptional explicit field projection over each row; wins over `detail` when given.
offsetNoPagination offset, default 0.
personNoLinked person to run this call as (first name). Omit to run as the connection's holder.
projectNoWorkspace to run this call in (id or name).

Schema Changelog

Changes observed during successful MCP inspections.

  1. 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"
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / project
      Added value: +{
+  "description": "Workspace to run this call in (id or name).",
+  "type": "string"
+}
  3. Changed1 schema field changed
    • addedInput schema / required
      Added value: +[]
  4. Added

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already cover safety (readOnlyHint true, destructiveHint false, closed world), so the description focuses on what annotations cannot say: the returned row shape (id, preview, labels, link), the contents excluded from results, and the query-vs-no-query behavior with default recency ordering. That is meaningful disclosure beyond structured fields.

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?

Front-loads the trigger condition, then scope, then return shape, then query semantics — a logical order for an agent to read. Three sentences, no filler, and every clause carries decision-relevant information.

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?

No output schema exists, but the description compensates by describing exactly what each row contains and how to expand a row into the full note. For an 8-parameter search tool with full schema coverage and safety annotations, nothing an agent needs in order to call it 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 schema already defines every parameter and the baseline of 3 applies. The description adds a little beyond it — that queries match over title, body and labels and that omitting the query yields recently touched notes in recency order — but it says nothing about label, limit, detail, fields, offset, person or project, so it does not exceed the schema's own coverage.

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 ('search' notes) and immediately bounds the scope: plain notes, open questions and saved prompts, explicitly excluding the to-do list. That boundary, plus the named sibling connections_todo_list, lets an agent distinguish it from connections_note_get and connections_todo_list without opening any 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 concrete triggering conditions ('when the member asks what they wrote, saved or noted', 'to find a note', 'to see their recent notes') and an explicit exclusion with the alternative to use instead. It also states the follow-up path: pass the id to connections_note_get to read the whole note.

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