site

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

No annotations are supplied, so the description carries the full burden. It does imply a read-only introspection and discloses the returned content (columns, numeric flags, row count, provenance banner), which is useful since there is no output schema, but it says nothing about permissions, cost, or output format.

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 short sentences with no filler. The returned-content list is front-loaded, though the call-to-action ordering hint trails at the end rather than leading.

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 compensates by enumerating the four things returned, which is enough for an agent to know what it gets. It could say more about the shape of those values, but nothing essential is missing for a zero-argument introspection 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?

The tool takes zero parameters, so there is no parameter surface to document and the baseline is 4. The description correctly implies the call is argument-free and dataset-scoped.

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 resource (Immigration Adviser Finder dataset) and enumerates what the tool returns: columns, numeric flags, row count, and provenance banner. It is clearly a schema-introspection tool and reads differently from dataset_row or dataset_search, though it does not explicitly distinguish itself from the overlapping dataset_provenance and dataset_stats 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?

"Call this first to learn the schema" gives clear sequencing guidance that tells the agent when in a workflow to reach for it. It stops short of naming alternatives or stating when not to use it, so it sits at clear-context-without-exclusions.

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?

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses that multi-value membership is against a single column and that result order follows the given value order, but says nothing about return shape, whether full rows come back, or any result-size 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?

A single sentence with no filler, though it is structured as a noun phrase rather than an imperative and the most actionable cue ('for X vs Y questions') is deferred to the end rather than front-loaded.

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 and no annotations, the description should say more about what comes back (full rows? matched column values? ordering of results relative to values?) and about any result limits. It covers the input contract adequately but leaves the output contract entirely to inference.

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 compensate, and it does: 'column is any of the given values' clarifies membership semantics (OR across values on one column, not pairwise matching) and 'in the order given' explains that the values array controls output ordering. It still does not mention the 2–10 item bounds, which the schema enforces silently.

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 concrete resource (rows of the Immigration Adviser Finder dataset) and the filter operation (column matches any given value), which is specific enough to distinguish it from siblings like dataset_row or dataset_search. It lacks an explicit verb and never explains the 'compare' framing beyond the 'X vs Y' hint, but the mechanism is recoverable.

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?

'for "X vs Y" questions' gives an implied usage context, but there is no explicit when-not guidance and no sibling tool is named as the alternative (e.g. dataset_row for a single record, dataset_search for free text). The agent must infer the routing itself.

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?

With no annotations, the description carries the full behavioral burden, and it implies a safe, non-mutating metadata read by describing only static descriptive fields. It does not disclose whether the dataset is versioned, whether the licence terms change, or whether the result can fail/stale-date, so gaps remain for a tool with zero annotation coverage.

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 filler: the first front-loads what is returned, the second states the reason to call. Nothing is redundant with the title.

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 parameterless read tool with no output schema, the description usefully enumerates the return fields (source, date, licence, citation), effectively standing in for a missing output schema. Only the exact shape/format of the citation and licence text is left unspecified.

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 zero parameters, so the baseline is 4. There is nothing input-side for the description to disambiguate.

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?

Names the resource precisely (provenance metadata for the Immigration Adviser Finder dataset) and enumerates the returned content: source, computed date, licence, and citation. It is clearly distinguishable from dataset_stats, dataset_columns, dataset_row, and dataset_search, though it never names a sibling to contrast against.

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?

"Read this to attribute a figure correctly" gives a concrete triggering condition — calling it when a figure must be cited or attributed. No exclusions or alternative tools are named, but the usage context is unambiguous.

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?

With no annotations, the description discloses the key behavioral trait of case-insensitive exact matching. However, it does not cover read-only safety, permissions, result limits, or return behavior, leaving some burden unmet.

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, front-loaded sentence that states the dataset, condition, and matching behavior without any wasted words.

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 two-parameter lookup, the description adequately explains the filter semantics and implies a rows-based return. It lacks explicit output formatting or pagination details, but no output schema exists and the tool is low complexity.

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 compensate, and it does: it explains the relationship between column and value and specifies the case-insensitive exact comparison. It still does not enumerate valid column names or value formats.

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 the resource (rows of the Immigration Adviser Finder dataset) and the filter condition (column equals a value exactly, case-insensitive). It is clear enough to distinguish an exact-match lookup from broader siblings like dataset_search, though it does not name those alternatives.

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 exact, case-insensitive column-value condition implies when this tool is appropriate, but it gives no explicit when-to-use guidance or alternatives such as dataset_search. It is minimally enough to infer the usage context.

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?

With no annotations, the description carries the full burden. It usefully discloses case-insensitive substring matching across any cell and a hard 50-row cap, but says nothing about ordering, pagination beyond the cap, or what happens when the cap truncates results — material for a search tool whose result set can be silently clipped.

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 sentence that front-loads the resource, the match semantics, and the result cap. No filler.

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, so the description must convey the return shape. 'Rows of the dataset' is roughly sufficient to convey a row collection, but the fields per row and the behavior when more than 50 rows match are left unspecified.

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 50% (only query documented). The description compensates: it defines query as a cell-level case-insensitive contains match and explains that limit is capped at 50, adding meaning beyond the bare integer maximum in 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 the operation (return rows whose cells contain the query) against a named resource (the Immigration Adviser Finder dataset) and bounds the result, so an agent knows exactly what it returns. It does not explicitly contrast itself with siblings like dataset_top or dataset_row, but the substring-match semantics are distinctive enough.

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: 'cells contain the query' suggests free-text lookup, but there is no statement of when to prefer this over dataset_top, dataset_row, or entities_search, nor any precondition. Minimum viable at best.

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?

No annotations are provided, so the description carries the full burden, and it does add real behavioral detail: grouping commas and currency symbols are normalized before parsing, and non-numeric rows are excluded and counted rather than erroring. It does not state what happens if the named column is entirely non-numeric or how the excluded count is surfaced, leaving a modest 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?

One sentence, front-loaded with the list of computed statistics, followed by the important parsing/exclusion caveats in a compact parenthetical. Dense but every clause carries information; no redundancy.

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 annotations and no output schema, the description does the key work of enumerating the returned values and the data-handling semantics. What is missing is minor: behavior on an all-text or nonexistent column and how the excluded-row count is reported.

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 single 'column' parameter has 0% schema description coverage, so the description must compensate. It adds that the column must be numeric and belong to the Immigration Adviser Finder dataset, but gives no naming format or example, so the guidance is only partially compensating for the schema gap.

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 specific resource (a numeric column of the Immigration Adviser Finder dataset) and enumerates exactly which statistics are computed (count, min, max, mean, median, sum), so an agent knows precisely what the tool produces. It does not explicitly contrast itself with siblings like dataset_top or dataset_compare, so it stops 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?

Applicability is implied by the 'numeric column' qualifier, which tells the agent this tool only makes sense for numeric fields, but there is no explicit when-to-use guidance and no routing to sibling tools for non-numeric summaries or ranked views.

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?

No annotations, so the description carries the full behavioral burden, and it discloses little beyond 'returns the highest/lowest rows'. It does not mention the 50-row cap, what happens with a non-numeric or unknown column, ordering ties, or anything about the returned shape.

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 front-loaded sentence with no filler; the extremal case is stated before the example. Slight redundancy with the title ('numerical column' / 'highest or lowest rows') keeps it just short of ideal.

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 3-parameter tool with no annotations and no output schema, the description omits the default limit, the cap behavior, return shape, and error conditions for invalid columns. An agent can guess the happy path but not the failure modes.

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 only 33% (only 'ascending' is documented). The description usefully adds that 'column' must be numeric, which the schema does not state, but it says nothing about 'limit' or the default row count, leaving half the 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+resource (rank rows of the Immigration Adviser Finder dataset) and the operative parameter class (a numeric column), with an example question ('which is the most/least X') that pins the intent. It does not name or exclude siblings like dataset_stats or dataset_row, so differentiation relies on the reader's inference.

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 'which is the most/least X' framing implies the usage context (extremal lookup rather than aggregate or search), but there is no explicit when-to-use/when-not guidance and no named alternative such as dataset_stats for aggregates or dataset_search for filtering.

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?

With no annotations provided, the description carries the full burden and does disclose key behavioral facts: nothing is bought/ordered/paid, no quote is guaranteed, and it is free. It also states what it returns (who receives the details, consent wording, confirmation mechanism). It stops short of noting read-only nature explicitly or any rate/format details.

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 'Read first' directive followed by the concrete scope. Each sentence earns its place by covering purpose, disclaimers, and return contents, though the phrasing is slightly loose in places.

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, no annotations, and no parameters, so the description must stand alone — and it adequately explains what the tool returns (recipients, consent wording, confirmation flow) for an informational describe tool. Minor gaps remain around return format, but nothing essential 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?

The tool takes zero parameters, which is the baseline for a 4 per the rubric. The description correctly does not invent parameter semantics, and the empty schema is consistent with an informational describe tool.

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+resource: it describes/explains what submit_enquiry does on Immigration Adviser Finder. It explicitly distinguishes itself from the sibling submit_enquiry by clarifying that this tool 'states plainly what submit_enquiry does' and returns metadata like consent wording and recipient details, rather than performing the enquiry.

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?

'Read first' is an explicit directive placing this tool ahead of submit_enquiry in the workflow. It implies the when-to-use condition (before submitting an enquiry) and the contrast with the sibling, but does not spell out alternatives or exclusions beyond that ordering hint.

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?

No annotations are provided, so the description carries the full burden. It usefully describes the output content (key, label, type, required, help text, options) and hints that answers should be passed to submit_enquiry, but it does not explicitly state that this is a read-only operation or mention any side effects, permissions, or caching behavior. Minimum viable for a metadata tool.

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, front-loaded with what the tool returns and followed by a concise usage hint. No filler, every word 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?

For a simple metadata tool with no input parameters, no output schema, and no annotations, the description is complete: it lists the exact fields returned and explains how to use the output with submit_enquiry. Nothing an agent needs 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?

The input schema has zero parameters, so per the rubric the baseline is 4. The description adds no parameter information because none exist, and none is needed.

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 exactly what the tool returns: 'Every field of the Immigration Adviser Finder enquiry: key, label, type, whether required, help text and the allowed options where there are any.' It clearly distinguishes itself from the sibling submit_enquiry by noting 'Pass answers to submit_enquiry keyed by field key.' An agent can tell this is a field-discovery tool, not a submission tool.

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 usage: get the fields here, then pass answers to submit_enquiry keyed by field key. It does not explicitly state 'use this before submit_enquiry' or list when-not-to-use conditions, but the context is clear enough for an agent to infer the correct workflow.

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?

With no annotations, the description carries the full disclosure burden and does so well: it states the auth requirement (Authorization: Bearer), a metering constraint (pages metered per key per day), and the fallback behavior when no key is supplied (the response explains how to obtain one). It omits anything about rate-limit consequences or partial/error responses, so not a full 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?

Three tight sentences with the core purpose front-loaded and operational constraints appended; no filler. Slightly dense but every clause carries information (scope, page size, auth, metering, no-key behavior).

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 2-parameter export tool with no output schema, the description covers the key operational facts an agent needs: what it returns (every entity, with provenance), pagination shape, and auth/metering. The remaining gap is the exact page/response structure, which the absence of an output schema leaves slightly under-specified.

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 compensate. It adds real meaning for pageSize ('200 a page', matching the maximum=200) and implies pagination via 'in pages', but says nothing about the semantics of the page parameter (e.g., 1-based, ordering, bounds), 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 action and resource: exporting every entity of the Immigration Adviser Finder register, in pages of 200, with provenance. An agent can distinguish 'whole register' bulk export from the search/lookup siblings like entities_search and entity_lookup. It stops short of naming an alternative explicitly, so it is clear but not sibling-differentiating.

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 by 'the whole register' — reach for this when you need everything rather than a filtered subset. However, no alternative is named and no explicit when-not condition is given, leaving the agent to infer that entities_search/entities_in handle targeted retrieval.

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses paging ('50 a page'), but says nothing about read-only semantics, auth/scoping requirements, return shape, or sort order for a listing tool.

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 front-loaded sentence with no wasted words. The region scope and paging note are stated up front, though the phrasing is slightly dense.

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 and 0% param coverage, the description should say more about what a page of entities looks like and how page/pageSize behave. It covers region and service but leaves return content and pagination controls thin for a 4-param listing 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 description coverage is 0%, yet the description usefully clarifies that region accepts an id or a name and that service is optional — meaning beyond the bare schema. However, the page and pageSize parameters are never explained (defaults, interaction), leaving half the params 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 resource (Immigration Adviser Finder register entities) and a clear scope (one region). It's distinguishable from entities_search/entity_lookup at a high level, though it never names those siblings. The verb is implicit ('register entities') but the intent is clear.

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 hints that region is required and service is an optional narrowing filter, but gives no explicit when-to-use guidance and never mentions alternatives like entities_search, entity_lookup, or entities_export. An agent must infer routing from the sibling list alone.

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?

No annotations are supplied, so the description carries the full burden, but the tool takes zero parameters and is a metadata read, so the behavioral risk surface is inherently small. The description discloses the shape of what comes back (fields, counts, regions, services, identifier schemes, citation) yet never states it is read-only, side-effect free, or cached, leaving the safety profile to inference.

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 content is front-loaded and the imperative "Call this first" lands at the end as an actionable hook. It is slightly dense as a single run-on list, and the duplicated word in "register register" is a small editorial defect that briefly disrupts reading.

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 and no annotations, the description must convey what a caller gets back, and it does so by naming the six categories of information returned plus the citation purpose. It stops just short of completeness by not indicating format, size, or whether the values are static, but for a parameterless metadata tool this is sufficient to 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?

The input schema declares zero properties, so there is nothing for the description to disambiguate and the baseline of 4 applies. No parameter semantics are needed or missing.

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 enumerates exactly what the tool returns: field inventory, entity counts, regions, services, identifier schemes, and citation guidance for the Immigration Adviser Finder register. That is specific enough to separate it from entities_search, entity_lookup and entities_export, but it never contrasts itself with the overlapping metadata siblings dataset_columns, dataset_stats or dataset_provenance, so differentiation is only partial.

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?

"Call this first" is an explicit, actionable sequencing instruction that tells the agent when to reach for this tool relative to the rest of the toolset. However, it gives no when-not conditions and does not say how it relates to the other metadata tools it overlaps with (e.g. dataset_columns), so the routing guidance is clear but not exhaustive.

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?

With no annotations, the description carries the full behavioral burden. It discloses the maximum result size (50 rows) and the searchable fields, but does not cover read-only nature, pagination, default limits, or authentication requirements.

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 a single dense sentence that is appropriately sized and front-loads the core search target. It wastes little space, though it could be slightly more scannable.

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 search tool with no annotations, no output schema, and 0% parameter description coverage, the description covers core search semantics and filters. It still omits default limit behavior, pagination, and whether q is required or optional.

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 compensate. It explains q as matching name, commercial name, website, address, or authority; region as accepting id or name; service as accepting slug or name; and constrains output to 50 rows.

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?

Describes a search over entities in the Immigration Adviser Finder register, specifying which fields are matched. The purpose is clear, but it does not explicitly differentiate this tool from siblings such as entity_lookup, entities_in, or dataset_search.

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 usage by describing optional region and service filters, along with a result cap. However, it does not explain when to use this tool instead of alternatives like entity_lookup or entities_in.

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?

With no annotations, the description carries the full burden and does disclose that matching is exact and that the whole record plus its page is returned. It is silent on the not-found/error case and on the fact that slug and scheme+value are alternative (not cumulative) lookup paths, which is behavior an agent needs.

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 tight sentences; the resource and its two lookup keys are front-loaded, and no clause 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 no-annotation, no-output-schema lookup, it covers the key inputs and the return shape ('whole record with its page'), but leaves the mutually exclusive use of slug vs. scheme+value and the failure behavior 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 coverage is only 33% (scheme is the sole documented parameter), so the description must compensate, and it does by explaining that 'value' is the identifier value paired with 'scheme' (e.g. lei) and that 'slug' addresses the entity's page. This adds real meaning beyond the bare schema types.

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+resource: retrieves the Immigration Adviser Finder register entry for a firm, keyed either by register identifier (scheme + value) or by page slug. This clearly separates it from the entity listing/search siblings, though it does not name any sibling 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?

'Exact match' implies the tool is for when you already hold a known identifier or slug, which contrasts with searching, but that contrast is never made explicit and no alternative such as entities_search is named. Usage is therefore only implied.

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?

With no annotations, the description carries the full burden and does so: it discloses the consent semantics verbatim, the validation-only nature of step 1, that submission is gated behind an email link the person must click before any provider sees the data, and exactly what step 1 returns. This is well beyond a restatement of the name.

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 two-step framing and the critical 'not a purchase' caveat before procedural detail. It is dense and somewhat long, and the consent statement appears twice (once in prose, once quoted), which is mild redundancy rather than waste.

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, consent-gated submission tool with no annotations and no output schema, everything an agent needs is present: prerequisites, the exact two-call sequence, what each call returns, and the downstream email-verification gate. No material behavior is left undisclosed.

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 fields are already documented, but the description adds flow-level meaning the schema cannot: answers are keyed by field key from enquiry_fields, consent is the gating boolean, and confirmation is the token returned by step 1 and reused in step 2. That cross-parameter sequencing is genuine added value.

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 (submits an enquiry to Immigration Adviser Finder) and immediately disambiguates scope: 'NOT a purchase, NOT a guaranteed quote'. This separates it from adjacent enquiry_* siblings by naming the exact artifact being created.

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 prescribes a two-step protocol: step 1 when validating, step 2 only after the person approves. It names the trigger condition for the second call ('only if the person agrees') and the required inputs for each step, leaving no inference to the agent.

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