CRM Connector

Search tasks across all records

search_tasks

Read-onlyIdempotent

AI Agents (inside one system): Use to find tasks across a whole AI agent's system, such as every open task or what one user still has to do. Not for the tasks of one record you already know (use list_related_records). Where a task names the contact it is on, update_task needs that contact.

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": {
      "system": "<system>"
    },
    "name": "search_tasks"
  }
}

Input Schema

Name	Required	Description
`done`	No	True for finished tasks only, false for open tasks only; both when left out.
`text`	No	Words the task has to hold.
`limit`	No	How many to return per page, 1 to 100.
`users`	No	Only the tasks of these users, by the ids describe_record_type gives with include users.
`cursor`	No	The cursor of the previous answer, to read the next page.
`system`	Yes	Which AI agent: the system's id from get_ai_agent_options, or the name of the system or its connection. Ask the person which AI agent they mean unless they named it in this conversation; never pick one yourself.
`contacts`	No	Only the tasks on these contacts, by their ids.

Output Schema

Name	Required	Description	Default
`notice`	Yes
`result`	Yes
`status`	Yes
`systemId`	Yes
`operation`	Yes
`truncated`	Yes
`systemName`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 5, 2026

changedInput schema / properties / system / description

Previous value: -"Which AI agent: the system's id from get_ai_agents_info, or the name of the system or its connection. Ask the person which AI agent they mean unless they named it in this conversation; never pick one yourself."New value: +"Which AI agent: the system's id from get_ai_agent_options, or the name of the system or its connection. Ask the person which AI agent they mean unless they named it in this conversation; never pick one yourself."

AddedOct 30, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so safety needs no restatement. The description adds cross-tool context the annotations cannot: the downstream dependency that update_task requires the contact when a returned task names one. It does not discuss paging behavior, but cursor/limit are schema-documented and an output schema exists.

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?

Three short sentences, front-loaded with the tool's scope before the exclusion and the prerequisite. The closing update_task note is a slight detour from search semantics but is short and useful, so nothing is genuinely wasted.

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?

For a 7-parameter read-only search with full schema coverage, annotations, and an output schema, the description covers scope, the sibling alternative, and a downstream constraint. Pagination workflow is only implicit via the cursor parameter, which keeps it from being fully self-contained.

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, and the description only weakly signals filters ("open task" for done, "one user still has to do" for users). It adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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 ("find tasks") scoped to "a whole AI agent's system" and gives concrete examples ("every open task or what one user still has to do"). It explicitly distinguishes itself from list_related_records, so an agent can separate the two without opening either 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?

Provides an explicit when-not rule with the named alternative ("Not for the tasks of one record you already know (use list_related_records)"), plus a prerequisite chain (task names the contact -> update_task needs that contact). The routing decision is fully determined by the text.

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

All CRM Connector 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?