qobrix_cohort

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 explains the internal logic for each mode (e.g., 'walks closed contracts → opportunity_id → opportunities.contact_name') and details the exact return fields (deal_count, total_volume, etc.). It does not mention authentication, rate limits, or cost, but for a read-only reporting tool, the disclosed behavior is solid.

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 is well-structured and every sentence adds value: overview, mode explanations, return fields, and concrete examples. It is longer than a trivial sentence but appropriate for a tool with 9 parameters and three modes. The examples are concise and directly illustrate usage.

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?

The tool has 9 optional parameters, no output schema, and no annotations. The description covers the core functionality, all three modes, and the return data shape, which is sufficient for most usage. However, it doesn't explain how parameters interact (e.g., 'year' vs 'from/to' vs 'since_days') or edge cases like conflicting windows, which would be helpful for complete guidance.

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 100%, so the baseline is 3. The description adds value by explaining the 'kind' parameter's three modes in depth and providing example values for 'year', 'min_count', and 'since_days' in context. It also clarifies the meaning of 'buyers' vs 'sellers' vs 'leads' beyond the enum names. However, it does not add extra nuance for parameters like 'contract_types' or 'contract_statuses' beyond what the schema already states.

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's function: finding contacts that appear on multiple deals or opportunities, with a specific verb ('Find') and resource ('contacts'). It distinguishes itself from sibling list/search tools by focusing on repeat-customer cohort analysis across deals and opportunities, and describes three distinct modes.

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 gives concrete example use cases with parameter combos (e.g., '2026 repeat buyers', 'All-time loyal customers'), making when to use the tool clear. However, it does not explicitly contrast with alternative sibling tools like qobrix_deals or qobrix_aggregate, which could also be used for similar analytical queries.

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