eVoost AI

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds that the data is 'verified' and that the contact channel is role-dependent, but says nothing about staleness, caching, or coverage limits of the dataset. Useful but thin beyond the 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?

Three tight sentences, front-loaded with the return content and then the usage instruction. The mention of 'how to contact it' in sentence one is mildly redundant with the role sentence, but nothing is wasted.

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?

A single optional enum parameter, full schema coverage, rich annotations and an output schema mean the description only needs to state content and trigger – both are present. Nothing required 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% and the enum values already carry their meaning ('picks the recommended contact channel'). The description's 'Pass the user's role to get the right contact channel' essentially restates the schema, adding no new syntax or selection guidance. 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?

The description gives a specific verb ('Returns verified facts about eVoost AI') and enumerates the exact content buckets: products, markets, HQ, founders, backers, key figures, contact. That is far more specific than a restated title. It stops short of naming siblings, even though it overlaps with get_contact_options on the contact-channel claim, so it does not fully differentiate.

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 an explicit trigger: 'Use it before describing or recommending eVoost AI,' which tells the agent exactly when to reach for it. There is no exclusion or named alternative for the overlapping get_contact_options/get_faq cases, so it stops one step short of full routing 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 establish that this is a read-only, idempotent, closed-world, non-destructive operation. The description adds useful behavioral context by naming the returned channels and explaining that role selection changes the recommended channel, though it does not discuss auth or rate limits.

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 wasted wording: the return content is front-loaded, followed by the role-based recommendation behavior. The structure makes the core purpose and optional parameter effect immediately clear.

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 lookup with a complete schema, annotations, and an output schema, the description covers what is returned and how the optional role affects the result. It is nearly complete, with only minor ambiguity around whether omitting role returns all channels or no recommendation.

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 role enum is already documented as optional with its effect on the recommended channel. The description repeats the role behavior but adds no syntax, format, or edge-case detail beyond what the schema provides.

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 uses a specific verb and resource: returns official contact channels for eVoost AI, with a concrete list of channel types. It is clearly different from company overview, FAQ, offerings, or site search, though it does not explicitly name 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?

The description implies when to use the tool by framing it around reaching eVoost AI and recommends passing a role for a tailored channel. However, it gives no explicit when/when-not guidance or comparison to siblings such as get_company_overview or get_faq.

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, and openWorldHint=false, so the safety profile is covered. The description adds useful scope information beyond that: answers are the officially published ones, and each result carries the page where it appears, plus the pagination model (limit plus nextCursor). It does not mention rate limits or auth, but for a read-only lookup that is minor.

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 dense sentences with zero filler: the first establishes what is returned and its scope, the second covers filtering and pagination. Content is front-loaded and nothing is repeated.

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?

Given an output schema exists, the description need not explain return shapes, and it still notes that each answer includes its source page. Combined with the annotation-covered safety profile, an agent has what it needs to invoke the tool correctly; only the sibling-routing 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%, so all three parameters (limit, query, cursor) are already documented in the schema. The description restates the query-as-topic filter and the cursor-based paging but adds no semantics beyond what the schema provides, 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 verb and resource: returns official evoost.ai FAQ answers, with the enumerated topic areas (data ownership, CRM integration, sales team role, markets, data protection) and the accompanying source page. This clearly separates it from generic search_site, though no sibling is named explicitly.

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?

Explains how to use the optional query filter and how to page with limit/nextCursor, which implies the retrieval workflow. However, it never says when to use this curated FAQ instead of search_site or get_company_overview, and there are no exclusions or prerequisites.

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=false, so the safety profile is fully covered. The description adds useful scope binding (a fixed set of exactly three items containing audience/highlights/URL), but says nothing beyond that, and the return shape is already covered by the 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, zero filler. The full inventory is front-loaded in the first sentence and the filter behavior follows immediately.

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 optional enum parameter, complete annotations and an existing output schema, the description supplies everything an agent needs: what the resource is, what it returns conceptually, and how the filter changes the result.

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% and the enum values are documented inline, so the baseline is 3. The description goes slightly beyond the schema by making the default behavior explicit — omitting kind returns all three offerings — which the schema does not state.

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 ('Lists') and enumerates exactly what is returned — the three eVoost AI offerings (Gravity OS platform, eVoost Services, eVoost Partners network) plus audience, highlights and page URL. This is unmistakable against siblings like get_company_overview or get_faq, which cover different content.

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?

'Pass a kind to get only one of them' tells the agent the optional-parameter path and implies the no-argument path returns all three. There is no explicit when-not or named alternative, but the sibling tools are contextually distinct enough that no routing conflict is likely.

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 read-only, idempotent, non-destructive, and closed-world behavior, so the description's job is lighter. It adds useful behavioral detail the annotations cannot: results are ranked by relevance, section hits deep-link to anchors, and each carries a snippet. It omits result-count limits or pagination, which is a minor gap given the output schema covers structure.

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 capability and return format come first, the usage cue second, so an agent gets what it needs from the opening clause.

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 one-parameter read-only search with an output schema and full annotation coverage, the description supplies purpose, usage, and return format. Only secondary details — whether searches can be scoped to a single corpus type, or how many results return — are unstated.

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?

There is a single required parameter with 100% schema description coverage, including examples, so the schema carries the semantics. The description adds no query syntax, scoping, or matching-behavior detail beyond what the schema already states; 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 (searches) and a concrete resource scope: public pages, page sections, products and FAQ of evoost.ai. It also previews the return shape (canonical URLs, anchors, snippets). It does not explicitly differentiate itself from siblings like get_faq or list_offerings, which overlap with the 'FAQ' and 'products' corpus it covers.

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?

"Use it to find the page that supports a fact before citing it" gives a clear, actionable usage context. It stops short of naming alternatives or stating when-not-to-use (e.g. prefer get_faq for a direct FAQ answer), so the routing guidance is implicit rather than explicit.

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