Rekvira: EU regulation pinpoints for compliance AI

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

Although annotations indicate this is not read-only, the description carries the behavioral detail: it sends exactly one email in the chosen language, the confirm link/code is valid for 15 minutes, connect_verify blocks until the click, and nothing is charged. This exceeds what annotations alone convey.

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

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

A single dense paragraph that contains no filler, but it could be better structured into two modes or bullets. Every sentence earns its place and the most important distinction appears early.

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 still names the return values (trial_id, request_id), the email validity window, and the next tools to call. An agent has enough information to invoke connect correctly in both 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 100%, so the baseline is 3, but the description adds mode-dependent meaning: omitting both parameters means trial, while supplying email and language triggers sign-in. It could more explicitly state what happens with a partial combination, but the core semantics are clear.

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 two distinct, concrete modes: no arguments launches a keyless trial and returns trial_id, while email plus language signs in and returns request_id. It explicitly frames the tool as step 1 of 2 and names connect_verify as the next step, so it is not confused with its siblings.

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

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

It states exact conditions for use: no arguments for the trial, email and language for sign-in, and instructs to call start_here after the trial and connect_verify immediately after the email. This is explicit contextual routing with no ambiguity.

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 far beyond the annotations, which only indicate non-read-only, non-idempotent, and non-destructive. It discloses that the tool waits up to 45 seconds, returns as soon as the user confirms, may return a waiting state requiring retry, moves keyless trial work into the account, and returns a one-time rek_ key plus a session value for later calls. This gives the agent a full behavioral model.

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 dense but every sentence carries actionable information: when to call, what to pass, what to expect, how to handle waiting, and what is returned. It is front-loaded with the core instruction and contains no filler or redundant phrases.

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 there is no output schema, the description fully compensates by explaining return values (rek_ key shown once, session value) and the retry loop. It also clarifies the relationship with connect(email) and the trial_id flow. The tool's complexity is high because of the asynchronous wait and retry semantics, and the description covers all needed behaviors.

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 all three parameters with clear descriptions, so coverage is 100% and the baseline is 3. The description reinforces that code should be omitted by default and that trial_id should be passed along, but it mostly restates what the schema already provides. It adds flow context rather than new parameter-level semantics.

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 states the tool finishes signing in as step 2 of 2, with a specific verb and resource. It explicitly anchors to connect(email), distinguishing it from the connect sibling and other workflow tools. The scope is unambiguous: verify a sign-in request either by waiting for email confirmation or by passing a six-digit code.

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 gives explicit when-to-use instructions: call it right after connect(email) with request_id and no code. It also explains the retry behavior ('if it returns waiting, call it again') and tells the agent not to ask the user to report the click, which prevents a common misuse. It even covers the alternative code path when the user reads the code.

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 destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: the auth handshake required, the trial-scoped ownership boundary, and the fact that shipped playbooks and other trials' drafts are immune. It does not mention whether the deletion is recoverable or how the caller should confirm intent.

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 auth prerequisite so the agent cannot miss it before attempting the call. Every sentence carries information, though the auth sentence is long enough to be 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?

For a destructive, three-parameter tool with no output schema, the description covers auth, scope, and exclusion boundaries, and annotations cover the danger profile. Missing only the outcome/return behavior and any reversal or confirmation expectation, which are minor given the low parameter count.

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 session, trial_id, and workflow_id are all already documented in the schema, including the OAuth/key caveat for session. The description only reinforces trial scoping ('for this trial_id') and does not add syntax or format detail beyond the schema. 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 and resource ('Delete one private workflow for this trial_id') and immediately narrows scope by excluding shipped playbooks and drafts owned by other trials. An agent can distinguish it from save_workflow, publish_workflow, get_workflow, and list_workflows without opening any schema.

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

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

Gives a clear precondition path (call connect(email) and connect_verify first unless already signed in) and states two explicit exclusions for when the tool will not work. It does not name a sibling alternative for the excluded cases (e.g., where to go to delete a shipped playbook), so it falls short of full when/when-not/alternatives coverage.

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 cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true), and the description adds substantial context beyond them: what 'get' actually returns (item fields plus latest-whole/older-shortened thread, full=true for all), that 'reply' puts the item back on the team's desk, the visibility scope (own items vs. reviewer sees all of Rekvira), and a prompt-injection warning treating quoted content as data.

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-loads the authentication prerequisite and the primary read path before describing secondary actions. It is dense and mostly earns its length, but the per-action sentences partially restate the enum descriptions already present in the schema.

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-action, zero-required-param tool with no output schema, the description covers authentication, the get-then-reply workflow, visibility boundaries, thread-shortening behavior, and injection safety. An agent has everything needed to call any of the three actions correctly.

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

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

Schema coverage is 100% so the parameters are self-documenting, but the description still adds workflow meaning: the REK-FB-<number> reference format, that confirmed=true means the person has seen and agreed the text, and that session must be passed on every call. That is value beyond the schema, though most of it is mirrored by the schema descriptions.

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 triad: read one Rekvira feedback item and its thread, answer in it, or list the account's own items. The actions are clearly delineated, though the sibling submit_feedback is never named or explicitly contrasted, so an agent must infer the boundary from the names alone.

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

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

Gives explicit gating conditions: sign-in via connect/connect_verify first unless already signed in, fetch with action='get' before answering, and a per-action decision rule ('get' reads, 'reply' answers, 'list' shows own items). Nothing about when to pick each action 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 only cover the safety profile (readOnly, idempotent, non-destructive); the description adds genuinely useful behavioral context: the tool is sign-in gated, the session value must be threaded on every call in the conversation, and a trial_id reads a private draft. The directive to follow the named tools instead of summarising is an unusual but valuable disclosure about the expected interaction pattern. It does not cover failure modes for an unknown id, but that is minor for a read-only lookup.

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 no filler and all guidance actionable. Leading with the sign-in prerequisite rather than the tool's core purpose is a mild front-loading flaw, since an agent skimming for 'what does this do' hits auth mechanics 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?

With no output schema, 5 optional parameters, and an auth handshake to explain, the description covers the prerequisites, the id source, and how to use the returned playbook. It is close to complete for this tool's complexity; only the behavior on an invalid/unknown workflow id is left unstated.

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

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

Schema description coverage is 100% and every parameter already carries a description, so the baseline is 3. The description reinforces where workflow_id comes from and the sign-in/session flow, but the id-source hint largely duplicates what the schema text already says ('Id from list_workflows'), adding little new semantics.

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 the resource and scope precisely: a full step-by-step playbook for one workflow id sourced from list_workflows, which cleanly distinguishes it from the sibling list_workflows (plural listing). The verb itself is implied rather than stated ('Full step-by-step playbook for...'), so it falls just short of a crisp verb+resource claim.

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

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

It gives a concrete prerequisite chain (call connect(email) and connect_verify first unless already signed in) and tells the agent where the id comes from (list_workflows), plus how to consume the result (follow the named tools rather than summarising). No explicit 'when not to use this' or comparison against a sibling alternative is 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 readOnly/idempotent/non-destructive, so the bar is lower. The description adds real un-annotated context: an authentication prerequisite (connect/connect_verify), the newest-first ordering, and a scope guard against fabricating rows.

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?

Four tight sentences, front-loaded with the sign-in prerequisite before the actual behavior. No redundant filler, though the auth sentence is somewhat verbose.

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 must carry behavior; it covers auth, ordering, and scoping. It does not describe pagination or response shape, but for a simple read-only list with fully documented params this is close to sufficient.

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 each of the 4 params (limit, session, trial_id, max_chars) is documented in the schema. The description reinforces trial_id provenance ('from connect()') but adds little beyond what the schema already states, so baseline 3 applies.

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

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

States a specific verb and resource ('List this trial_id's recorded assessments') plus the ordering ('newest first'). This clearly distinguishes it from the write-oriented sibling record_assessment and from the workflow/regulation listers.

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

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

Gives a concrete when-to-use context ('resuming a multi-week DPIA or applicability review') and a scope exclusion ('Never invent rows for another trial'). It does not explicitly name an alternative tool, but the intent is clear enough to route correctly.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so safety is covered. The description adds genuinely new behavior: the auth gate and its ordering, and the fact that the response reports corpus JSON load state. No return format or pagination detail beyond the schema, so not a 5.

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

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

Two sentences, front-loaded with the blocking prerequisite before the tool's own behavior, which is the right ordering for an auth-gated tool. Slightly dense with the sibling enumeration, but nothing is wasted.

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

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

Covers the prerequisite, what is returned (registry entries plus corpus load status), and where to go next. With no output schema and only two fully documented parameters, this is nearly complete; only return shape and result-size behavior are left implicit.

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

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

Schema description coverage is 100% for both parameters (limit, max_chars), so the schema already carries their meaning. The description adds nothing about limit/max_chars semantics, making the baseline 3 correct.

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 regulations in the registry') plus a distinctive extra output ('whether corpus JSON is loaded'). The routing sentence implicitly separates it from search_regulation/search_regulations, though it does not explicitly say this is the unfiltered enumeration and those are for filtered lookups.

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

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

Gives an explicit prerequisite chain (call connect(email) and connect_verify first unless already signed in) and names the follow-up alternatives (search_regulation, search_regulations, list_workflows for a named process). It does not state a when-not-to-use condition, but the routing makes the intended workflow clear.

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

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

Annotations already establish read-only, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely non-redundant behavior: an auth/session lifecycle requirement, session continuity across calls, and the fact that trial_id surfaces private drafts alongside the shipped library.

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?

Five sentences, no filler, and the highest-stakes fact (sign-in required) is front-loaded. Slightly verbose in restating auth steps that the session parameter description also covers, but nothing is wasted outright.

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 auth-gated listing tool with no output schema, the description covers the sign-in gate, what the list contains, the trial_id scoping, and the follow-up call. It leaves the return shape (fields per playbook, pagination) unstated, but limit/max_chars in the schema partly compensate.

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 baseline is 3. The description adds real meaning on top: it explains trial_id's effect on the result set (own drafts beside the shipped library) and ties session semantics to connection mode, beyond the schema's terse field notes.

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

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

States a concrete verb+resource ('Playbook library', 'list your own private drafts beside the shipped library') and clarifies it as a browse step distinct from get_workflow, which is named as the drill-down follow-up. It does not differentiate against other list_* siblings (list_assessments, list_regulations), so it falls 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?

Explicit prerequisites (connect + connect_verify first, or an existing session/OAuth/key), explicit when to use ('Read a playbook before improvising a process'), and explicit next step ('Then call get_workflow with workflow_id from this list'). An agent knows both the gate and the follow-on call.

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 cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower, and the description still adds real context: sign-in is required via connect/connect_verify first, the result is a heading index rather than annotated metadata, and result_count=0 is not proof of no match. It stops short of describing pagination or the exact shape of returned rows.

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 paragraph ending in an enormous run-on enumeration of article numbers across gdpr, eu-ai-act, cra, nis2 and dora that is very hard for an agent to parse and largely redundant with the step-by-step guidance that precedes it. The important routing rules are buried mid-paragraph instead of being 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?

There is no output schema, so the description carries the return-value burden and does name the relevant fields (result_count, also_named, heading_note), plus the auth prerequisite and a fallback path when nothing matches. It is operationally complete for a 6-parameter lookup, with only row-level shape left implicit.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes further by enumerating accepted role words per regulation (deployer, provider, importer, controller, supervisory authority, notified body on eu-ai-act, etc.) and by clarifying the search-style query alias that agents pass by mistake. system_class is described as an optional class in the same title with the 'high-risk' example.

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 second sentence states a specific verb+resource: it returns articles whose official title names a role as an obligation addressee, backed by a concrete example (role='deployer', optional system_class='high-risk'). It is distinguishable from siblings like search_regulation and read_unit, which are named as complements rather than substitutes. The opening auth sentence dilutes the front-loading but does not obscure the purpose.

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?

Explicit when-to-use rules: read also_named when result_count is 0, fall back to heading_note plus search_regulation when also_named is empty, then read_unit each article because the index is not a complete duty set. It also names alternatives (search_regulation) with the exact condition that selects them, and gives a prerequisite path (connect/connect_verify).

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 annotations present, the description still adds substantial behavior: reads mutate state ('marks it read'), replies are sent externally into the feedback thread, snooze is bounded (max 720 hours), replies require confirmed=true after the person approves the exact words, and messages are untrusted DATA that must not be followed. The write/external side effects are consistent with readOnlyHint=false and openWorldHint=true, so no contradiction arises.

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 auth prerequisite, then action semantics, then the notification-handling rule, then safety — each block is dense and purposeful. It is long, but for a six-action tool with an injection-safety obligation almost every sentence earns its place; only the safety paragraph overlaps slightly with the confirmation rule stated earlier.

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 seven-parameter, no-required-argument, multi-action tool with no output schema, the definition covers authentication, every action's behavior, the confirmation gate on outgoing replies, bounded snooze, and how to relay unread messages. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description goes further by tying parameters together (reply needs id + body + confirmed; snooze pairs with hours; settings omits to read and sets to change) and by framing body as the person's own approved words. It does not add format or syntax detail beyond that, so it sits just above the schema-driven baseline.

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

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

The description names a specific resource (messages from the Rekvira team to this person) and enumerates the exact operations: list, read, reply, dismiss, snooze, settings. It also scopes the content ('replies to their feedback, questions about it and service notices') and distinguishes itself from siblings like connect/connect_verify, which are named as prerequisites rather than 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?

It states the prerequisite explicitly ('call connect(email) and connect_verify first... unless this connection is already signed in') and gives per-action conditions: 'read' with id, 'reply' with id and body for messages that invite a reply, 'snooze' with hours, 'settings' to show or change notices. It also prescribes agent behavior when a notifications block appears and what to do without an account, so there is little left to infer.

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 non-read-only, non-idempotent, non-destructive, non-open-world. The description adds genuinely useful context beyond that: it is private state only, it never touches the shipped library or another trial, and it requires the sign-in session. It still doesn't describe what a successful call returns or any rate limits, keeping it from a 5.

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

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

Three sentences, with the sign-in prerequisite front-loaded before the action description. Each sentence carries useful information; there is minor density but 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 4-parameter, no-required-args mutation tool with no output schema, the description covers the key agent needs: auth/session flow, the effect of the call, and the scope limitation of the state change. It is essentially complete, missing only return-value or error behavior that the absent output schema would otherwise cover.

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

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

Schema description coverage is 100%, so the schema already documents session, trial_id, published (true=ready/false=draft) and workflow_id. The description's phrasing ('mark ... ready or draft') mirrors rather than extends the published semantics, so the baseline 3 applies.

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

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

The description states a specific verb+resource: it marks a private playbook in this trial as ready or draft. It also draws a boundary that separates it from content-creating siblings (save_workflow/delete_workflow) by noting publishing 'never adds content to the shipped library.' It doesn't name a sibling explicitly, so it falls 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?

It clearly states the prerequisite (call connect/connect_verify first unless already signed in) and the two states the tool can set. However, it gives no explicit guidance on when to use this versus save_workflow or deleting/re-creating a workflow, leaving that choice 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?

Adds significant non-annotation context: the authentication prerequisite (call connect and connect_verify first), that articles return aggregated paragraph text, and that paragraph numbers repeat across articles so article= is needed. These are real behavioral gotchas the annotations do not cover.

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-loads the sign-in prerequisite and then the core action; every sentence carries information. Dense but not padded, though the closing verify_citation sentence could be tightened slightly.

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 10-parameter, no-output-schema tool this covers the main call paths, auth, and the article/paragraph disambiguation pitfall. It is nearly complete; the cite/citation aliases and as_of are left entirely to the schema, which is acceptable given full coverage.

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 baseline is 3. Most of what the description says about parameters (article= for paragraphs, pinpoint resolving kind/number, numbers or strings accepted) restates what the schema already documents, adding little beyond the example pinpoint string.

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 ('Read one citable unit by kind and number or label') and immediately scopes the behavior for articles and paragraphs. It is clearly distinguishable from siblings like search_regulations and verify_citation.

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 routes the agent: use read_unit to read one unit, pass article= to disambiguate paragraphs, use pinpoint verbatim from a result row, and use verify_citation instead when checking someone else's pinpoint. Both the when and the alternative are named.

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 a non-read-only, non-idempotent, non-destructive write, and the description adds genuinely useful context: the required sign-in flow, that re-recording the same regulation+pinpoint overwrites, and that assessments are annotations that never suppress search/read results. It stops short of describing what the overwrite does to audit history or what the call returns, but it is well above the annotation baseline.

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?

Dense but front-loaded: the auth prerequisite comes first, then the core action, then the enum/overwrite semantics. Nearly every sentence carries a distinct constraint; the enum restatement in the description is the one mildly redundant element.

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 6-parameter (all-optional) write with no output schema, the description covers trigger, auth, overwrite behavior, and value constraints. The only gap is that with no output schema present, the description says nothing about what a successful recording returns or how the write is confirmed.

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 verdict and reason enums are already documented in the schema and the description mostly restates them. It does add one real constraint — reason must be a structured code, never free text — and ties trial_id/session back to connect, but this is marginal value over structured fields, so baseline 3 applies.

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

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

States a specific verb and resource — 'Record one structured applicability verdict on a regulation pinpoint' — and scopes it to a keyless trial_id. An agent can immediately distinguish this write from read-side siblings like list_assessments or search_regulation.

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

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

Gives a clear trigger ('Call after the officer states applicability') plus a hard prerequisite (connect/connect_verify sign-in) and an exclusion (reason codes only, never free-text notes). It does not name a specific alternative tool for the 'don't record' case, but 'assessments annotate; they never hide search or read results' effectively clarifies the boundary.

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

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

Annotations declare destructiveHint=true and readOnlyHint=false, and the description adds real context beyond them: 'keys' never returns the key itself, 'revoke_key' needs the prefix, 'delete' is two-step (email confirmation link, deletion on click), 'export' returns everything held, and nothing is charged during the beta. It doesn't cover session lifetime or what happens to data after deletion beyond the click, so it falls short of a 5.

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

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

The sign-in requirement is correctly front-loaded, but the body is a single dense run-on sentence with interleaved parentheticals covering seven actions. An action-per-line structure would be far more scannable; much of the content earns its place, but the packaging works against it.

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

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

For a 5-parameter, 7-action dispatch tool with no output schema and full schema coverage, the description covers prerequisites, per-action effects, and side effects like the deletion email. It is close to complete; only cross-action return expectations (e.g., what 'usage' or 'export' yield structurally) are left implicit.

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

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

Schema coverage is 100%, so the baseline is 3, but the prose adds genuine meaning: it ties key_prefix to the value action='keys' lists, specifies confirm_email is the account's own email typed back by the user, and explains action='plan' behavior. It is more than restating 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 the resource (the signed-in account) and enumerates the exact effect of each action ('status' returns email/what is kept/keys, 'plan' explains the free beta, 'keys' lists without exposing the key, 'delete' mails a confirmation link). An agent can tell what each action does. However, it never distinguishes this tool from the sibling whoami, which plausibly overlaps with action='status'.

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?

Explicit prerequisites are given up front: sign in via connect(email) and connect_verify unless already signed in, and it names connect/connect_verify as the alternative path. It also states what happens when not signed in. It stops short of saying when to prefer this over whoami or what to do for account concerns outside this tool's action list.

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 the write/idempotency/safety profile, but the description adds material context beyond them: a sign-in requirement with the exact bootstrap calls, and tenancy scoping ("It stays inside this trial_id"). It does not clarify the upsert-vs-create behavior implied by "save or update" against idempotentHint=false, which is the only remaining gap.

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

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

Three sentences, front-loaded with the blocking prerequisite, then purpose, then the sibling boundary — every sentence earns its place. The first sentence is densely packed with two calls and a parenthetical, but nothing is wasted.

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 six-parameter mutation tool with 100% schema coverage, no output schema, and annotations covering the safety profile, the description supplies the missing pieces an agent needs: auth prerequisites and the save-vs-publish boundary. Only the create-vs-update result semantics remain unaddressed.

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

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

Schema description coverage is 100%, so all six parameters (body, title, session, summary, trial_id, workflow_id) are already documented in the schema. The description only touches trial_id implicitly ("stays inside this trial_id") and 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 pair ("Save or update") and resource ("one private compliance playbook") with scope ("for this keyless trial"). It explicitly distinguishes the action from the sibling publish_workflow, so an agent can route between them 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?

Gives an explicit prerequisite sequence (call connect(email) and connect_verify first, unless already signed in) and an explicit alternative ("call publish_workflow only to mark it ready here, never to share it with another user"). The when-to-use condition is stated, not 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?

Annotations already declare readOnly/idempotent/non-destructive, and the description adds behavior beyond them: a hard sign-in prerequisite, the nature of the return (excerpts not summaries), and the fact that limit/detail/max_chars bound response size. This is exactly the extra context the annotations cannot carry.

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

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

Four tight sentences, front-loaded with the blocking prerequisite and then the purpose, then return shape, then the call chain. Every clause carries actionable information 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?

With no output schema, the description still explains the return format (pinpoints and excerpts), the auth requirement, the bounding parameters, and the recommended next tools. Nothing an agent needs to call this correctly is missing.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds genuinely new value: a concrete regulation id example ('eu-ai-act'), a note that detail takes compact|full, and confirmation that the response size is bounded by limit/max_chars. It doesn't cover as_of or kinds, which the schema already documents.

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 ('Search held regulation text') and immediately clarifies the return shape ('pinpoints and excerpts, not summaries'). The requirement for a single regulation id implicitly separates it from the plural sibling search_regulations, so an agent can route without opening schemas.

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

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

Explicitly states the prerequisite workflow ('call connect(email) and connect_verify first') and the follow-up routing ('Then read_unit on the best pinpoints; verify_citation if checking someone else's cite'). It names the alternative tools and the condition that selects each, leaving nothing 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 cover the safety profile (readOnly, idempotent, non-destructive), so the bar is lower. The description adds genuinely useful non-annotation context: an auth prerequisite with the exact connect/connect_verify sequence, cross-act relevance ranking, and response-size bounding.

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?

Five dense sentences, front-loaded with the blocking auth prerequisite before purpose, usage, response controls, and the chaining hint. No filler and nothing repeated from the name or 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?

With eight optional parameters, no output schema, and a chained read workflow, the description supplies what is otherwise missing: sign-in gating, cross-act behavior, response-size controls, and the fact that each hit yields a regulation id for read_unit.

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 are already documented. The description restates the response-bounding role of limit/detail/max_chars and per_regulation_min's per-act share, which frames their interplay but adds little detail beyond the schema text.

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 ('Search all loaded regulation modules in one call') plus the scope that distinguishes it: cross-corpus, relevance-ranked. An agent can tell it apart from the singular search_regulation sibling from the description alone.

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

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

Gives an explicit selection condition ('when the question names more than one act or you do not know which act holds the answer') and a follow-up step ('then read_unit per regulation'). It never names the single-act alternative, so the routing is clear but not fully spelled out.

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

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

Annotations already declare readOnly/idempotent/non-destructive, and the description layers on traits they cannot express: an auth prerequisite, zero quota cost ('cheap: one call, no quota'), and call-time freshness ('built from the loaded corpus at call time'). This is exactly the added context the annotations leave open.

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 sentences, front-loaded with the blocking prerequisite, then purpose, then next steps. The em-dash enumeration is dense but every element is load-bearing; slightly packed rather than wasteful.

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 naming the payload contents, and it covers entry conditions and exit paths. Nothing needed to call this correctly is missing.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain; baseline 4 applies. The description's mention of connect(email) belongs to a sibling tool, not this one.

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

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

States a concrete verb+resource: orientation for the loaded corpus, enumerating exactly what it returns (regulations loaded, unit counts, data_as_of, gaps, per-module first-call hints). An agent can distinguish it from list_regulations or search_regulation without opening a schema.

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

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

Explicitly sequences prerequisites (connect(email) then connect_verify unless already signed in) and names the follow-on alternatives (list_regulations, search_regulation, list_workflows). Both the when and the what-next are stated rather than 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?

Annotations only cover the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=true); the description adds substantial context beyond them: the connect/connect_verify sign-in prerequisite, that every item is read by a person, the confirmed=true gate, privacy handling of user words and confidential details, and that the reply carries a reference id with no promise of a response.

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

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

It is long (multiple dense paragraphs), but the length is largely earned by 11 parameters, privacy constraints, and a multi-step consent workflow. Prerequisites are front-loaded, though the description opens with auth rather than the tool's core purpose, slightly delaying the headline action.

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 11-parameter, zero-required tool with no output schema, the description covers the auth prerequisite, the invocation workflow, privacy gates, field guidance, length limits, and even what the response returns (a reference id). 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?

Schema coverage is 100%, so the baseline is 3; the description goes further by explaining cross-parameter rules the schema cannot (confirmed=true only after user approval, authored_by='agent' allows unconsented observation, what/expected/got pairing, query only with user OK, length caps). It adds real semantics, though the per-field descriptions in the schema already carry much of the same content.

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 ('Send feedback about Rekvira to the team that builds it') and enumerates the categories it accepts (bug, wrong answer, missing data, missing feature, workflow idea, praise). It is highly unambiguous about what the tool does, but it never distinguishes itself from the sibling tool 'feedback', leaving that relationship to 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?

Includes an explicit 'When to offer it' trigger list (empty/wrong answer, user correction, missing workflow step, repeated manual step, unmet need) plus behavioral guidance ('Offer once, in one sentence; the user's task comes first'). The 'Ask first' rule further constrains when and how to invoke, leaving nothing to guess.

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 what the structured fields cannot: the sign-in gate, the specific error signal (regulation_mismatch when a YYYY/NNNN embeds a different act), and the as_of/wording-in-force behavior. Lacks any note on rate limits or latency, 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?

Dense but every sentence carries load: auth gate, purpose, input convention, follow-up, and disambiguation. It is well front-loaded, though leading with the auth prerequisite before stating the core purpose slightly buries the main verb.

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 tool with no output schema and rich parameter docs, the description supplies the auth flow, the check semantics, the error case, and the natural next step (read_unit). What comes back is described only in outline, but no critical gap remains 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?

With 100% schema coverage the baseline is 3, but the description goes further: it explains that regulation= disambiguates when the cite omits the act name, that quote= is an optional sentence check, and that cite is passed as written, adding semantics beyond the schema text.

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 precise verb and resource ('Verify a citation someone else produced') and defines the exact check performed: pinpoint existence in held text plus optional quote matching. This clearly distinguishes it from the sibling read_unit, which it names as the follow-up for full text.

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

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

Gives an explicit auth prerequisite (connect + connect_verify, or already signed in), the input convention ('pass the cite as written'), the optional quote=, and the alternative route (read_unit for full text). The regulation= disambiguation condition is also spelled out.

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

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

Annotations already mark the call read-only and idempotent; the description adds the concrete output contents (tier, trial state, corpus load count) and the trial_id echo behavior. This is meaningful context beyond the structured fields without contradicting them.

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, front-loaded with the call's purpose and followed by actionable parameter guidance. 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 simple read-only identity check with rich annotations and fully documented parameters, the description covers what it returns and how to use it after connect. The absence of an output schema is mitigated by naming the returned fields, though a bit more on expected failure/auth scenarios could help.

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

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

Schema coverage is 100% and both parameters already carry descriptions. The description adds the purpose of trial_id (confirming the handle for assessments/private workflows), but session is not elaborated beyond the schema, so the added value is modest.

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?

Description states the tool identifies the caller and reports tier, trial state, and corpus load count—clear verb and resource. It doesn't explicitly contrast with sibling tools, but the unique 'who is calling' scope distinguishes it.

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 instructs passing trial_id from connect() to confirm the handle and points to start_here or list_regulations as next steps, giving a clear post-connect usage context. It stops short of explicitly naming alternatives or when-not-to-use, but the workflow ordering is useful.

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