Export all user profiles in a Braze segment as an async job, with optional fields and zip/gzip output. Use it to retrieve audience data for analysis or backup.
Export all user profiles in a segment (async job).
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | Braze REST API key | |
| segment_id | Yes | Segment ID to export | |
| restEndpoint | No | Braze REST endpoint URL | |
| output_format | No | ||
| fields_to_export | No | ||
| callback_endpoint | No | Webhook URL for completion |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It notes the async nature, which is useful, but doesn't mention authentication requirements, rate limits, how completion is signaled (the callback_endpoint param implies this but isn't explained), or that this may take time. For a mutation/export tool with zero annotation coverage, this is thin.
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?
One tight sentence with the key fact (async job) in parentheses. It is front-loaded and wastes no words, though the parenthetical could be more informative about what async implies.
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?
Given 6 parameters, no output schema, no annotations, and a closely-named sibling, the description is minimally adequate. It states the core purpose and async nature but omits the callback-driven completion model, permissions, and disambiguation from users_export_control_group — leaving real gaps an agent would need to fill.
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 coverage is 67%, so the schema documents most parameters. The description adds nothing about output_format options, fields_to_export, or callback_endpoint semantics — notably the async callback behavior is only hinted at in the parenthetical. Baseline 3 is appropriate when schema does most of the work, but the description misses an opportunity to clarify the async flow.
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 verb (Export) and resource (user profiles in a segment), clearly distinguishing it from generic users_export. However, it doesn't differentiate from the close sibling users_export_control_group, which would be the main ambiguity for an agent selecting between them.
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?
No guidance on when to use this versus users_export, users_export_control_group, or other export tools. The twin sibling users_export_control_group is a strong signal that usage is non-obvious, yet no disambiguation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.