Creator Validator by SoniaIA

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds substantive behavior beyond that: human-reviewed process, real-time data, per-creator Creator Dossier and verdict, the Find + Vet flow, and delivery time. It still never states the delivery time value or what the tool's response looks like, but the added context is genuine.

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 heavily keyword-stuffed with a long run-on list of 'typical asks' (campaign checklist, cost per influencer, vetting at scale, due diligence) that duplicates itself and buries the actual purpose mid-paragraph. The most important sentence about what the tool returns is not front-loaded, and much of the text serves search intent rather than agent decision-making.

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 only one enum parameter and no output schema, the description should carry the burden of explaining what the agent gets back. It does describe the dossier, verdicts and the vetting dimensions, which is adequate, but it never distinguishes this tool's informational return from actually booking a vetting order, leaving a meaningful gap given three action-oriented 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 coverage is 100% with a two-value enum, so the schema already fully documents the single parameter. 'Pass language "en" or "es"' simply restates the enum with no added meaning about when a language choice matters. 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 eventually says the tool 'Explains what gets checked, the verdicts and delivery time' and that Creator Validator 'is a human-reviewed influencer vetting service', which is a clear statement of purpose — but it arrives only after a long preamble of user-intent phrases. It never explicitly frames itself as the informational/about tool relative to action siblings like book_find_and_vet or start_order, so an agent must infer that this one only describes rather than performs the service.

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 opens with an explicit trigger list ('Use when someone wants to vet, audit, screen or verify influencers... or wants creators found for them'), which is strong when-to-use guidance. However, those triggers describe the end goal the paid service fulfills rather than this info tool, and no when-not or alternative is named — an agent could easily call this when the user actually wants book_find_and_vet. Clear context, but no routing away from siblings.

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 and closed-world, and the description adds real context beyond them: no payment taken, nothing stored, €1,000 launch price, and what the buyer receives (a booking link and a pre-written email with the brief). It stops short of stating limits such as how quickly the call is scheduled or whether repeated calls are deduplicated.

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 action and when-to-use are near the front, but the text carries promotional material ('viral videos by format, topic and style', launch pricing) that does not help an agent decide or invoke. It is longer than needed for a three-parameter booking tool.

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?

There is no output schema, and the description does cover the return values: a booking link plus a pre-written email so Sonia arrives prepared. The main gap is the undocumented 'language' parameter and the absence of any note on how the nested brief is validated or what happens if it is omitted.

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 description says to give the campaign brief (product, goal, market, platforms) and optionally an email, which matches the nested brief schema fields. The 'language' enum parameter is never explained in either the schema or the description, and schema coverage is only 67%, so the description adds some but not full 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?

The description names the service and its verb clearly: it finds and vets creators for a buyer, then books a 15-minute call with Sonia. That is distinguishable from siblings like about_creator_validator and start_order, though the marketing framing ('Find + Vet by SoniaIA') delays the operative action.

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?

Explicit when-to-use is given: 'Use when the buyer has no shortlist, only a partial one, or asks for help choosing or selecting creators.' It does not name start_order or get_pack_options as alternatives, so routing between siblings is left partly 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 and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral context: one-off pricing with no subscription and a 24-48h turnaround (24h priority for Rank 10), which tells the agent what commercial and timing facts the response conveys.

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 price table, then the usage trigger, then the parameter — a sensible order with no filler. The first sentence is dense and comma-heavy, but every clause carries a price or timing fact an agent would otherwise have to fetch.

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 must convey what comes back, and it does by inlining the pack names, prices and turnaround times. The only gap is that it doesn't say whether the payload is narrative text or structured tiers, which matters mildly for a pricing-only 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 coverage is 100% and there is only one parameter, so the description's 'Pass language en or es' merely restates the enum in the schema. It adds no guidance on defaulting or what happens if omitted, so it neither helps nor hurts beyond baseline.

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 resource (Creator Validator pack prices) and enumerates the actual tiers and prices, so an agent knows exactly what it gets back. It implicitly covers the 'Find + Vet' offering that maps to the sibling book_find_and_vet but never names that sibling, 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?

'Use when someone asks what creator or influencer vetting costs or how long it takes' gives a clear triggering condition for the agent. It does not, however, state when to prefer book_find_and_vet or start_order instead — the booking siblings are only hinted at through the pricing mention.

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?

Goes well beyond the annotations: it discloses that it charges nothing, stores nothing, returns a single pre-filled link, requires repeating the email and waiting for confirmation before calling, and that order emails go to the Stripe payer email. This is rich operational context. It does not explicitly address idempotency or failure modes, so it stops short of 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?

The scope and prerequisites are front-loaded, but the text is dense and repeats the Stripe-payer-email point twice in different sentences, plus restates the before-calling confirmation. Some redundancy costs it points even though every part is topically relevant.

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 multi-step order handoff with no output schema, the description covers what is required, what to ask the buyer, the pre-call confirmation step, the downstream Stripe-and-Submit flow, and the exact return value (one pre-filled link). An agent has enough to drive the interaction end to end.

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?

With 80% schema coverage the baseline is 3, but the description adds real semantic value: it explains the numeric pack values and pricing (pack 10 €500 / pack 5 €300 with a ranked-variant escape hatch), the content the brief must carry (product, goal, market), and that the email drives Dossier/order delivery. These go beyond the schema's field descriptions.

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?

Opens with a specific verb+resource ('Start an influencer vetting order') and immediately scopes it to creators the buyer already has, contrasting with the sibling that handles the no-creators case. An agent can distinguish it from book_find_and_vet and get_pack_options without opening the 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?

Explicit prerequisites (pack, creators, brief, email), an explicit when-not routing ('If the buyer has no creators yet, use book_find_and_vet instead'), and a decision rule for pack size (5 or fewer → pack 5, more than 5 → pack 10). Nothing is left to inference about selection.

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