MentionFox

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

Annotations cover the safety profile, and the description adds behavior they cannot express: a flat 15-credit cost regardless of headcount, two free failure paths (fewer than two people on file, ambiguous name returning candidates), and the tabular read-down/read-across output shape. Pricing and free-of-charge edge cases are exactly the kind of operational context an agent should know before calling.

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 opening sentence puts the core action and output format first, and pricing plus eligibility caveats follow logically. It is dense dashed prose with some restatement of the schema's two-to-five bound, but almost every clause carries new 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?

With an output schema handling return values and annotations covering safety and idempotency, the description fills the remaining gaps: cost, free paths, ambiguity handling, prerequisite of prior lookups, and an explicit prohibited use. An agent has everything needed to decide and invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description earns the extra point by explaining the semantic effect of the optional context string — it steers the comparison framing — which the schema only hints at with examples. The people parameter is largely restated from the schema rather than extended.

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 and resource (side-by-side comparison of two to five people) and enumerates the comparison axes: how they work, career trajectory, experience depth, visibility, and connections. The only gap is that it never names a sibling tool (enrich_person, get_dossier) as a contrast, so differentiation from those has to be inferred.

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 states concrete use cases (people to pitch, partners to weigh, guests or speakers to prepare for) with the framing effect of the context parameter. It also gives an explicit exclusion — never for hire, admit, lend, or house decisions — and a prerequisite that the people be already looked up, meaning enrichment comes first.

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 read-only, idempotent, open-world, non-destructive, so the bar is lower, yet the description adds substantial behavior: a 5-credit charge only on a successful match, no charge on ambiguity or no-match, the candidate-list return path, and the MentionFox red-flag check prefixed when a company is supplied. These are things an agent could not infer from the annotations or 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?

Front-loaded with the resource and return shape, followed by usage triggers, exclusions, and cost model in a logical order. Slightly verbose with several quoted user phrasings and an appended pricing URL, but each sentence carries actionable 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?

An output schema exists, so return values need not be described, and the description still covers cost, ambiguity handling, the person_id follow-up path, and the company-driven red-flag prelude. For a three-parameter lookup tool, nothing an agent needs in order to call it correctly 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 coverage is 100%, so baseline is 3; the schema already explains name, company, and person_id. The description reinforces the company parameter's purpose ("add their employer if the name is a common one") and situates person_id in the two-step flow, but adds little syntactic or semantic detail beyond what the schema states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource framing: "How to reach one person: their email address, phone number where there is one, and their profile links," then names the returned fields (person, current role, contact methods). This is clearly distinct from siblings like compare_people or get_dossier, which operate on multiple people or broader reports.

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?

Explicitly states when to use ("how do I get hold of her", "find his email") and when not to ("Do not use it to find out WHO to contact: this looks up somebody you can already name"). It also documents the disambiguation loop — candidate list returned free, pick one and re-ask with person_id. The only gap is that it never names the sibling tool to use instead for the "who to contact" case.

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 the mutation/non-idempotent profile; the description adds the behavior that actually matters — each call produces a frozen snapshot rather than a live artifact, costs 5 credits, strips MentionFox branding, and supports custom logo/colours. It does not state whether a failed or repeated call still burns credits, which is the main open risk given idempotentHint=false.

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 produces, then the snapshot-vs-live caveat, then cost. The example utterances and pricing URL are slightly padding, but each sentence carries usable signal 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?

For a 4-parameter export tool with a full output schema and rich annotations, the description covers the dimensions an agent needs: output formats, branding scope, snapshot semantics, and cost. Minor gaps remain — the report_id cross-references to get_dossier are documented in the schema rather than the description, and error behavior is unaddressed.

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 the nested branding object and both enums is already documented in the schema. The description adds no format or report_id nuance beyond what the schema says, 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?

The description names a specific action and output: converts an existing report into a sendable file in html/pdf/markdown, with branding applied and no MentionFox watermark. The vague opener 'something you already have' is resolved by the schema's report_type enum, but the description itself never names the report kinds it accepts, so the agent must open the schema to know what 'something' means.

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 explicit trigger phrases ('send me that as a PDF', 'put our branding on it') and, critically, an explicit when-not: for anything that must stay current, share the live link instead of making a fixed copy. The 5-credit cost and pricing link let the agent weigh the call against a cheaper alternative.

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 read-only, idempotent, open-world behavior; the description adds real substance on top: 1 credit charged only when results come back, zero cost on empty searches, results never padded, provenance via record_url, and searched_feeds exposing which feeds were queried and their freshness. That is exactly the kind of cost/coverage disclosure annotations cannot carry.

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 required action, then behavior, then cost — a sensible order with little filler. It loses a point for re-listing every trigger type already enumerated in the schema and for the trailing promotional links (free trial, pricing) that are not needed to invoke the tool correctly.

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 5-parameter, open-world search with an output schema, everything an agent needs is present: input meaning, geographic and category limits, default trigger selection, result-size honesty, cost model, and field-level meaning of the return. The output schema makes the return-value explanation optional, so its inclusion is surplus rather than a requirement.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaning the schema does not: it explains that url is read to infer what you sell, that the cap is 10 companies, and crucially that omitting trigger_types makes the service pick event kinds matching your offering rather than defaulting to all. Only the days/state semantics are left entirely to 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?

States a concrete action and resource: reads your website, then searches recent filed events for up to 10 companies with a buy signal, enumerating the event categories. It is clearly distinguishable from the person-centric siblings (enrich_person, compare_people, get_dossier) without opening any 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?

Tells the agent the required input ('the website of the business you sell for'), scopes results to US companies, and explicitly excludes investment funds and real estate filings. It also points to a free web trial as an alternative route, though it never names a sibling tool or says when not to call this one.

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 read-only, idempotent, non-destructive behavior, and the description adds the parts annotations cannot express: the 30-credit cost, free repeat lookups, no charge on ambiguous or empty name matches, re-charge on refresh, and the prepended MentionFox company check. The cost and ambiguity handling materially change how an agent should plan a call.

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?

Scope and cost are front-loaded, and the routing guidance follows in priority order. It runs long, and the closing pricing URL plus the company-check paragraph are somewhat tangential to the core definition, but nothing is redundant enough to hurt comprehension.

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-parameter, paid, read-only lookup with an output schema available, the description covers scope, cost, ambiguity, refresh semantics, and partial-result behavior. An agent has everything needed to decide and invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description earns an extra point by explaining the operational consequence of person_id (from an earlier candidate list) and that refresh rebuilds from scratch and is charged again. The format parameter's summary/full trade-off is left entirely to the schema, which is acceptable given full coverage.

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 ('everything on file about one person') and enumerates its sections, then explicitly scopes it against cheaper alternatives: a brief, contact details. An agent can tell what this returns and what it is not 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?

It gives concrete trigger phrases ('tell me everything about her', 'background on him before the call') and explicit when-not routing: use contact details if you only need an email, use a brief if you want a short assessment, both flagged as cheaper. That is precisely the when/when-not/alternative structure that leads to correct tool 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?

Beyond the annotations, it discloses that the artefact is immutable once written, that a refresh is a separate paid write, that generation takes minutes and may return a link instead of content, that the call costs 50 credits and requires the Pro plan, and that ambiguous subjects are not charged. This is exactly the cost/permission/latency context the annotations (readOnlyHint=false, openWorldHint=true) do not convey.

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 front-loaded and the immutability rule leads, but it restates that point twice ('never edited afterwards' / 'the old one stays exactly as it was') and lists the same 50-credit price 24 times in the subject_type roster, which is avoidable padding. The required value list earns its place; the repetition does not.

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 paid, non-idempotent, open-world generation call, the description covers cost, plan gating, latency, caching semantics, immutability, disambiguation, and the full enum of subject types, and an output schema exists to cover return shape. Nothing an agent needs to call this correctly 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 coverage is 100%, so baseline is 3, but the description adds real meaning: it enumerates the 24 accepted subject_type values (the schema defers to the description rather than declaring an enum), explains the company parameter convention with a worked example ('Flock Safety' / 'flocksafety.com'), and clarifies that a bare website works as subject.

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+resource: a long-form written report on one subject, section by section, ending with sources. It explicitly contrasts itself with 'the short brief' that 'runs to a page' versus several thousand words, so an agent can distinguish this from lighter-weight siblings like get_snapshot or get_dossier.

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 concrete user phrasings that should trigger this tool ('I need the full write-up', 'proper due diligence before we commit', 'the long one') and spells out the re-request rule (cached report returned free unless new_report is set). It also handles the ambiguous-company case with a defined follow-up flow at no charge. It stops short of naming sibling tools as explicit alternatives, which keeps it from 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?

Beyond the read-only and non-destructive annotations, it discloses that the operation is free, performs no new lookup, and exposes only the current user's history. These billing, execution, and data-scope details are directly useful when deciding whether invocation is safe and 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?

The purpose is front-loaded and the examples are easy to scan, but the definition repeats the free/no-charge point and ends with a pricing link that is unnecessary for tool selection or invocation. It is clear but noticeably more verbose than needed.

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?

Together with the complete parameter schema, annotations, and output schema, the description supplies nearly everything needed to invoke this simple zero-required-parameter tool correctly. It could be more complete by defining what 'recently' means or explicitly directing agents to a sibling when they need fresh research or full report contents.

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 sole limit parameter already has complete schema documentation, including its range, default, and per-category behavior. The description adds no further parameter semantics, so the high schema coverage supports the baseline score.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies a history-listing operation covering researched people, requested write-ups, and previous calls, restricted to the current user. Emphasizing what was already looked up distinguishes it from siblings that perform fresh enrichment, scans, or report retrieval.

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 decision point—call this before paying for research that may already exist—and supplies three concrete natural-language use cases. The statement that nothing new is looked up also helps prevent using it as a substitute for fresh-research 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?

Annotations declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, but say nothing about cost. The description fills that gap with per-subject-type pricing, a free cached repeat, and no charge when the subject is unknown or thin — behavior an agent cannot infer from the annotations. It loses a point because the cost table is buried in prose rather than stated as a rule up front, and the interaction between new_report and billing is only fully clear 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?

Purpose and return shape are front-loaded, which is good, but the 23-item inline subject-type price list dominates the middle of the description and is delivered as undifferentiated prose. The free-repeat rule is stated twice in near-identical terms, and the pricing URL trails a sentence that has already moved on to the MentionFox check. It is informative but not tightly structured.

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 paid, open-world research tool with four parameters, the description covers everything an agent needs before spending credits: what it returns (text plus a shareable link), cost per subject type, caching behavior, the zero-result policy, and the sibling alternative. An output schema exists, yet the extra return detail is additive rather than redundant.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema: it justifies subject_type ('what matters about a founder is not what matters about a doctor') and supplies the full accepted-value list with prices, which the schema itself lacks (no enums). It does not add anything for the optional 'company' parameter beyond what the schema already says.

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 verb and artifact (a one-page brief on a single subject) and enumerates what the brief covers for each kind of subject: red flags with sources, leadership, funding, record highlights. It also names the sibling it is not — 'For the long version, use get_full_report' — so an agent can route between the two without opening either 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 explicit trigger phrases ('who is this', 'what should I know before I meet them', 'quick read on this firm') and an explicit alternative with the condition that selects it (get_full_report for the long version). It also states the free-repeat and no-charge-on-miss rules, which affect whether the agent should call at all.

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 read-only, open-world and non-destructive behavior, but the description adds substantial context the annotations cannot: a credit cost of 3 per source, the automatic MentionFox record check prepended to results, and the absence of person profiling. The one flaw is an internal inconsistency — 'looks across 55 places by default' versus 'a default run of five places is about 15' — which could mislead an agent about default scope and cost.

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 capability is front-loaded and the example phrasings are useful, but the text is chatty and padded with a pricing URL, credit arithmetic and a restated MentionFox behavior. The contradictory source counts (55 vs five) are wasted-and-confusing content rather than economy.

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 search tool with a full output schema, the description covers costs, default scope, special-case output (MentionFox check), and an exclusion to a sibling. The remaining gap is the unresolved default-source count, which matters because it drives both result breadth and credit spend.

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 defines topic, sources and hours_back with examples and bounds. The description adds only a vague 'you can narrow that' for sources and never mentions the hours_back parameter or its 1–24 cap, so it contributes little beyond the structured fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly conveys the resource (posts, comments, articles, videos mentioning a named topic) and the added signals (source, link, sentiment, buyer intent). It also separates itself from sibling tools by stating it 'does not build a picture of a person — for that, ask for a brief.' The verb is delivered indirectly through examples rather than a crisp statement, 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?

Concrete trigger phrases are supplied ('what are people saying about us today', 'did anyone pick up the launch', 'anything new on this topic this week'), plus one explicit exclusion pointing to the person-brief tool. It does not name the sibling tools directly (e.g. get_dossier, find_buyers_now), so the routing is clear in intent but not in exact tool identity.

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 budget: 25 credits and a few seconds of latency, an immutable snapshot that is never edited and never overwritten by re-checking, and a description of the four-outcome response shape plus the MentionFox prefix behavior. It also proactively discloses the tool's central limitation — "could not verify" means one search on one day in one place — which is exactly the failure mode an agent could misread. Consistent with annotations (non-idempotent, non-destructive, open-world).

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?

Effectively front-loaded: what it checks, what you get back, then the epistemic caveat, then use cases and cost. The anti-overreach paragraph is worth its length given the risk of an agent treating "could not verify" as "fraudulent," though it repeats the same point twice across two sentences. The pricing URL is a minor tail.

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?

Covers everything an agent needs despite an output schema being present: cost, latency, immutability semantics, the meaning of each of the four verdicts, and the conditional MentionFox prefix. Nothing material is left ambiguous for a call with one required free-text parameter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already defines all four fields, giving a baseline of 3. The description adds real guidance the schema doesn't: paste the material whole rather than extracting fields, since the claims are parsed out of the input — which explains why name/title/employer are all optional and secondary. It stops short of describing how the optional fields interact with the parsed input.

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 ("checks those particular claims against the official lists that would record them") scoped to a concrete class of claims: doctor, lawyer, broker, professor, company director. This is clearly distinct from siblings like enrich_person or get_dossier, which build a profile rather than adjudicate credential claims.

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?

Gives several concrete trigger phrasings ("is this person who they say they are", "check this expert before I quote them", "should I trust this pitch") that map intent to the tool. It also bounds the answer set (it will never conclude someone is fake), which steers interpretation. What's missing is explicit routing to siblings — nothing says when to prefer enrich_person or compare_people instead.

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