openpanel_get_unique_users

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It fails to indicate whether this is read-only (implied but not explicit), omits rate limits, return format, pagination behavior, or caching characteristics. The '[UNIFIED]' prefix hints at implementation context but lacks explanation of behavioral consequences.

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?

The description consists of two efficient sentences with no significant redundancy. The '[UNIFIED]' tag at the beginning appears to be metadata leakage but does not severely impact readability. The note about project_id is appropriately placed as secondary information.

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 3-parameter read operation with no output schema and no annotations, the description provides minimal viable coverage. It identifies the core metric being retrieved and one parameter constraint, but leaves the return value structure, date_range format syntax, and site parameter requirements unexplained. Adequate for basic invocation but incomplete for robust usage.

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 description coverage is 0%, requiring the description to compensate. It partially compensates by explaining project_id optionality based on environment configuration and referencing 'time period' which contextualizes date_range. However, site parameter is undocumented and date_range format/accepted values (e.g., '30d') are not explained, leaving significant semantic gaps.

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?

The description clearly states the tool retrieves 'unique user/visitor count for a time period' with specific resource (users/visitors) and scope (time-bounded count). However, it does not explicitly differentiate from similar sibling metrics tools like openpanel_get_event_count or openpanel_get_page_views, though the specific metric mentioned provides implicit distinction.

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?

The description includes one usage note that project_id is optional when configured in environment, providing conditional guidance for that parameter. However, it lacks explicit guidance on when to prefer this over other OpenPanel analytics tools (e.g., vs. openpanel_get_profile for individual vs. aggregate data) and does not mention any prerequisites or filters.

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