nophi.sh

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

Annotations already declare readOnly/idempotent/non-destructive, so safety is covered. The description adds real behavioral context beyond that: the Enterprise-on-quote fallback above the largest plan, the four possible status values, and the fallback behavior ('contact address given') when no public fact exists. Pagination/side effects are irrelevant for a read-only check, so this is strong.

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 in the first sentence, followed by inputs and then return values in a logical order. The return-value sentence is long and dash-heavy, but nearly every clause carries information an agent needs.

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 explaining return values, and it does so thoroughly: plan selection, prerequisites, per-need status taxonomy, known gaps, and trial link. Minor gaps remain around how free-text needs are matched and what 'see_facts' entails.

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 schema already documents needs keys, free-text fallback, language enum, size bounds, and provider enum. The description largely restates the parameter list ('company size, mail provider, up to 20 needs') without adding syntax or format meaning, 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?

The description states a specific resource ('fit check for one company') and enumerates what comes back: plan for the size, mail prerequisites, per-need statuses, gaps, and trial link. It is clearly narrower than siblings like get_pricing or get_overview, though the verb 'fit check' is slightly informal.

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 notes that all inputs are optional, which implies you can call it with partial data, but it never says when to prefer this over get_pricing or get_deliverability_prerequisites despite their overlap. Usage is inferred rather than 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 readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so safety and repeat-call behavior are covered structurally. The description adds that results are organized per provider and that Google/OVH entries are guidance delivered on request, which is genuinely useful context beyond annotations. It does not say anything about response format or ordering, though for a static reference tool that is a minor gap.

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 sentence, which is efficient, but that sentence is a dense stack of parentheticals ("Advanced Delivery, with the sending IPs and domains", "guidance on request") that slows comprehension. Front-loading the core purpose before the provider detail would read considerably better.

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 roughly what comes back, and it does enumerate the per-provider content an agent will receive. Two parameters with full schema coverage keep the surface small, so the definition is close to complete; only the untested language parameter and the response shape remain 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 coverage is 100%, so both parameters are already documented, and the description's only parameter comment — the optional mail_provider filter — restates what the schema says. The language parameter (fr/en output language) is never mentioned in the description, so no meaning is added there. 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 states a concrete verb-and-resource: it returns mail-system configuration required for simulation e-mails to land in inboxes, broken out per provider with named providers (Microsoft 365, Google Workspace, OVH) and the own-domain/own-mailbox option. That is specific enough to distinguish it from informational siblings like get_security_and_data or get_pricing, though it never names those siblings 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?

Usage is implied rather than stated: an agent can infer this is reference lookup to run before sending simulation e-mails, and the mention of an optional mail_provider filter hints at narrowing. There is no explicit when-to-use/when-not, no prerequisites stated, and no routing to a sibling even though several siblings are also informational lookups.

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=false and destructiveHint=false, so the safety profile is fully covered structurally. The description adds one genuinely new behavioral fact beyond that: the content is public and requires no account, which tells the agent no auth flow is needed before calling. It stops short of noting rate limits or answer size, keeping it at a 4 rather than 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?

It is a single front-loaded sentence: the subject is identified first, then the contents are listed compactly with no filler. The parenthetical catalogue inventory is slightly dense but every item conveys real scope 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 no output schema, the description must convey what comes back, and it does so by enumerating the covered topics including explicit negatives ('features not included') and trial terms. For a simple, single-parameter read-only tool this is close to sufficient; only the answer's shape/length is 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 optional parameter with 100% schema description coverage and an explicit fr/en enum, so the schema already carries the semantics. The description never mentions the language parameter, adding nothing beyond the schema — the baseline 3 applies when coverage is this high.

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 opens with a specific verb+resource framing ('Summary of nophi.sh, a phishing-awareness training service') and then enumerates exactly what the summary covers: audience, capabilities, the 5-step workflow, catalogue sizes, excluded features, and trial terms. This implicitly separates it from siblings like get_pricing or list_courses, but 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?

Usage is only implied: the enumeration of contents makes clear this is the orientation/overview call, and 'Public facts; no account needed' establishes a prerequisite. There is no explicit statement of when to prefer this over get_pricing, get_template_categories, or compare_fit, so an agent must infer the routing.

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 closed-world, so the safety profile is covered structurally. The description adds genuinely useful behavioral context beyond that: prices are in EUR and exclude VAT, both monthly and annual billing figures are returned, Enterprise is quote-only above the largest plan, and the trial is 14 days with no card required. It does not discuss freshness of pricing data or response shape, which keeps it from a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

One dense sentence with no throat-clearing, and the most important element (plans, limits, prices) leads. The parenthetical stacking of billing and tax qualifiers makes it slightly run-on, but every clause carries real 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 no output schema, the description must convey what comes back, and it does: plan tiers, user limits, EUR ex-VAT prices in two billing modes, an Enterprise quote tier, and trial terms plus signup link. What is missing is the shape of the returned data (per-plan structure, whether annual figures are totals or per-month equivalents), which matters for a pricing 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?

There is a single optional parameter with 100% schema description coverage (a fr/en answer-language enum with default 'en'), so the schema already does the work. The description says nothing about language handling or localization, so it adds no meaning over the schema. Baseline 3 applies when schema coverage is 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?

The description names the exact payload: plans with user limits, EUR prices excluding VAT on monthly and annual billing, an Enterprise quote tier, and 14-day trial terms with a signup link. That is far more specific than the bare name/title and separates it from content siblings like get_overview or get_security_and_data. It stops short of 5 only because there is no explicit verb (e.g. 'Returns...') anchoring what the tool does.

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 content listed, which suggests it is the pricing/plan-comparison lookup, but the description never states when to call it or when a sibling such as compare_fit or start_trial_link is the better choice. Given that a trial-signup sibling exists and the description mentions the signup link, the absence of any routing guidance 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?

The annotations already establish that this is a read-only, idempotent, non-destructive, closed-world operation, so the description does not need to restate that safety profile. It adds useful behavioral context by defining topic coverage, stating that out-of-scope questions are not handled, and explaining that the answer includes a contact address for those cases.

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 efficient and front-loads the content scope, with no filler sentences. The first sentence is a dense list of topics, which is useful but could be easier to scan if structured more clearly.

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 tool with one fully documented optional parameter and rich annotations, the description supplies enough context: what content is returned, that dates are included, and how out-of-scope topics are handled. No output schema exists, but the description adequately explains the return subject matter.

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 only one optional parameter, language, and the schema fully documents it with an enum and default at 100% coverage. The description adds no meaning beyond the schema for that parameter, so the baseline score of 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 precisely identifies the returned resource: security questionnaire answers with dates, then enumerates covered security and data topics. It also draws a clear boundary around out-of-scope topics, making the tool distinguishable from the other product-information 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?

It clearly indicates when the tool is appropriate by listing the covered topics, and it says topics outside that list are not covered and should use the included contact address. It does not name an alternative sibling tool, but none of the listed siblings appears to cover security questionnaire answers.

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, so safety is covered. The description adds value beyond them by disclosing the return payload's shape (per-language and per-difficulty counts, repeat-clicker course assignment, QR-code totals), which matters because there is no output schema. It does not mention caching or size, but for a small 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 sentences, zero preamble, with the payload contents front-loaded and the sibling linkage placed last where it acts as a next-step pointer. The middle enumeration is dense but every item maps to a real returned field 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?

For a one-parameter, no-output-schema, read-only lookup, the description covers both what comes back and how the result feeds another tool. Nothing an agent needs in order to call this correctly and use the response is missing, aside from the minor language-scope nuance.

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 single `language` parameter is fully documented with an enum and default, so the baseline of 3 applies. The description says counts are broken out 'per language' but never clarifies whether the `language` parameter controls labels only or filters the returned counts, which is the one ambiguity the schema does not resolve.

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

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

States a specific resource (phishing simulation template categories) and immediately enumerates its contents: key, label, counts per language and difficulty, repeat-clicker course, and total/QR-code counts. That specificity is enough to distinguish it from siblings like list_simulation_templates or get_overview 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 second sentence explicitly ties this tool to a sibling: 'The category keys are the values accepted by the category filter of list_simulation_templates.' That gives the agent a concrete discovery-then-filter workflow. It stops short of a full when/when-not statement (e.g. does not say whether to call this before or instead of list_courses for course data), so it is clear context rather than exhaustive routing.

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 safety (readOnly, idempotent, non-destructive, closed-world), so the description's job is content shape — and it delivers by listing the per-course fields (title, description, lesson count, duration, quiz questions, passing score) plus the assignment-after-click behavior and practice exercise. It adds no caveats about size, pagination, or ordering of the returned catalogue, which is the remaining gap.

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 resource and its grouping are front-loaded, and every clause carries information about returned content. The parenthetical theme list and the trailing clauses about assignment and practice exercise make the single sentence dense and slightly run-on, but nothing is redundant.

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 rightly spends its words on returned fields, which makes the tool callable with confidence. However, it omits practical call details an agent would want — whether the catalogue is large, how many courses are typically returned, and what the language parameter changes — leaving it adequate rather than complete.

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 both parameters are already documented, including the enum meanings and the language default. The description restates the theme filter but does not explain the language parameter or how theme grouping relates to the filter, so it adds little beyond the schema 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 (security-awareness course catalogue) and enumerates its grouping and per-course contents, so an agent knows exactly what data comes back. The verb is implicit in 'catalogue' rather than stated as 'list', and there is no explicit contrast with the nearest sibling list_simulation_templates, keeping it short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The only usage cue is 'Optional filter: theme', which implies this is the broad enumeration tool, but nothing states when to prefer it over list_simulation_templates or compare_fit. Usage is inferable from the resource name rather than spelled out.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description's genuine additions are the metadata-only payload boundary and the pagination contract ('the result includes total and next_offset'), which is useful. Beyond that it adds little on filtering semantics or default ordering, so with annotations carrying most of the load a 3 is fair.

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 compact sentences that front-load the resource, then the payload, then the pagination mechanics. The staccato list style is dense but each clause carries information; there is no filler. Slight readability cost from the compressed phrasing.

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, filtered list tool with no output schema, the description covers payload shape, pagination, and result envelope (total, next_offset) — enough to call it correctly on the first attempt. Minor gaps remain around default sort order and what an empty page looks like, but nothing blocking.

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 enum listings and the language nuance, so the schema already explains every parameter. The description restates limit (1-100, default 20), offset, and the optional filters without adding format, interaction, or ordering rules the schema lacks. Baseline 3 applies 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?

Opens with a specific verb and resource ('E-mail phishing simulation templates') and enumerates what each record contains (name, category, difficulty, QR-code flag, red-flag titles, assigned course). The scope is sharply bounded by 'Metadata only (no e-mail bodies, no links)', so an agent knows exactly what it gets. It does not, however, contrast itself with siblings like get_template_categories or list_courses, which leaves the differentiation work to 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?

Gives clear operating context: one language per call, optional category/difficulty filters, and paged retrieval with limit/offset. It implicitly tells the agent what this tool cannot do (no body content, no links), steering it away from expecting full template text. What is missing is an explicit 'use this instead of X when Y' statement naming a sibling.

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, so the safety profile is covered. The description adds genuinely new behavior beyond that: it returns a link only, creates no account, sends no e-mail, and simulations can only target the caller's own company e-mail domain. That is the kind of side-effect and constraint disclosure an agent cannot get from the annotations.

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 fact, a link to the signup URL, is stated first, and the no-account/no-email caveat is kept short. The opening clause about the steps a person completes is slightly compressed and reads awkwardly before the enumeration, but nothing is redundant.

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-optional-parameter tool with no output schema, the description covers the return value (a link), the non-effects, and the domain constraint, which is enough to call it correctly. It could go further on whether the link is stable across calls, though the idempotent annotation partly covers that.

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 single language parameter is fully documented in the schema with its enum and default. The description says nothing about the language parameter, so it adds no meaning beyond the structured data; 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 identifies a specific resource (the signup URL of a 14-day card-free free trial) and what it returns, so the agent knows exactly what this yields. It does not explicitly contrast itself with informational siblings such as get_pricing or compare_fit, so the sibling differentiation is missing.

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: this is the tool to hand someone who wants to begin a trial, and the described steps make the flow clear. There is no explicit statement of when to prefer it over get_pricing or compare_fit, and no prerequisites or exclusions are given.

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