Ergora Specialists

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

Annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds real value beyond that by stating the return shape ('summarised, cited insights') and the provenance of the answers (curated practitioner/book/research knowledge base), which no structured field conveys since there is no output schema.

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?

Two sentences with no filler: the first establishes identity and scope, the second establishes return format and source quality. Nothing repeats the title and nothing is buried.

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 correctly compensates by telling the agent answers are summarised and cited from a curated corpus. Combined with the fully documented input schema, an agent has enough to call it correctly; only the routing-versus-siblings question is left open.

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%, and the schema already carries the important semantics — notably the free-tier unlock via email and the subscribe opt-in gate. The description adds no parameter-level information, so the baseline of 3 applies; nothing is missing that the schema does not already supply.

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 names a specific verb ('ask the specialist') and resource (paid ads domain), and enumerates the covered sub-domains (Meta, Google, TikTok, creative, media buying, attribution), which meaningfully separates it from generic siblings like ergora_marketing. It stops short of naming a sibling it is not, so an agent scanning 19 near-identical ergora_* names still has to reason about overlap.

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 domain list implies when the tool is appropriate, but there is no explicit when-to-use/when-not guidance and no pointer to alternatives such as ergora_marketing for higher-level or cross-channel questions. The agent must infer routing from the topic labels alone.

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 readOnly, idempotent, non-destructive, open-world behavior, so safety is covered. The description adds the fan-out scope (all 17 specialists) but says nothing about throughput limits, the free-tier/email unlock, or the shape of what comes back — all of which matter for a network-backed query tool.

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?

Two short sentences, zero filler, with the primary capability front-loaded and the alternative routing second. Every clause carries decision-relevant 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 five-parameter read-only query tool with full schema coverage and a complete annotation set, the description covers the essential routing decision. It stops short of noting the daily quota / subscription behavior that affects real invocation choices, but no output schema exists to compensate for return-shape ambiguity.

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 email, query, top_k, vertical, and subscribe are all documented in the schema, and the baseline is 3. The description only loosely reinforces the 'vertical' parameter by telling the agent to prefer the per-vertical tool; it adds no syntax or defaulting detail beyond the schema.

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 specific verb+resource+scope: asking across all 17 Ergora specialists at once, cross-vertical. It also names the contrasting sibling pattern (ergora_<vertical>), so an agent can distinguish it from the 17 vertical tools without opening a schema.

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 a clear routing rule: use this for cross-vertical questions, use a specific ergora_<vertical> tool when the domain is known. That covers the main when/when-not decision, but it doesn't address the other plausible alternatives such as ergora_list_specialists or clarify that trivial lookups are a poor fit.

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, idempotentHint, non-destructive and openWorld, so the safety profile is fully covered. The description adds that output is summarised and cited from a curated knowledge base, which is genuinely useful, but says nothing about rate limits or the free-tier gating that the schema mentions.

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?

Two tight sentences, front-loaded with the action and scope, with no filler. The parenthetical topic list earns its place as scope signal rather than padding.

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 correctly states the return shape (summarised, cited insights), and the schema fully covers parameters and tiering. However, in a 19-sibling specialist family it omits any routing guidance, which is the main missing piece for an agent to call the right tool.

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 (query, email, top_k, subscribe) are already documented with usage context in the schema itself. The description adds no parameter-level detail beyond naming the domain, so the 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 clear verb ('Ask') and resource (the Business Strategy specialist) plus an explicit scope list (competitive strategy, OKRs, planning, positioning) that maps to its domain sibling. It separates itself from non-strategy specialists like ergora_finance or ergora_legal, though it does not clarify the boundary with overlapping siblings such as ergora_leadership or ergora_entrepreneurship.

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?

There is no explicit when-to-use guidance and no routing against the 19 sibling specialists; the closest is the implicit 'ask the specialist' framing. An agent facing a strategy-adjacent question (leadership vs. entrepreneurship vs. business strategy) gets no help choosing, and the free-tier/email behavior lives only in the schema.

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, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description usefully adds the nature of the response ("summarised, cited insights from a curated knowledge base"), but omits operational context such as the anonymous 5-query limit and the email-unlocked 30-query tier that only appear in the schema.

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?

Two tight sentences with the action front-loaded ("Ask the ... specialist") and the return behaviour second; no filler. It is efficient, though the second sentence could have carried a routing hint at no extra length cost.

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 correctly compensates by stating that answers are summarised and cited. Combined with 100%-covered parameters and rich annotations, the only real omission is guidance on when to prefer this specialist over its siblings.

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 fully documents query, email, top_k and subscribe, including the tiering logic. The description adds no parameter-level meaning of its own, so the baseline 3 is the correct ceiling here.

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 specific verb ("Ask") and resource ("Ergora Community Building specialist") and scopes it with concrete sub-topics (brand communities, engagement, moderation, events), which naturally differentiates it from the other 18 domain siblings. It is clear, but it never explicitly contrasts itself with a neighbouring specialist (e.g. ergora_ask or ergora_marketing), so it falls 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?

Usage is only implied: the agent can infer it should call this when it needs community-building expertise. There is no explicit when-to-use framing, no when-not condition, and no named alternative among the many sibling specialists, which is the exact ambiguity a routing decision needs resolved.

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 readOnly, idempotent, openWorld and non-destructive behavior, so the safety profile is covered. The description does add useful output context ('summarised, cited insights from a curated knowledge base'), but it omits the anonymous-vs-email query quota and the fact that 'subscribe' triggers outbound email, which live only in the schema.

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?

Two compact sentences: the first establishes what the tool is and its scope, the second establishes what comes back. Nothing is redundant or buried.

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 usefully characterizes the return as summarised and cited from a curated knowledge base, and annotations cover safety. Minor gaps remain around quota behavior and the email-confirmation side effect, though those are recoverable from the schema.

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%, including the free-tier quota rationale for 'email' and the constraint on 'subscribe', so the schema carries the burden. The description adds no per-parameter meaning beyond what is already documented, which is the expected baseline here.

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?

Names a specific action (ask a specialist) plus the resource domain, and lists the sub-topics it covers (SEO, editorial, distribution, content strategy) so an agent can route by topic. It does not, however, draw an explicit boundary against the overlapping sibling ergora_marketing, leaving topical overlap to inference.

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 domain parenthetical implies when to reach for this specialist versus the other ergora_* domains, but there is no explicit when-to-use statement, no when-not-to-use condition, and no named alternative such as ergora_marketing or ergora_ask. Usage is inferable, not stated.

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 cover the safety profile (readOnly, idempotent, non-destructive, openWorld). The description adds useful behavioural context about the source of answers ('curated knowledge base of practitioners, books and research') and their form (summarised and cited), but it omits rate-limit and tier behaviour, both of which appear only in the schema. Modest value beyond structured fields.

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?

Two tight sentences; the what-it-is statement leads and the return format follows. No filler, no restating of the title.

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 query tool with four fully documented parameters and no output schema, the description supplies the missing piece — what a caller gets back (summarised, cited insights). It leaves routing against sibling specialists unspecified, which is the only real gap.

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 fully documents email, query, top_k and subscribe, including the free-tier and confirmation-link semantics. The description contributes no additional parameter meaning, so the 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?

Names a specific resource (the Ergora Creator Economy specialist) and scopes it with concrete subtopics — audience growth, monetisation, personal brand — which routes it apart from siblings like ergora_marketing or ergora_content. It also states the output form (summarised, cited insights). It stops short of explicitly contrasting with the nearest sibling, so it is clear but not sibling-differentiating.

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?

Usage is only implied by the domain scope; the description never says when to pick this specialist over the 18 sibling specialists, nor any anti-patterns. An agent must infer routing from the topic keywords alone.

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, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuinely new context about the return behavior: summarised, cited insights drawn from a curated knowledge base. That is useful beyond the annotations, though it omits rate-limit or tier behavior that the schema carries.

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?

Two sentences with no filler; the domain scope is front-loaded ahead of the return-value note. Efficient, though the second sentence could be trimmed without loss.

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 carries the burden of describing returns and does so adequately ('summarised, cited insights'). For a single-required-parameter read-only tool, this is nearly complete; it would only benefit from an explicit note on querying alternatives.

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% and every parameter, including email tier behavior and subscribe semantics, is already documented in the schema. The description adds no parameter-level meaning beyond what is structured, so the 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?

Names a specific resource (the Ergora Design and UX specialist) and scopes its domain parenthetically as product design, usability, brand, and design systems. An agent can distinguish it from ergora_marketing or ergora_ads by domain, though the description never explicitly contrasts itself with those siblings.

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?

Usage is implied by the domain keywords ('product design, usability, brand, design systems'), so an agent knows roughly when to reach for it. There is no explicit when-not guidance and no mention of ergora_ask or ergora_list_specialists as alternatives, leaving routing to inference.

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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description usefully adds the epistemic nature of the output ('summarised, cited insights from a curated knowledge base'), which matters because no output schema exists, but it omits the free-tier rate-limit behavior that only appears in the email parameter's schema text.

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?

Two sentences, front-loaded with the action and specialist identity, followed by the return-value nature. No filler or restated title padding.

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 read-only research tool with full schema coverage and no output schema, the description covers purpose, topic scope and the shape of the return. The remaining gap is routing guidance against the other 18 ergora specialists, which is the one thing an agent most needs here.

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% and all four parameters are documented in the schema, so the baseline is 3. The description adds genuine meaning for the required 'query' parameter by defining its topical scope (software craft, DevOps, architecture), helping the agent phrase and route requests correctly.

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 ('Ask') and resource ('the Ergora Developer specialist') and scopes the domain with 'software craft, DevOps, architecture', which distinguishes it from the many other ergora_* domain specialists. It stops short of explicitly routing the agent away from siblings like ergora_ask or ergora_list_specialists.

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?

There is no when-to-use or when-not-to-use guidance. The description never mentions the general sibling ergora_ask, so an agent cannot tell whether a software question should go here or to the general research tool, nor does it explain what 'specialist' invocation buys over the generic path.

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, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered. The description earns some credit for disclosing that output is summarised and cited from a curated knowledge base, but it omits the free-tier/rate-limit behaviour that only the schema mentions and says nothing about latency or result freshness.

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?

Two tight sentences: the first front-loads what the tool is and its scope, the second states the return contract. Zero filler or restated boilerplate.

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 read-only knowledge-base query tool with full schema coverage and no output schema, the description covers purpose, domain scope and return format adequately. It falls short only on routing against sibling specialists and on the tier/quota context that an agent would want before prompting the user for an email.

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 itself documents email (free-tier unlock), query, top_k and subscribe. The description adds no parameter-level meaning beyond that, which is the correct baseline when the schema does the heavy lifting.

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 action (ask the specialist), the resource (Ergora Ecommerce), and the topical scope (Shopify, WooCommerce, DTC, conversion, retention, email/SMS) plus the return type (summarised, cited insights). The domain scope distinguishes it from most siblings, but against the near-identical 'Ergora <domain> Specialist' family it relies on the domain keyword alone rather than an explicit contrast with a sibling.

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?

Usage is implied by the topical scope: use it for ecommerce questions. There is no explicit when-to-use, when-not-to-use, or routing guidance (e.g. versus ergora_ask or ergora_list_specialists), which is a real gap in a family of 19 near-synonymous specialist tools.

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?

Beyond the annotations (which confirm it is read-only), the description adds crucial behavioral traits: the insights are 'summarised, cited' and come from a 'curated knowledge base,' informing the agent about the expected quality and presentation of the returned data.

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?

It is a single, dense sentence where every clause serves to define either the scope (entrepreneurship stages) or the output quality (summarised, cited insights), demonstrating maximum efficiency.

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?

As a knowledge retrieval tool without an output schema, the description is highly complete. It specifies not only the topic but also the source, the delivery mechanism, and the expected quality of the resulting data.

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?

Since schema coverage is 100%, the schema defines the parameters technically. The description adds semantic value by reinforcing the operational rules of the optional fields (e.g., how the 'email' unlocks the free tier).

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 explicitly scopes the tool to a specific domain: 'starting, validating, funding and scaling a business.' This makes it distinct from the general 'ergora_ask' or specialized tools like 'ergora_finance'.

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 highly specialized domain focus (entrepreneurship stages) clearly guides the agent on when to invoke this tool versus when another specialized sibling (like 'ergora_marketing' or 'ergora_hr') should be used.

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, idempotentHint, openWorldHint, and non-destructive behavior. The description adds that responses are summarised and cited from a curated knowledge base, but it does not add further behavioral context such as rate limits, freshness, or limitations. With annotations covering the safety profile, a 3 is appropriate.

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?

Two sentences, front-loaded with the tool's purpose and domain scope, followed by the return behavior. No wasted language and easy for an agent to parse.

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 description covers purpose, domain, and return nature, while annotations cover safety and the schema fully documents parameters. No output schema exists, but the description sufficiently indicates that callers receive summarised, cited insights. Minor missing context around result freshness or limitations keeps it at 4.

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 every parameter including email tier behavior, top_k range, and subscribe semantics is already documented in the schema. The description does not add meaning beyond the structured fields, making the baseline 3 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 names a specific specialist and domain topics (SaaS metrics, cash flow, valuation, fundraising, CFO topics), and states the return format as summarised, cited insights. It clearly separates this finance-focused tool from generic siblings, though it does not explicitly contrast with any specific sibling tool.

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?

Usage is implied by the domain scope: ask this specialist for finance topics. There is no explicit guidance on when to prefer this over ergora_business_strategy or ergora_ask, and no exclusions or prerequisite context beyond what the schema states.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds that results are summarised and cited from a curated knowledge base, but omits the anonymous-tier quota (5/day) that materially affects how an agent should use it — that constraint lives only in the email parameter's schema text.

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?

Two sentences, zero filler, with the identity and scope front-loaded before the return behavior. Nothing is repeated from the schema or annotations.

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 read-only research tool with 100% schema coverage and no output schema, the description states the return shape (summarised, cited insights), which is the key thing an agent needs. It could be stronger by surfacing the quota/consumption behavior, since that is not obvious from the description alone.

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 (query, email, top_k, subscribe) are fully documented in the schema, including the free-tier unlock and the explicit-consent condition for subscribe. The description adds nothing parameter-specific, so the 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?

Names a specific verb (ask) and resource (HR and People Ops specialist) and enumerates the domain scope (hiring, culture, performance, employment). Against 18 same-pattern siblings, the domain parenthetical is exactly what lets an agent separate it from ergora_leadership, ergora_legal, or ergora_ask without opening a schema.

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 topic list implies when this tool is appropriate (HR/people questions), but there is no explicit when-not guidance or routing to alternatives such as ergora_leadership, ergora_business_strategy, or ergora_list_specialists. With 18 near-identical siblings, the absence of any disambiguation rule is a real gap, though domain keywords provide usable implied guidance.

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, idempotentHint, openWorldHint and non-destructive, so the safety profile is covered without the description. The description does add a real behavioural detail by characterising the output as summarised and cited from a curated knowledge base, which matters since there is no output schema. It says nothing about latency, retrieval behaviour, or what happens when the knowledge base has no match.

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?

Two sentences with zero filler: the first establishes who to ask and about what, the second establishes what is returned. The domain scope is front-loaded where an agent scanning siblings will see it first.

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 single-query retrieval tool with full schema coverage and annotations handling the safety profile, the description covers purpose and return shape adequately. The main remaining gap is sibling disambiguation within a large, overlapping specialist family, which the description only partially addresses through its topic parenthetical.

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%, including non-obvious details like the email free-tier unlock and the top_k range, so the schema carries the parameter burden. The description adds no parameter-level meaning at all, which is the expected baseline 3 when the schema is this complete.

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 ('Ask the Ergora Leadership specialist') and scopes the domain with parenthetical examples ('managing teams, execution, feedback'), which separates it from the generic ergora_ask. It also says what comes back ('summarised, cited insights from a curated knowledge base'). It stops short of explicitly naming which sibling to use instead when the topic straddles domains.

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 parenthetical topic scope implies when this specialist is the right one, but there is no explicit when-to-use statement and no routing against adjacent siblings like ergora_hr or ergora_business_strategy, whose remits clearly overlap with 'managing teams, execution, feedback'. Usage is inferable but not stated.

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 readOnly, idempotent, openWorld and non-destructive, so safety is covered; the description adds genuinely new behavioral context by disclosing that answers are summarised, cited, drawn from a curated practitioner/book/research knowledge base, and explicitly not legal advice. Rate-limit/auth behavior is left to the schema rather than the description.

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 the action and specialist name, and the second sentence efficiently covers the return nature. The nested parentheses '(contracts, IP, compliance, startup law (not legal advice))' are slightly awkward but not wasteful.

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 correctly compensates by describing the return (summarised, cited insights) and the source corpus, and all four parameters are fully documented in the schema. The remaining gap is routing guidance relative to the 18 sibling specialists.

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%, and the schema already explains email (free-tier unlock), top_k (1-10 insights), subscribe (opt-in confirmation link) and query. The description adds nothing about parameter meaning, so the 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 verb ('Ask') and a specific resource (the Ergora Business Legal specialist) and enumerates the covered domain (contracts, IP, compliance, startup law), which does differentiate it from domain siblings like ergora_finance or ergora_hr. It stops short of distinguishing itself from the generic ergora_ask or ergora_business_strategy, which share the same 'ask a specialist' shape.

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?

Usage is only implied by the topic list; there is no explicit statement of when to pick this over ergora_ask, ergora_business_strategy, or other specialists, and no prerequisites. The '(not legal advice)' caveat is the one real scoping rule offered.

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, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered structurally. The description adds only that the result set is bounded at 17 and includes per-vertical coverage summaries; it says nothing about response shape beyond that.

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 sentence with no filler, and the key fact (17 verticals) is front-loaded immediately after the verb. Nothing could be trimmed without losing meaning.

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 zero-parameter, read-only listing tool with no output schema, the description supplies enough to predict the return: 17 verticals plus a coverage description each. Only the exact field names are unspecified, which is minor for a simple index call.

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 takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No parameter language is needed or missing.

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 ('List'), a precise resource ('the 17 Ergora specialist verticals'), and the content of each entry ('what each covers'). The fixed count of 17 and the directory framing make it distinguishable from the per-vertical siblings, though it never names those siblings as the items being indexed.

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?

Usage is only implied: an agent can infer this is a discovery/index tool to consult before selecting one of the concrete specialist tools. There is no explicit 'call this first' or 'do not use for actual specialist work' statement, and no sibling is named.

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, idempotentHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful return-shape context ('summarised, cited insights from a curated knowledge base'), but is silent on quota/auth behaviour (the free tier and email unlock live only in the schema) and on latency or whether sources are reproducible.

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?

Two tight sentences with zero filler: the first front-loads what the tool is and its scope, the second what it returns. Nothing repeats the title or the schema, and nothing is padded.

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 moderate-complexity query tool with no output schema, the description does name the return format, which is the main thing missing elsewhere. But with 19 sibling specialists and no routing rule, an agent still lacks enough to reliably choose this tool over ergora_marketing, ergora_community or ergora_ask.

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 query, email, top_k and subscribe are each already documented, including the free-tier mechanics and the subscribe confirmation flow. The description adds nothing parameter-specific, which is the expected baseline when the schema does the heavy lifting.

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 names a specific specialist domain (Local Marketing) plus a concrete scope parenthetical — local SEO, small business marketing, community presence — and states the deliverable ('summarised, cited insights'). This lets an agent tell it apart from generic siblings like ergora_marketing or ergora_community, though the overlap with those two is never explicitly resolved.

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?

There is no explicit when-to-use or when-not-to-use guidance and no named alternative, which matters because the tool sits among 19 near-identical 'ergora_<domain>' specialists (ergora_marketing, ergora_community, ergora_pr) plus ergora_ask and ergora_list_specialists. The agent must infer routing purely from the domain label in the title.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds value beyond them by disclosing the output nature ('summarised, cited insights from a curated knowledge base of practitioners, books and research'), which matters because there is no output schema.

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?

Two tight sentences with zero filler; what the tool is comes first, what it returns second. Nothing needs to be cut or reordered.

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 read-only research tool with a fully documented schema and no output schema, the definition covers purpose, scope and return character adequately. The remaining shortfall is selection guidance relative to the dense sibling set, which an agent must resolve on its own.

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%: query, email, top_k and subscribe are all documented in the schema, including the email tier-unlock behaviour and the subscribe confirmation flow. The description adds nothing about parameters, so the 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 verb ('Ask') and resource ('Marketing specialist') and enumerates the domain scope (positioning, strategy, growth, analytics), which helps separate it from siblings like ergora_ads and ergora_pr. However, the scope still overlaps visibly with ergora_business_strategy and no sibling is named or contrasted, so differentiation is inferred rather than stated.

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 topic list implies when this specialist is the right pick, but there is no explicit when-to-use/when-not-to-use guidance and no routing against the 18 sibling specialists. With this many near-neighbours (ads, sales, pr, content, business_strategy), the absence of routing rules is a real gap.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds that results are summarised and cited from a curated knowledge base, which is mild output-character context, but it omits the rate-limit/quota behavior that only appears in the schema.

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?

Two compact sentences with the purpose front-loaded and the return characteristic second. No filler or repetition; slightly terse but every clause carries weight.

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 4-parameter retrieval tool with no output schema, the description conveys what it does, the domain, and the nature of the return value. Combined with fully covered schema descriptions and rich annotations, an agent has enough to invoke it correctly, though routing guidance among siblings is still 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 all four parameters (query, top_k, email, subscribe) are already documented in the schema, including the free-tier email logic and subscribe confirmation. The description adds nothing parameter-specific, so the baseline of 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?

Names a specific verb (Ask) and a specific resource (the Ergora PR and Communications specialist), with a parenthetical that scopes the domain to media relations, crisis comms and brand reputation. That domain scoping is what distinguishes it from the many ergora_* sibling specialists, though it never explicitly contrasts itself with the generalist ergora_ask.

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?

Usage is only implied by the domain label — an agent can infer 'use for PR/comms questions' but the description offers no explicit when-to-use, when-not-to-use, or routing rule versus ergora_ask or the adjacent specialists. Minimum viable but with a clear gap in alternative selection.

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 readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description usefully adds the return character ('summarised, cited insights') and the sourcing ('curated knowledge base of practitioners, books and research'), but omits notable behaviors documented only in the schema, such as the anonymous vs email-tier query quota and the subscribe confirmation email.

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?

Two sentences, zero filler: the purpose and scope come first, the return behavior second. Nothing repeats the tool title or the structured fields verbatim.

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 simple read-only research tool with no output schema and full schema coverage, the description covers what it is, what it covers, and roughly what comes back. It could say more about result shape or the free-tier/quota behavior, but nothing essential for correct invocation is missing.

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 baseline is 3. The description adds no parameter-level meaning beyond the schema — it never mentions the email tier unlock, top_k range, or the subscribe opt-in, all of which are fully documented in the schema itself.

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 names a concrete verb and resource ('Ask the Ergora Sales specialist') and enumerates the covered domain (prospecting, outreach, pipeline, closing, sales ops), which separates it from ergora_marketing, ergora_ads and the other domain siblings. It stops short of explicitly saying how it relates to the general-purpose ergora_ask, so it is clear but not perfectly differentiated.

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?

Usage is only implied by the domain topic list; there is no statement of when to pick this over ergora_ask or over adjacent siblings such as ergora_marketing, and no exclusions or prerequisites. An agent can infer 'use for sales questions' but gets no routing rules among the 18 siblings.

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