Minds: Synthetic Market Research

Get Audience Limits

get_audience_limits

Read-onlyIdempotent

Returns the Audience size ceilings that apply to the authenticated account before an Audience is created: the per-Audience plan cap including any configured team allowance, the custom-size maximum, and the per-mode ceilings. Relevant whenever a size is named, "as many as possible" is asked for, or a creation mode is chosen.

The two mode ceilings are different things. automaticSizingCeiling bounds the size the server picks when memberCount is omitted; explicitCountCeiling bounds a size you state, and only "balanced" has one — exceeding it is refused with MODE_CAP. In the deeper modes a stated size is bounded by memberCap alone.

These are sizes for each Audience, not workspace capacity, remaining credits, or a reservation. The response names the account and team the allowance belongs to, which can differ from another connector or browser login.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`mode`	No	Report only this creation mode. Omit to see every mode.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`creationModes`	No	Audience creation modes and their limits, when a mode was requested.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 20, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "creationModes": {
+      "description": "Audience creation modes and their limits, when a mode was requested."
+    }
+  },
+  "type": "object"
+}

AddedSep 3, 2026

TDQS

A5/5.0

Behavior5/5

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so no side effects are expected. The description adds valuable behavioral context beyond annotations by explaining the distinct meanings of the two mode ceilings, the MODE_CAP refusal behavior, and that the response identifies the account/team which may differ from other connectors. It also clarifies the data scope (per-Audience, not workspace), giving the agent a full picture of the tool's semantics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately detailed without waste. Each sentence serves a distinct purpose: defining outputs, stating relevance, clarifying field semantics, and disambiguating scope. It is well-structured and front-loads the core purpose before diving into nuances. No redundant phrasing or filler.

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?

Given the tool's simplicity (one optional parameter) and the presence of an output schema, the description is remarkably complete. It explains the meaning of the returned fields, when to use the tool, and the error condition (MODE_CAP). It covers all aspects an agent needs to call it correctly and interpret results. There are no apparent gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'mode' is fully described in the schema (enum with three values, each with a description), giving 100% schema coverage. The description goes further by explaining the practical implications of each mode (e.g., only balanced has an explicitCountCeiling) and the effect of omitting the parameter. This enriches the schema's semantics and helps the agent choose the right value.

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 precisely states the tool returns 'Audience size ceilings' for the authenticated account, listing specific components (per-Audience plan cap, custom-size maximum, per-mode ceilings). It further disambiguates the meaning of the returned fields (automaticSizingCeiling, explicitCountCeiling, memberCap) and clarifies what these are not (workspace capacity, credits, reservation). This is a specific verb+resource action that clearly differentiates from sibling tools like list_audiences or create_audience_from_brief.

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?

The description explicitly states when the tool is relevant: 'Relevant whenever a size is named, "as many as possible" is asked for, or a creation mode is chosen.' It also explains the nuanced behavior of mode ceilings and which mode has an explicit cap, warning that exceeding it is refused with MODE_CAP. This provides clear contextual guidance without ambiguity and implicitly tells the agent when to consult this tool versus alternatives.

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

All Minds: Synthetic Market Research 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.