Skip to main content
Glama

Query CRM tasks

query_crm_tasks
Read-only

The follow-ups Sliq suggested to the user (the Tasks view's suggested follow-ups, waiting for the user to add or dismiss them) come only with status='suggested', and the ones they dismissed only with 'dismissed', newest dismissal first; both cover only the user's own suggestions. A suggestion's data.trigger says why Sliq made it: 'stalled_conversation' (the person went quiet after the user's last message), 'follow_up_requested' (they asked to be contacted later) or 'stage_stalled' (its deal has sat in one stage too long). Dict with paging info and the tasks page. {total, has_more, tasks: [{id, title, notes, due_at, status, completed_at, assignee_email, person_profile_id, company_profile_id, deal_id, person_profile, company_profile, deal (the linked deal, or null; its open_task_count and next_task aren't filled in here — use query_deals for those), data, created_at, archived_at}]}.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "query_crm_tasks"
  }
}

Input Schema

NameRequiredDescriptionDefault
qNoText match on the task title, or the linked contact, company, or deal name.
limitNoMax tasks (default 25, capped at 200).
offsetNoTasks to skip for paging; re-call with offset += limit while has_more is true.
statusNo'open' (default), 'done', 'all' (open and done), 'suggested' or 'dismissed'.open
deal_idNoOnly tasks on this deal.
person_idNoOnly tasks linked to this person (a query_people `id`).
company_idNoOnly tasks linked to this company (a query_companies `id`).
due_beforeNoOnly tasks due before this day (YYYY-MM-DD). For "overdue" pass today.
on_behalf_ofNoA teammate's email, or an agency client's from list_agency_clients, to run this call in that account: their agents, settings, connected accounts, and credits. Omit it to act on your own account.
assignee_emailNoOnly tasks assigned to this teammate (ignored for 'suggested' and 'dismissed', which cover only the user's own). For "my tasks" pass the user's own email.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / on_behalf_of / description
      Previous value: -"An agency client's email, from list_agency_clients, to run this call in that client's account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."New value: +"A teammate's email, or an agency client's from list_agency_clients, to run this call in that account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."
  2. Changed3 schema fields changed
    • changedInput schema / properties / assignee_email / description
      Previous value: -"Only tasks assigned to this teammate. For \"my tasks\" pass the\nuser's own email."New value: +"Only tasks assigned to this teammate (ignored for 'suggested' and\n'dismissed', which cover only the user's own). For \"my tasks\" pass the user's own\nemail."
    • changedInput schema / properties / status / description
      Previous value: -"'open' (default), 'done', or 'all' (open and done)."New value: +"'open' (default), 'done', 'all' (open and done), 'suggested' or 'dismissed'."
    • changedInput schema / properties / status / enum
      Previous value: -[
      -  "open",
      -  "done",
      -  "all"
      -]New value: +[
      +  "open",
      +  "done",
      +  "suggested",
      +  "dismissed",
      +  "all"
      +]
  3. Changed1 schema field changed
    • addedInput schema / properties / on_behalf_of
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ],
      +  "default": null,
      +  "description": "An agency client's email, from list_agency_clients, to run this call in that client's account: their agents, settings, connected accounts, and credits. Omit it to act on your own account."
      +}
  4. Added

TDQS

A4.2/5.0
Behavior3/5

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

readOnlyHint=true already tells the agent this is a safe read, and the description adds genuinely useful context: tasks are shared across the team, sort order, and that suggestions cover only the user's own with 'newest dismissal first'. The data.trigger enumeration ('stalled_conversation', 'follow_up_requested', 'stage_stalled') explains field values rather than behavior, and no rate limits or empty-result behavior are noted, so it sits above baseline without being rich disclosure.

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-loaded with purpose, ordering, and use cases, then scoped caveats, then a returns block. The pseudo-XML tags and the two-sentence aside about trigger values are slightly verbose but the content is dense and non-redundant.

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?

With 10 parameters and no output schema, the description compensates by enumerating the returned dict's keys and explicitly flagging which nested deal fields are null here. An agent has enough to call it correctly and interpret the response without a follow-up query.

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 coverage is 100%, so the schema already documents paging, enum values, and filter semantics. The description's contribution beyond the schema is largely the suggestion/dismissal scope and trigger meanings, which relate more to returned data than to parameter usage.

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 and resource ("List CRM tasks (the Tasks view)") plus ordering semantics (earliest due first, undated last). It also distinguishes itself from the mutation siblings by naming update_crm_task as a downstream consumer of the ids returned here.

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 phrases ("what's on my plate", "what's overdue", "what's next with Acme") and states the prerequisite for update_crm_task. It further scopes the status='suggested'/'dismissed' modes and redirects to query_deals for deal-level fields not populated here.

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