Skip to main content
Glama

Search records

search_records
Read-only

List/filter records of any object type. The right tool for a plain LIST — open tasks, deals in a stage, tasks for one person, contacts at an account — before run_report (counts, sums, grouping, trends, charts). Pass object_type and optional filters (field key → exact value; relationship fields filter by target id; e.g. object_type:"task" with filters:{status:"open"}, object_type:"opportunity" with filters:{stage:"proposal", open_only:true}). Optional free-text query searches by NAME/text on the built-in objects that support it (account, contact, opportunity, lead, task, touch, meeting); for activity (object_type:"touch") it ALSO searches stored EMAIL CONTENT and PARTICIPANT addresses (sender/recipient, attendees), so "sally@acme.com", "kayode" or "acme.com" finds the activity that reached that person. Keyset-paginated, default 20 rows (limit 1–100): pass next_cursor back as cursor. Order varies by object — most newest first, tasks by due date ascending (undated last). Every object type answers in ONE shape: the rows are the top-level records array beside count, object_type, next_cursor, has_more and search_coverage (a built-in object's nested result is retained one release, same rows). Works for custom AND built-in objects (routing to the typed search — its filter keys apply; query is ignored, with a note, where unsupported). For deals of a given TYPE use object_type:"opportunity" with filters:{type:"renewal", open_only:true}; the type as object_type (e.g. "renewal") auto-routes there. Opportunity rows carry each account's reply-recency (account_last_inbound_at / account_last_touch_at), so 'open renewals with no reply in N days' is one call. Unknown or unsupported filter keys/values are IGNORED (echoed in ignored_filters + a note) with search_coverage.status='unsupported_query': those rows DO NOT answer the original query — correct the inputs before claiming matches or none. search_coverage also distinguishes a complete result from one page; follow every next_cursor for an exhaustive answer. An unknown object_type returns the valid types. Unified work queue: object_type:'task', projection:'actions' — sequence steps included, reminder tasks deduplicated, exact counts plus paged rows; filters scope (mine/team/all; assignment, not book), bucket (due/upcoming/paused/completed/all), channel (email/call/linkedin/other), source (task/sequence), sequence or owner UUID, day (YYYY-MM-DD), time_zone (IANA), timed_only. Use each row's taskId/enrollmentId for writes, never its projection id. Nothing is sent.

When to use: Find records of any object (built-in, meeting, or custom). The right tool for a plain list — open tasks, deals in a stage — before reaching for run_report. Filter by field value; keyset-paginated, 20 rows by default; every object type answers with the rows in a top-level records array beside search_coverage. A free-text query searches by name on the objects that support it; for touches it also full-text-searches stored email CONTENT and matches a participant email ('find the emails about X', 'find the emails to sally@acme.com'; matches carry a highlighted snippet).

Example: Find the emails to sally@acme.com.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoPage size, 1–100 (default 20). Out-of-range values are clamped.
queryNoFree-text search. Matches names + (for touch/activity) email subject/summary, stored email body content, and participant addresses. Object types without free-text search ignore it (noted in the result).
cursorNoOpaque keyset cursor: pass the previous page's next_cursor to fetch the next page; omit for the first page (a stale or invalid cursor restarts from page one).
filtersNoField key → exact scalar value (string / number / boolean). Non-scalar values can't be matched and are ignored with a note.
projectionNoRead-only unified Actions queue, for object_type task.
object_typeYesObject key to list — a built-in (account, contact, opportunity, task, touch, meeting, report…), a custom object's key, or an opportunity type key such as renewal (auto-routed).

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteNo
countNo
totalNo
countsNo
resultNo
recordsNo
has_moreNo
projectionNo
next_cursorNo
object_typeNo
ignored_filtersNo
search_coverageNo
custom_field_definitionsNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnly/non-destructive, but the description goes well beyond them: keyset pagination with cursor semantics, default 20 rows, ordering variation by object (tasks by due date, undated last), ignored filters echoed in `ignored_filters` with search_coverage.status='unsupported_query', and the explicit warning that such rows do not answer the original query. It also states 'Nothing is sent', confirming no side effects.

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

Conciseness2/5

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

The purpose line is front-loaded, but the body is a dense ~450-word block followed by a 'When to use' paragraph that restates the same facts (plain list before run_report, keyset pagination, 20 rows default, top-level `records` array, touch email search). Whole clauses are near-duplicated, forcing the reader to parse the same routing rule twice.

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?

Output schema exists so return values need not be explained, yet the description still covers the response shape, edge cases (unknown object_type returns valid types), the deprecated nested `result` retention, and exhaustive-answer guidance via next_cursor. For a 6-parameter, nested, multi-mode tool this is complete.

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

Parameters5/5

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

Schema coverage is 100%, so 3 would be the baseline, but the description adds real meaning: relationship fields filter by target id, opportunity type keys auto-route from object_type, `query` semantics differ per object (name match vs touch email-body/participant match), and projection:'actions' carries its own filter vocabulary (scope/bucket/channel/source/day/time_zone). That is substantive semantics the schema alone does not convey.

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?

Opens with a specific verb+resource+scope ('List/filter records of any object type') and immediately distinguishes itself from the sibling run_report by naming what run_report does (counts, sums, grouping, trends, charts). An agent can tell search_records apart from get_record and run_report 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?

States when to reach for this tool ('The right tool for a plain LIST — open tasks, deals in a stage') and when not to (before run_report for aggregates). The dedicated 'When to use' section plus worked conditions (custom vs built-in, deal-by-type routing, unified actions queue) leave little to inference.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources