customerio_get_customer_segmentsList the segments a single person belongs to. App API: GET /v1/customers/{customer_id}/segments.
| Name | Required | Description | Default |
|---|---|---|---|
| customer_id | Yes | The person's id. |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the per-customer scope and exact GET endpoint, but doesn't mention response format, empty results, or pagination behavior; with readOnly covered, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences; the first states behavior and scope, the second the exact endpoint. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only lookup with full schema coverage and readOnlyHint, the description plus schema leave no critical gap for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema describes customer_id as 'The person's id' and coverage is 100%, so the schema carries the parameter definition. Description merely reinforces the person context and endpoint placeholder; no additional format or lookup guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('List') and resource ('segments') constrained to a single person, and names the exact API endpoint. The 'single person' qualifier distinguishes it from sibling customerio_list_segments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear that this is for segment membership of one person, not a general segment catalog. However, it does not explicitly name the sibling alternative (customerio_list_segments) or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool maps to a distinct resource and action: campaign, customer, segment, message, collection, export, or send. The potentially similar pairs like list_messages/get_customer_messages and list_segments/get_customer_segments are clearly differentiated by workspace-wide vs per-customer scope.
All tools consistently use a customerio_ prefix with verb_noun snake_case naming. get_ is used for single-resource operations, list_ for collections, and send_/trigger_ for actions, creating a predictable pattern.
13 tools is well within the ideal range for an API integration and each tool represents a meaningful endpoint. There is no obvious redundancy or padding; campaigns, customers, messages, segments, collections, exports, and sends all have coverage.
The surface is solid for reading Customer.io data and triggering sends, but it lacks common lifecycle operations like creating/updating/deleting customers, tracking events, or listing transactional templates. These are notable gaps that can force agents to rely on out-of-band IDs for send workflows.