Skip to main content
Glama
ohneben

ActiveCampaign MCP

create_match_all_request_with_segment_id

Read-onlyIdempotent

Starts a match-all request for a given segment to find all contacts matching its criteria. Returns results if ready within 4 seconds, otherwise provides a runId to check later.

Instructions

🟢 READ-ONLY · query · Segments · GET /api/3/segmentMatchAll/{segmentId}

Create a Match All Request

Runs a search/report (a POST that returns data). Changes no account records; may create a short-lived, cached result-set.

A new match-all request will be initiated. If results are not ready within 4 seconds, a response that lacks a result-set will be returned and the response's is_ready attribute will be equal to false. Use the returned segmentId and runId to poll and check back later to see if the result-set is ready

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage Number1
sortNoComma delimited list of fields for which to sort the results. Optionally prepended with a dash sign to indicate descending order. Allowed fields: id, email, phone, first_name, last_name, full_name, cdate, udate, account_name, score, score<score-id>. The score<score-id> option will sort off of the value of a particular score. Examples: "email", "-phone", "score2", "last_name,-first_name"id
instantNoIf present, API will return instantly with a runId without waiting for up to 4 seconds for the results to be ready. Useful if you want to kick off a match-all request but don't need the results immediately
page_sizeNoPage Size. Maximum: 10,00020
segmentIdYesA segment id
Behavior5/5

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

Annotations (readOnlyHint, idempotentHint, destructiveHint) are already present, but the description adds valuable context: may create a short-lived cached result-set, the instant vs wait behavior, and the need to poll with runId. This fully discloses the tool's non-standard behavior.

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?

The description is fairly concise and front-loaded with key info (read-only, path, summary). It uses emoji and formatting, which may slightly reduce conciseness but aids clarity. Each sentence adds value, though the polling explanation could be tightened.

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?

Given the complexity and absence of an output schema, the description adequately covers the polling mechanism, caching, and the instant parameter. It could mention potential error states or limits, but it's sufficient for a tool that returns data with a possible delay.

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 description does not need to explain parameters. It does add context for the 'instant' parameter (returns immediately) and mentions using segmentId and runId for polling, but this is consistent with the schema descriptions. Baseline 3 is appropriate.

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?

The description clearly states the tool's action: 'Create a Match All Request' and explains it runs a search/report that returns data. It distinguishes itself by name from the sibling create_match_all_request, though not explicitly in the description. The emoji and path prefix further clarify it's a read-only query.

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?

The description advises using this tool to initiate a match-all request and provides polling guidance when results aren't ready. However, it does not explicitly contrast with create_match_all_request or state when NOT to use it. The guidance is clear but incomplete for exclusion cases.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ohneben/ActiveCampaign-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server