AssessAll Assessment Catalogue

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 the safety profile is fully covered by structured data. The description adds that pricing is 'one-time' in two currencies, which is useful context, but says nothing about failure behavior for a bad slug or whether data is cached/live. Against an annotated read-only tool, a 3 is appropriate.

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

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

One tightly packed sentence with no filler; the resource and returned fields are front-loaded and the sourcing constraint appears at the end where it reads naturally.

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?

No output schema exists, so the description's enumeration of returned fields (description, link, category, dual-currency price) carries real weight and tells the agent what to expect. It is nearly complete for a trivial single-parameter lookup; only error behavior for an unknown slug 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% and the single slug parameter is documented in-schema with an example ('apt-numerical-graduate'), so the schema does the heavy lifting. The description only restates that the slug originates from search_assessments, adding marginal value beyond the schema's own note. 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 (retrieve one assessment) plus the exact fields returned: description, link, category, and one-time INR/USD price. It also distinguishes itself from the sibling search_assessments by identifying that tool as the source of the slug, so an agent can tell 'search many' from 'fetch one' 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 states the workflow dependency clearly: the slug must come from search_assessments, which implies search first, then fetch details. It does not spell out when NOT to use it (e.g., for practice tests or guides, which are separate siblings) or what to do with an invalid slug, so it stops short of full explicit guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful non-structural context (no account required, scoring happens client-side, results tie back to a paid assessment), but says nothing about volume, ordering, or what a result entry looks like.

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

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

A single compact sentence with no filler, and the key qualifier ('free ... no account') is front-loaded. The trailing clause about the paid assessment it rehearses is slightly convoluted but still earns its place by explaining the content relationship.

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 parameters and no output schema, the description is the only place an agent could learn the shape of the returned list, and it does not describe item fields (names, URLs, which assessment each maps to). Adequate for deciding to call it, thin for predicting 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?

The tool takes no parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No misleading parameter claims are made.

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 the resource as the set of free practice tests on assessall.com, including their defining traits (no account, instant in-browser scoring, each paired with a paid full-length assessment). That is enough for an agent to know what it will get, but it never contrasts itself with siblings like search_assessments or get_assessment, and the listing verb itself is only implied by the name.

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

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

There is no statement of when to call this versus search_assessments, get_assessment, or search_guides. The 'free / no account' framing hints at a browse-style use case, but the agent must infer it rather than being told.

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 genuine value beyond them by disclosing what comes back (titles, links, categories, one-time prices in both INR and USD) and that the catalogue is public, which matters since there is no output schema.

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

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

Two sentences, no waste, and the core action plus resource is front-loaded before the example list and the return-value clause. The examples each earn their place by illustrating a different query axis (skill, role, language/context, compliance).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description correctly compensates by summarising the return fields, and it makes the public/unauthenticated nature of the catalogue clear. What remains unaddressed is result-set behaviour: nothing about default page size, the 1-25 limit range, or whether more results exist beyond the cap.

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 67%, and the description extends the bare "What to measure, for whom, or why" with concrete query patterns ('numerical reasoning', 'first-time manager', 'POSH committee'), giving the agent a real sense of the query's semantic space. It does say prices are returned in INR and USD, which contextualises the USD-only price filter, but it says nothing about `limit` or the semantics of `max_price_usd`.

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 ("Search") and a precise resource ("AssessAll's public catalogue of online assessments") with the qualifying dimensions spelled out (skill, role, purpose, keyword). The concrete query examples further pin down what counts as in-scope, which implicitly separates it from practice tests and guides, 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?

The phrasing "by skill, role, purpose or keyword" and the sample queries imply when to reach for this tool (exploratory discovery against the catalogue). However, it never states when NOT to use it or points to get_assessment/list_practice_tests/search_guides for adjacent needs, so the routing decision is left 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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description earns credit beyond that by disclosing the return shape ("titles, one-line summaries and links"), which matters because there is no output schema. It stops short of explaining ranking or result-volume behavior.

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, no filler, with the corpus definition and topical scope front-loaded and the return shape trailing. Every clause earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully supplies the return shape and the domain of the index, which is enough to call the tool correctly. The remaining gap is the undocumented `limit` ceiling and any indication of result-set size or ranking.

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 0%, so the description must carry the burden. The topic enumeration gives real guidance on what a useful `query` looks like, but `limit` (default 6, max 15) is never mentioned in the description or schema, leaving one of two parameters undocumented.

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 ("Search") and a specific resource ("AssessAll's guides on assessment practice") and enumerates the topical coverage, so an agent knows exactly what corpus is being queried. It contrasts implicitly with search_assessments via the noun "guides," but never names that sibling or states the distinction outright.

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

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

The topic list implies when this tool is appropriate (conceptual/best-practice questions about validity, reliability, cut scores, CEFR, 360 feedback, etc.), but there is no explicit when-to-use or when-not clause and no pointer to search_assessments or list_practice_tests for adjacent needs. Usage must be inferred from the subject matter.

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