Imagine AI Benchmark

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

Annotations already declare readOnlyHint=true, so safety is covered. The description adds useful context that the output is counts plus engagement grouped by category, but says nothing about how categories are derived, whether uncategorized posts appear, or how metrics are computed.

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?

A single front-loaded sentence that names the metric, the grouping dimension, and the scope with no wasted words.

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?

With 7 parameters and no output schema, the description should clarify the return shape (what counts, what engagement metrics, how results are grouped). It gives the gist but leaves the actual response structure ambiguous for an agent that must interpret results.

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 100%, so the schema already documents every parameter including the enums and date formats. The description adds only the loose 'for companies or people' phrasing that maps to the source parameter, so baseline 3 applies.

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 resource (post counts and engagement per content category) and the entities it covers (companies or people), with concrete category examples. It is clear what the tool produces, though it does not explicitly differentiate itself from siblings like industry_landscape or company_fit_summary.

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 offers no when-to-use guidance, prerequisites, or alternatives. 'For companies or people' hints at scoping but never tells the agent when this breakdown is the right tool versus another aggregate view.

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

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

Annotations only declare readOnlyHint=true, so the description carries most of the load and does it well: it explains the ranking rule (median over up to 5 fitted people plus the page), the selection order (founders/CEO/C-suite in last 90 days, then most active), the 18-post floor, the '1 account' flag, and that results are held back while history pulls are pending. It omits pagination/return-shape detail, keeping it from a 5.

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?

Front-loaded with what the tool returns, and every clause about ranking, the floor, and the single-account case earns its place. The second sentence is a long run-on that is harder to parse than necessary, so it is not a clean 5.

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 complex analytical tool with no output schema and no required params, the description explains the computation, edge cases (single account, pending pulls), and which output fields identify counted members. That is nearly complete; only pagination/return format is left implicit.

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 100%, so the schema already documents all five inputs. The description references people.counted/countedPersonIds, but those are output fields, not the input params, so it adds no new meaning about dateTo, company, dateFrom, companyId, or workspaceId.

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 resource (a company's page fit plus its people's geometric-mean distribution, median and baseline band) and even the computation behind it. It does not explicitly name or contrast itself with siblings like category_breakdown or industry_landscape, so it stops short of a 5.

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 closing line 'Use for "how is X doing on LinkedIn"' gives one concrete usage scenario, but there are no exclusions or alternatives named (e.g. when to prefer category_breakdown or list_companies). Usage is implied rather than spelled out.

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

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

Annotations carry only readOnlyHint=true, so the description shoulders most of the burden and does add real behavioral context: the preliminary/solo flagging rules, the author-effect removal, and the caller-sensitive visibility rule ('public callers get bands and pooled lifts, the same as Discover'). It does not cover pagination or response shape, but the access-level disclosure is genuinely useful.

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 core deliverable is front-loaded before the alternative-use sentence, which is the right ordering. But the body is a single dense paragraph of stacked parentheticals and undefined internal jargon ('page fit', 'fitted people', 'peopleCounted'), which is hard to parse rather than economical.

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?

With no output schema in play, the description rightly spends its words explaining what comes back – rollup metrics, the preliminary and solo flags, baseline comparison, category lift – so an agent knows what to expect. Undefined domain terms are presumably covered by the methodology sibling, so the remaining gap is minor for a tool of this complexity.

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 100%, so the schema already documents all six parameters, including the industry/companyIds/workspaceId fallback chain. The description restates the industry-vs-custom-set split but adds no syntax, format, or precedence detail beyond what the schema states. Baseline 3 is appropriate.

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 states a concrete analytical product: a per-company rollup with population-vs-baseline and author-effect-removed category lift, scoped to an industry or a custom company set. That is well beyond a restatement of the name. However it never differentiates itself from the overlapping siblings category_breakdown and company_fit_summary, so an agent must guess which of the three to reach for.

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?

It gives two concrete triggering questions ('what works in fintech', 'where does X sit in its market'), which map onto the two halves of the output. That is clear usage context. There are no exclusions or explicit routing away from category_breakdown/company_fit_summary, so it stops short of a 5.

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

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

readOnlyHint=true already establishes a safe read, and the description adds genuinely useful context by saying the return is ids consumed by other tools. It does not add anything about default result volume (the 200 default lives only in the schema), pagination, or truncation behavior, so with annotations carrying the safety profile a 3 fits.

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?

Three short sentences, no filler, with the catalog scope stated first, the filter options second, and the downstream-consumption fact last. Every sentence earns its place.

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 low-risk read-only list tool with full schema coverage and no output schema, the description covers what the tool is for and how its output is used downstream. It stops short of noting result-volume defaults or truncation, which an agent calling a list endpoint would want.

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 100%, so all four parameters including limit, query, industry, and trackingOnly are already documented with defaults and examples. The description only restates the filter dimensions the schema already names, adding example-free redundancy rather than new meaning.

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 and resource (list companies) and scopes the domain as the 'benchmark catalog' with concrete examples of what a company is (customers, competitors, industry peers). It does not explicitly distinguish itself from siblings like industry_landscape or category_breakdown, which keeps it just short of a 5.

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 clause 'Returns ids you pass to every other tool' tells the agent this is the entry-point lookup tool, and the filter list ('by name substring, industry, or tracking') names the ways to narrow it. There is no explicit when-not-to-use or named alternative, so it stops at 4.

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

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 call-once prerequisite, which is useful behavioral context. It does not describe the return format, but with read-only annotations the description meets a lower bar and adds some practical guidance.

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 short and contains no obvious filler, but the first sentence is cryptic and front-loads 'Imagine AI research rules' before the actionable instruction. The second sentence is clear and earns its place. Structure could be more immediately useful to an agent.

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?

With no output schema, the description should ideally explain what the tool returns. It names concepts like log-normal engagement and research baselines but does not state the return format or how to apply the rules. It gives enough to know to call it first, but not enough to fully anticipate its output.

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?

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics, and the empty schema is consistent with that.

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 title and description together imply this tool provides rules for reading benchmark numbers, and the phrase 'Call once before interpreting any numbers' gives a use condition. However, the description does not state a clear verb or resource for what the tool returns, and the opening 'Imagine AI research rules' is vague. It is distinguishable from sibling data tools but only weakly.

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 a clear usage condition: 'Call once before interpreting any numbers.' This explicitly tells the agent when to invoke it relative to interpreting benchmark numbers. It does not name alternatives or when not to use it, but as a prerequisite reference tool that gap is minor.

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