onfido

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

Annotations already declare destructiveHint=true, so the bar is lower. The description adds valuable behavioral context beyond that: it creates PII, runs no verification check, and costs nothing. It stops short of disclosing auth requirements, return format, or what happens to the created record.

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 short sentences, front-loaded with the core action and endpoint, followed by a critical scope clarification. Every sentence earns its place with 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?

Given the full schema descriptions and the destructiveHint annotation, the description covers the essential behavioral context (no check, no cost, PII record). It could be richer by mentioning the return value or any authentication requirements, but it is largely complete for a simple creation tool with no output schema.

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 parameter semantics are already fully documented in the input schema. The description adds no parameter-specific meaning, which is acceptable given the high coverage but earns only 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?

States a specific verb (creates) and resource (applicant/person record) and includes the exact API endpoint. The added phrase 'runs NO verification check' implicitly distinguishes it from the sibling check/report tools, so an agent can select it correctly without ambiguity.

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?

Clearly signals when to use it: to create a PII record without running verification and at no cost. However, it does not explicitly name alternatives (e.g., update_applicant for existing records) or state prerequisites such as required fields, leaving some routing 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.

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

The readOnlyHint=true annotation already establishes this is a safe read, lowering the bar. The description adds the concrete REST endpoint (GET /applicants/{applicant_id}), which is mild contextual value, but it says nothing about authentication, 404 behavior for a missing id, or the record returned.

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, front-loaded with the operation and followed by the endpoint. No filler or 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?

For a one-parameter read tool whose safety profile is covered by annotations and whose schema is fully documented, the description is essentially sufficient. It omits error/empty-result behavior, which is a minor gap given there is no output schema.

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 parameter is documented there, so the baseline is 3. The description's 'by id' restates the identifier's role without adding format, constraints, or examples beyond 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?

The description states a specific verb ('Retrieve') and resource ('single applicant record by id'), making clear it is the single-record read counterpart to onfido_list_applicants. It does not explicitly name a sibling to contrast with, so it falls short of the top tier despite being unambiguous.

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 guidance on when to choose this tool over onfido_list_applicants or the other get_* siblings, nor are prerequisites or exclusions mentioned. Usage is only implied by the tool name and the word 'single'.

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?

readOnlyHint=true already tells the agent this is a safe non-mutating read, so the description's disclosure burden is light. It usefully adds the shape of what comes back (status, report ids, result), which matters because there is no output schema, but says nothing about auth, rate limits, or missing-id 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 tight sentences with the identifier and return contents front-loaded, plus the underlying endpoint reference. No filler whatsoever.

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 single-resource fetch with a fully documented id parameter, this covers purpose, input, and rough return shape, which compensates for the absent output schema. Only the lack of any usage routing (list vs get) leaves a small gap.

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 parameter and schema description coverage is 100%, so 'The check id.' in the schema carries the semantics and the description adds no syntax, format, or sourcing detail beyond 'by id'. Baseline 3 is appropriate.

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

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

States a specific verb (Retrieve), resource (a single check), keyed by id, and even names the returned fields (status, report ids, result), which implicitly contrasts with the onfido_list_checks sibling. It never names that sibling explicitly, 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?

Usage is implied rather than stated: 'single ... by id' suggests this is the lookup path when you already hold a check_id, versus the list sibling for discovery. There is no explicit when-to-use/when-not guidance, no prerequisite or error conditions (e.g. unknown id).

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 readOnlyHint annotation already establishes that this is a safe read. The description adds that only metadata is retrieved and gives the underlying API endpoint, but says nothing about error behavior, permissions, or response 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?

Two short sentences, front-loaded with the operation and scope. Every phrase contributes directly to identifying and calling the tool.

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

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

For a simple one-parameter getter with full schema coverage and a read-only annotation, the description is nearly complete. It could mention what metadata fields are returned, but with no output schema that is not strictly required.

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 single document_id parameter is already fully documented. The description only restates that the lookup is by id and adds no format or semantic detail beyond 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?

The description states a specific verb (retrieve), resource (single document's metadata), and lookup key (by id). The singular 'document' and 'by id' clearly distinguish it from the plural list_documents sibling.

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: call this when you have a document id and need that document's metadata. However, there is no explicit when-to-use guidance, no exclusions, and no named alternative such as list_documents.

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, so the safety profile is covered. The description adds real value beyond that by disclosing the shape of the payload ('detailed breakdown + result') and the underlying REST endpoint, which is useful given 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 compact sentences with the core action front-loaded and the endpoint as supporting detail. No filler, no repetition of 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 single-parameter read tool with no output schema, this covers purpose, target resource, and rough return content. What is missing is only how to source the id and whether the report is scoped to a check/applicant, which is minor here.

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?

Only one parameter and schema description coverage is 100%, so the schema fully documents report_id. The description echoes 'by id' without adding format, sourcing, or validation detail, which is the expected baseline when the schema does the work.

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 ('Retrieve a single report ... by id') and pins the backing endpoint GET /reports/{report_id}. This distinguishes it from the sibling list_reports by making the single-resource scope explicit, though it never names the alternative.

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 'by id' — an agent can infer this is the lookup path once it has a report_id. There is no explicit when-to-use statement, no mention of how to obtain a report_id (e.g. via list_reports), and no 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?

readOnlyHint=true already tells the agent this is a safe non-destructive read. The description adds genuine context beyond that by enumerating what the payload contains (status, output, task history) and the underlying endpoint, but says nothing about missing-id errors or auth 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?

Two tightly packed sentences: the resource statement is front-loaded and the endpoint reference follows with zero 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?

With no output schema, the description usefully previews the return shape (status, output, task history), which is the main thing an agent needs. Only error/empty-state 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% for the single parameter, so the baseline is 3. The description adds no format, sourcing, or id-discovery guidance beyond what the schema already 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?

States a specific verb (Retrieve) and resource (a single Studio workflow run) scoped by id, and even names the underlying API endpoint. It is clear against list_workflow_runs without opening either schema, though the sibling is not 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: 'by id' suggests this is the lookup path once a run id is known, versus the list sibling. There is no explicit when-to-use, when-not-to-use, or named 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?

With readOnlyHint=true already declared, the safety profile is covered by annotations. The description adds the pagination behavior and the literal REST endpoint, which is genuinely useful context, but it omits anything about result caps, rate limits, or ordering. Adequate but not rich.

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 tightly written sentences with zero filler; the core action is front-loaded and the API endpoint is appended as supporting detail.

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, zero-required-parameter list tool with annotations covering safety and a fully described schema, this is nearly complete. The only slight gap is that no output schema exists, so nothing indicates the shape of the returned applicant collection.

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 all three parameters (page, per_page, include_deleted) carry their own defaults and constraints, so the baseline is 3. The description only gestures at 'paginated' and adds no meaning beyond what page/per_page already document.

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 verb+resource ('List applicant (person) records in the Onfido account') and adds the scope 'paginated' plus the underlying API route GET /applicants. It distinguishes itself from onfido_get_applicant by the plural 'records' framing, but never explicitly names the sibling relationship, so it lands just short of 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?

Usage is only implied by the name and the word 'paginated' – an agent can infer this is the bulk-retrieval counterpart to onfido_get_applicant, but the description never says when to list versus fetch a single applicant, nor any preconditions. No exclusions or alternatives are offered.

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, and the description redundantly confirms 'read-only'. It adds some context by noting that results/status are returned and by giving the API endpoint GET /checks?applicant_id=…, but says nothing about pagination, ordering, or response shape. With annotations covering safety, this is a modest addition.

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 compact sentence plus the API endpoint, with the core purpose front-loaded. Every element earns its place and there is 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?

For a simple read-only list tool with full schema coverage and safety annotations, the description covers purpose, scope, and the API path. It does not mention pagination or return-shape details, but no output schema exists and the gap is minor for this operation.

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 schema already documents the single applicant_id parameter with 100% description coverage, and the description only implies it through 'for an applicant'. No additional format or constraint detail is provided, so 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?

The description gives a specific verb (list) and resource (verification checks) scoped to an applicant, and the plural 'checks' implicitly separates it from the singular get_check sibling. However, it never explicitly names or contrasts with any sibling, so it falls short of the top score.

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 what the tool does but offers no when-to-use guidance, no prerequisites, and no mention of alternatives such as onfido_get_check for a single check. The agent must infer all usage conditions.

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, so the safe-read profile is covered. The description adds genuinely useful return-scope context ('metadata only') but says nothing about pagination, ordering, or result limits for a list endpoint.

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, front-loaded with the purpose. The trailing 'Onfido API: GET /documents?applicant_id=…' restates what the tool name already conveys, so it is mild filler rather than a structural flaw.

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 single-parameter list tool with no output schema, the description covers purpose, scope, and return granularity ('metadata only'). Nothing essential to invoking it is missing, though return-shape detail is thin.

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% with a single required parameter, so the schema already documents applicant_id fully. The description adds no syntax or format detail beyond what the schema provides, making 3 the 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?

States a specific verb and resource ('List the identity documents uploaded for an applicant') and adds the scope qualifier 'metadata only'. It is distinguishable from the singular onfido_get_document by the verb, though it does not name that 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?

Usage is only implied: you call it with an applicant_id to enumerate that applicant's documents. The '(metadata only)' note hints at when to prefer this over fetching a document's contents, but there is no explicit when/when-not guidance or named 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 already declare readOnlyHint=true, so the safety profile is covered. The description adds the useful 'metadata only' clarification (no binary/image payloads), but says nothing about pagination, result limits, or ordering for what is a list endpoint.

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, front-loaded sentences with no wasted words; the endpoint reference is compact and informative. Minor redundancy in restating the applicant scoping already implied by the name.

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 list tool with no output schema, the description should at least hint at the response shape or pagination behavior; 'metadata only' helps but leaves the return contract and paging unspecified. Otherwise adequate for a one-parameter read 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?

With a single parameter at 100% schema description coverage, the schema already documents applicant_id fully. The description adds nothing about the parameter beyond restating it, 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?

States a specific verb and resource ('List the live photos captured for an applicant') plus a scope qualifier ('metadata only'). It does not explicitly differentiate itself from the close sibling onfido_list_live_videos, which an agent could confuse with this 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?

There is no when-to-use guidance, no prerequisites, and no mention of the alternative sibling tools (e.g. list_live_videos or get_document). The only usage signal is the required applicant_id, which is already visible in the schema.

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, so the safety profile is covered. The description adds genuinely useful context beyond the annotations with '(metadata only)', telling the agent that actual video content is not returned, plus the underlying endpoint. No pagination or rate-limit details, but the metadata clarification is a meaningful disclosure.

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 zero waste: the resource and scope come first, and the API endpoint is a compact supporting detail. Nothing redundant or padded.

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 list tool with one required parameter and no output schema, the description covers purpose, scope, and the metadata-only return characteristic. It could specify which metadata fields are returned or whether results are paginated, but it is close to complete for this tool's 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 100% and the single parameter is already documented as required in the schema. The description's URL template (GET /live_videos?applicant_id=…) reinforces how applicant_id is used but adds no format or syntax detail beyond the schema, 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?

States a specific verb (List) and resource (live videos) scoped to an applicant, which cleanly separates it from sibling list tools like onfido_list_live_photos and onfido_list_documents. It stops short of explicitly naming those siblings, so sibling differentiation is implied rather than stated.

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

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

Usage is implied by the resource name and the required applicant_id, but there is no explicit guidance on when to call this versus alternatives (e.g., list_live_photos, get_check) and no prerequisites or exclusions mentioned. Adequate but minimal.

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?

readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description adds the API endpoint (GET /reports?check_id=…) and the nature of the returned collection, but says nothing about pagination, result limits, or error behavior — useful additions are modest.

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, zero filler, and the core purpose is front-loaded before the API reference. 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?

For a read-only single-parameter list tool with no output schema, the description conveys scope and the kinds of items returned. It doesn't describe the return shape (id/status fields), but the enumerated report types give adequate orientation for correct invocation.

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 sole check_id parameter is fully documented in the schema, so the baseline of 3 applies. The description reinforces that reports are scoped to a check but adds no format, syntax, or constraint detail beyond 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 specific verb (List) and resource (reports), and clarifies scope — the reports that make up a single check — with concrete examples (document, facial similarity, watchlist). It does not explicitly distinguish itself from the singular onfido_get_report sibling, so sibling differentiation is left implicit rather than stated.

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

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

The phrase 'that make up a check' implies the precondition of having a check_id and wanting the full set of its reports, which is reasonable context. However, it never contrasts with onfido_get_report (single report) or states when-not to use this listing tool, so the guidance remains implied rather than explicit.

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, and the description largely restates this ('read-only'), though it adds the useful clarification that it does not start a run and names the underlying endpoint. No details on pagination limits, rate limits, or result size are provided.

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 clauses with zero waste and the key constraint ('does NOT start a run') front-loaded. Terse but functional; it does not pad with redundant restatement of 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 zero-required-parameter list tool with full schema coverage and no output schema, the description gives enough to invoke correctly (read-only, does not start runs, returns status/output). Return-shape detail is rightfully left to the API since no output schema exists.

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 all six filter/sort/pagination parameters are already well documented in the schema. The description adds no parameter meaning beyond what the schema supplies, so the baseline of 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?

States a specific verb (List) and resource (Onfido Studio workflow runs) with scope notes ('status/output, read-only'). It implicitly distinguishes itself from the singular sibling onfido_get_workflow_run and from run-starting operations, but never names an alternative 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 parenthetical '(does NOT start a run)' clarifies a boundary of use, and read-only signals a safe query context, but there is no explicit when-to-use guidance or routing rule distinguishing it from onfido_get_workflow_run for a single run or onfido_list_applicants.

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 description goes beyond the single destructiveHint annotation by disclosing that the change is reversible and that no verification is triggered — exactly the kind of operational context annotations don't convey. The tension between "reversible" and destructiveHint=true is a nuance (fields are still overwritten), not a contradiction, but it leaves the overwrite behavior unstated.

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 with the behavioral caveat front-loaded before the endpoint reference; nothing is padded and the key differentiators (reversible, no verification) come first.

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 an 8-parameter mutation tool with nested objects and no output schema, the description covers purpose and safety posture but omits partial-update semantics and permission/auth expectations. Given the fully self-documenting schema, it is adequate but noticeably thin on the mutation side.

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 all eight parameters (including the nested address and id_numbers pass-through objects) are already documented in the schema, making 3 the correct baseline. The description adds no format, constraint, or partial-update detail beyond what the schema provides.

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 ("Updates an applicant's details") plus the exact API endpoint, which unambiguously separates it from the get/list/create applicant siblings. It stops short of clarifying partial-vs-full replacement semantics, which would be the remaining distinguishing detail for an update 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?

There is no explicit when-to-use or when-not guidance: nothing tells the agent to prefer this over onfido_create_applicant for new applicants, or how it relates to verification/check tools. Usage is only weakly implied by the word "Updates" and the applicant_id parameter.

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