Global FinReg

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

Annotations already declare this a safe, idempotent, read-only, closed-world operation, and the description adds real context beyond that: the step-completion reporting, the transient nature of personVerificationUrl, and when walletReturnUrl appears. It stops short of stating auth requirements or polling cadence, but the safety profile is covered by annotations.

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

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

A single front-loaded sentence beginning with 'Returns the status...' with each clause carrying distinct information (statuses, steps, due URLs, nextStep). It is dense and slightly run-on but has 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 must describe return values, and it does so thoroughly: status enum, completed steps, personVerificationUrl while due, walletReturnUrl once submitted or approved, and nextStep. An agent has everything needed to interpret the response.

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

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

Schema coverage is 100% and the single idCredPub parameter is documented in the schema itself, including its provenance from start_concordium_company_verification. The description adds nothing further about the parameter, 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 ('Returns the status of a Concordium company identity') and enumerates the exact status values, making it clearly distinct from siblings like check_registration_status and check_transfer_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?

The parameter description ties it to start_concordium_company_verification and 'nextStep says what to do' hints at a polling workflow, but there is no explicit statement of when to call this versus the other check_* siblings or how often to poll.

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 adds genuine context beyond them: it discloses that despite the 'check' verb the call has a write side effect (confirming and recording an online POA signature), which explains readOnlyHint=false. It does not cover auth requirements or rate limits, but the key non-obvious behavioral trait is disclosed.

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 well-formed sentences, front-loaded with the primary purpose and return fields, with the side-effect caveat placed last where it belongs. Slightly dense but every clause carries information.

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

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

No output schema exists, so the description compensates by enumerating the returned signals (status, POA signed, document needs, readyToPay, next steps). Combined with annotations covering the safety profile, it is sufficient for correct invocation, though it omits any error/edge-case behavior.

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% for the single parameter, so the schema already carries the semantics (including the GUID source). The description adds no syntax or format detail beyond what the schema provides; 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 ('Returns the status') and resource ('a new LEI application'), then enumerates the exact status values (draft, paid, processing, issued) plus the accompanying fields. An agent can tell precisely what this returns without opening the schema.

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

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

Usage is implied by 'status of a new LEI application' – it is for checking an in-flight registration. However, it names no alternatives (e.g., get_lei_record, get_renewal_payment_status) and gives no explicit when-not-to-use guidance, leaving the agent to infer routing.

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

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

Annotations only give generic hints (readOnly=false, idempotent=true), so the description carries real weight and does so well: it discloses that despite the "check" framing the tool writes, confirming and recording an online POA signature with the signing service. It does not cover auth requirements or error/edge behavior, 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?

Two sentences, front-loaded with the primary purpose and no wasted framing. The clause "whether it must be renewed with the transfer and what to do next" is slightly loose but still earns its place by previewing the return payload.

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 what comes back (status values, renewal requirement, next steps) and flags the signature-recording side effect. For a single-parameter tool with annotations present, this is nearly complete, missing only failure/edge-case behavior.

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 already fully documents leiId (GUID from start_lei_transfer or list_my_leis, not the 20-character LEI number). The description adds nothing beyond that, which is the expected 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 ("Returns the status of an LEI transfer") and enumerates the possible states (awaiting_poa, processing, completed, rejected). The resource word "transfer" cleanly separates it from siblings like check_registration_status and check_concordium_verification_status without the agent 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?

Usage is only implied by the name and the returned statuses; there is no explicit statement of when to call this versus siblings such as get_renewal_payment_status or check_registration_status. "What to do next" describes a return value, not invocation guidance.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, openWorldHint=true, so the agent knows this is a state-changing, repeatable, external-facing call. The description adds genuinely useful behavior beyond that: the operation is an approval gate in a multi-step flow and it returns walletReturnUrl that must be handed to the user to open on their Concordium wallet device. No auth or failure-mode detail is given.

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 tightly packed sentences with zero filler. The route identity and the call precondition are front-loaded ahead of the return-value instruction.

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, and the description compensates by explaining what walletReturnUrl is and what the user should do with it. It covers preconditions for a multi-step, state-changing flow, though it omits failure cases such as an invalid or already-verified LEI.

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 both parameters are documented with their provenance from start_concordium_company_verification. The description reinforces that the LEI must be one of the user's active LEIs and user-selected, but adds no syntax or format detail beyond the schema; 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 (approves the Concordium company identity) and scopes it precisely as 'the fast route' using an LEI from start_concordium_company_verification. An agent can distinguish this from start_concordium_company_verification and set_concordium_company_details 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 an explicit precondition: only call after the user chose the fast route and confirmed which LEI the identity is for. It also names the sibling that supplies the LEI options. It does not name the alternative (slow) route tool, so the routing guidance is clear but incomplete.

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 declare the generic write/openWorld/non-idempotent profile; the description adds the real behavioral facts — irreversible financial commitment, that 'card' returns a paymentUrl for the user to sign in at Global FinReg (never collect card details), that 'invoice' confirms immediately and returns a PDF. Strong added value beyond annotations, though it doesn't mention failure/refusal handling beyond the price-change case.

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 commitment warning, then the payment branches; every sentence carries information. The single dense paragraph is slightly run-on, which costs a point versus a cleanly segmented version.

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, and the description covers the return values for both payment methods (paymentUrl, invoice PDF), the precondition, and the refusal condition on price change. Nothing an agent needs to call this risky write 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, but the description adds meaning the schema doesn't: it explains what paymentMethod 'card' versus 'invoice' actually does. It says less about years, vatNumber/vatCountry and expectedTotal, relying on the schema, which is acceptable at full coverage.

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 ('Orders the registration of a draft LEI application') and immediately distinguishes the pricing model from the sibling create_renewal_order ('paid like a renewal'). An agent can tell it apart from quote/status siblings without opening the schema.

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

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

Gives an explicit precondition chain: only call after showing the price from get_registration_quote and getting explicit agreement, because it commits the user to paying. It also explains the two paymentMethod branches and what each produces, so the agent knows which variant to pick.

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 flag a non-read-only, non-idempotent, open-world mutation, and the description adds the crucial commitments an agent must know: this commits the user to paying, card payment is completed on Global FinReg's page (never collect card details), and invoice confirms the renewal immediately. These are consequential side effects not visible in annotations.

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

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

Front-loaded with the committing nature of the call and the prerequisite check, then the two payment paths. Three dense sentences, each carrying distinct operational information; nothing redundant.

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

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

With no output schema, the description supplies the return values that matter (paymentUrl, invoice PDF), the confirmation semantics, and the safety rule about card details. Nothing an agent needs to call this mutation 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?

Beyond the 100%-covered schema, the description explains the behavioral consequence of each paymentMethod: 'card' returns a paymentUrl the user signs into and pays at (never ask for card details), while 'invoice' confirms immediately and returns a PDF. That is meaning the schema's terse enum values do not convey.

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 ('Orders the renewal of one of the user's LEIs') and immediately distinguishes itself from the quote step and from sibling order tools like create_registration_order by naming get_renewal_quote as the required predecessor.

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: only after showing the user the price from get_renewal_quote and obtaining explicit agreement. It also branches the two paymentMethod paths with what each does, leaving no ambiguity about invocation 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?

Beyond the annotations (readOnlyHint=false, idempotentHint=true), it discloses the concrete side effect (GFR emails a password-setup link), the access boundary ('you get no access to the account from this tool'), and confirms idempotent behavior with detail ('nothing changes, and the answer is the same'). This is exactly the extra context 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?

Front-loaded with the core action, then side effects, then the hand-off path; every sentence carries information. Slightly dense with the /auth.md routing detail, but nothing is redundant.

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

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

No output schema exists, so the description need not explain returns, and it still covers the full lifecycle an agent needs: prerequisites, the email side effect, the fact that no account access is granted here, and what to do next. Nothing material 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 email, firstName, lastName, currencyCode and languageCode are already fully documented in the schema. The description reinforces that the three names/email are required and user-supplied, but adds no syntax or format meaning beyond the schema. 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 names a specific verb and resource ('Creates a Global FinReg account for a user from their email address') and states the downstream purpose (ordering and managing LEIs). It is trivially distinguishable from all four siblings, which are read-only lookup tools.

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 explicit preconditions ('Ask the user for their email address, first name and last name, and confirm them with them before calling') and explicit follow-up routing ('After the user has set a password, register for access with /auth.md and use the account tools'). It also states the no-op case when the address already has an account.

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 readOnlyHint=false and idempotentHint=true, and the description explains why: 'The first download sets the invoice date, as on the website' — a genuinely non-obvious side effect that makes the readOnlyHint=false annotation sensible. It still doesn't say what happens on repeat downloads or on failure, so it stops short of full 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 sentences, no filler, and the core behavior plus the side-effect caveat are front-loaded. Every phrase carries weight and nothing is repeated from 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 single-parameter, no-output-schema tool whose annotations cover safety and idempotency, the description is nearly sufficient: it says what it produces and flags the state-changing first download. It could still note whether the PDF is returned inline or as a link/URL.

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 already explains how to build orderId from get_renewal_quote/create_renewal_order or the LEI GUID. The description only restates the same dual nature ('registrations or renewals') without adding syntax, format, or validation detail, 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 ('Returns the PDF invoice') plus the scope ('for one of the user's LEI registrations or renewals'), which is far more useful than the tautological title 'Download invoice'. It does not, however, distinguish itself from the sibling get_invoice or list_my_invoices, leaving the agent to infer the split.

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 triggering context ('e.g. to pay a renewal ordered with payment by invoice'), which tells the agent when this tool is the right call. It stops short of explicit exclusions such as when to prefer get_invoice over this one.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely new behavioral context beyond that: the return is a human-signable PDF (not a link or JSON) and it feeds a manual sign-then-upload workflow. It stops short of noting any state requirements or failure modes.

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, both load-bearing: the first defines the artifact and format, the second routes the agent to the follow-up tool. No filler or 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 single-parameter download tool with no output schema, the description covers what is returned, its intended use, and the next step in the workflow. Minor gaps remain around prerequisites (draft application must exist) and error behavior, but 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?

Only one parameter (leiId) and schema description coverage is 100%, with the schema even naming the source tools for the GUID. The description adds no syntax, format, or constraint information beyond the schema, 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 (returns/downloads), a specific resource (the limited POA of a draft LEI application) and the output format (PDF), which cleanly separates it from the sibling download_transfer_poa and the signing-link tools. An agent knows exactly what artifact this produces without opening the schema.

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

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

Gives clear workflow context: the PDF is meant for the user to print and sign by hand, and the signed copy goes to upload_signed_limited_poa. It does not, however, contrast this with get_limited_poa_signing_link or state prerequisites such as the application needing to be in a draft state, so there is no explicit when-not guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely useful context beyond that: the artifact is a PDF requiring a wet signature, and the signed copy must be returned via upload_signed_transfer_poa. It does not say how the PDF is delivered (URL vs. binary), which keeps it off 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 short sentences with no filler; the output artifact and its purpose are front-loaded, followed by the required next action. Every clause carries information the agent needs.

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

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

With no output schema, the description correctly identifies the return as a PDF and explains the follow-up upload step, which is enough to drive the workflow. It could be slightly more complete about how the PDF is delivered to the caller, but nothing essential to correct invocation 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 description coverage is 100% and the single leiId parameter is already well documented there, including its source (start_lei_transfer or list_my_leis) and the warning that it is not the 20-character LEI number. The description adds no parameter-level information, 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 (returns/downloads), the exact resource (the transfer POA of an LEI being transferred), and the output form (PDF for hand-signing). This clearly separates it from the sibling get_transfer_poa_signing_link and from download_limited_poa without needing to open 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?

The description names the downstream step explicitly — upload the signed copy with upload_signed_transfer_poa — which tells the agent where this fits in the transfer workflow. It gives no explicit exclusion or 'when not to use' guidance versus download_limited_poa, so it stops short of a 5.

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?

Goes well beyond the annotations: one-time use, 30-minute expiry, 4 MB cap, accepted formats, and exact POST encoding. These are the operational constraints an agent needs and none are in the structured fields.

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 return value and dense with useful detail; all sentences earn their place, though the single long paragraph could be split for scannability.

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, yet the description explains the return value (uploadUrl), its lifetime, and the consumer flow, plus the follow-up call. Nothing needed 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% and idCredPub is documented there; the description only adds its provenance ('from start_concordium_company_verification'), which is marginal extra meaning. 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 ('returns a one-time link where the user uploads a document') and places it in the flow ('the regular route, step 2'). An agent can distinguish it from get_upload_link / upload_registration_document by the company-verification framing.

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?

Clear usage context: give uploadUrl to the user, or POST the file yourself if you can make HTTP requests, and call again for more documents. It also names the follow-up tool (set_concordium_signatory). It does not explicitly say when to prefer this over the sibling get_upload_link, so not a full 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered elsewhere. The description adds one genuinely useful behavioral detail: the result is scoped to the access token's acting user rather than an arbitrary user. It does not describe failure modes (e.g., invalid/expired token), but the annotations lower the bar.

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 short sentence with no waste, front-loading the operation and its scope. Nothing redundant with the title or 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 no-arg read tool with annotations covering safety and no output schema, this is essentially complete: an agent knows it returns the authenticated user. Only the auth-failure behavior is unstated, which is a minor 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?

The tool takes no parameters, so per the baseline there is nothing for the description to disambiguate. Schema coverage is 100% and empty, and the description correctly omits any parameter discussion.

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 (Returns) and resource (the Global FinReg user the access token acts for), which is unambiguous on its own. It doesn't explicitly distinguish itself from nearby siblings like get_my_lei or get_lei_record, but the resource (identity of the token's user) is distinct enough to infer the difference.

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 offers no when-to-use guidance, no prerequisites, and no reference to alternatives. An agent knows what it returns but not the context in which it should be preferred over other identity-adjacent lookups.

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

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful context by enumerating the returned content (amount, currency, paid flag), which matters because there is no output schema. It stops short of noting auth requirements or error behavior, 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?

A single front-loaded sentence that names the resource first and then the payload. Nothing is padded or redundant.

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

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

For a one-parameter read tool with full schema coverage and no output schema, the description covers the essentials and even compensates for the missing output schema by naming the returned fields. It is only incomplete in not relating itself to the list/download invoice siblings.

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 schema itself explains that orderId is the LEI GUID obtainable from list_my_leis. The description adds no parameter detail beyond that, so the baseline of 3 is appropriate.

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

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

States a specific verb and resource: returns the registration invoice for one of the user's LEIs. The 'one of the user's LEIs' scoping and the listed fields (amount, currency, paid status) make the target unambiguous. It does not explicitly distinguish itself from siblings like list_my_invoices or download_invoice, which is the only thing keeping it from 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?

There is no when-to-use guidance, no mention of prerequisites, and no routing to alternatives. An agent holding an orderId would probably reach for this, but nothing tells it to prefer this over list_my_invoices for a single invoice or to use download_invoice when it needs the PDF.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the source ('global LEI register') and the returned field list, but does not disclose error behavior for unknown LEIs, auth requirements, or rate limits.

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

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

One front-loaded sentence with no wasted words. The enumeration of returned fields is necessary because there is no output schema, and each listed item earns its place.

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

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

For a simple one-parameter read operation with no output schema, the description supplies the key return fields and the source register. Annotations cover the safety profile, so nothing essential for correct invocation 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 description coverage is 100%, so the single `lei` parameter is fully documented in the schema with its 20-character format and example. The description adds no syntax or format guidance beyond what the schema already provides, making the baseline 3 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 ('Returns') and resource ('registration record of an LEI'), and enumerates the fields returned. This clearly distinguishes it from sibling search_lei_by_company_name, which would be used when the LEI is not already known.

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?

No when-to-use guidance, prerequisites, or alternatives are provided. The description does not mention that search_lei_by_company_name is the alternative when the LEI is unknown, nor any condition for choosing this lookup over that search.

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 idempotentHint=true, destructiveHint=false and openWorldHint=true, so safety is partly covered. The description adds real value beyond that: the signing is performed by the user themselves (not the agent), it requires a director/board-member role, and the correct next call is check_registration_status. Return format is conveyed ('signingUrl') even without an 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 short sentences, zero filler: purpose first, then prerequisite and next step. Every clause earns its place and the key constraint (self-signing by a director) is 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?

For a one-parameter tool with no output schema, the description covers the action, the returned artifact, the authorization prerequisite, and the follow-up step. The only gap is not explicitly distinguishing this from get_transfer_poa_signing_link, though the 'limited POA' phrasing makes the distinction inferable.

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 required parameter at 100% schema description coverage, and the schema already explains that leiId is the GUID from start_lei_registration or list_my_leis. The description adds only the contextual hint that this is a 'draft LEI application', which is marginal; baseline 3 applies when the schema carries the parameter documentation.

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 verb and resource ('Returns the page where the user signs the limited POA') and even names the returned field (signingUrl). It is clearly distinguishable from the sibling get_transfer_poa_signing_link and download_limited_poa, which concern a different POA type or a download rather than a signing page.

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 a prerequisite ('the user must be a director or board member of the entity') and an explicit follow-up ('After they have signed, call check_registration_status'), which routes the agent through the workflow. It stops short of explicitly contrasting with the transfer-POA sibling or saying when not to use it, so it is clear context without full exclusion guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral value by disclosing what the response contains (direct and ultimate parent entity fields), which matters because there is no output schema. It does not mention error behavior for a non-owned LEI id.

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

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

A single front-loaded sentence that leads with the action and then details the returned fields. It is dense with field names, but that detail earns its place given the absence of an output schema; no filler text.

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-only lookup with full annotation coverage, the description plus schema covers nearly everything an agent needs, and the field enumeration compensates for the missing output schema. The only gap is sibling disambiguation against get_lei_record and list_my_leis.

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 schema already explains that leiId is a GUID obtained from list_my_leis and is not the 20-character LEI number. The description adds nothing beyond that, 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 gives a specific verb and resource ('Returns one of the user's LEIs with all application details') and enumerates the parent entity data returned. It is clear on its own, but it does not distinguish itself from the sibling get_lei_record or explain its relationship to list_my_leis.

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 guidance: nothing says to call this after list_my_leis, or why an agent would pick this over get_lei_record. The only routing hint ('from list_my_leis') lives in the schema's parameter description, not in the tool description itself.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds meaningful context beyond annotations: prices exclude VAT, cover both new and renewal registrations, multiple terms, and the optional fully assisted service, plus a pointer to the quote tools for VAT-inclusive totals. It does not mention auth or caching, but for a static price list those omissions are minor.

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

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

Two sentences, front-loaded with the core purpose, using semicolons and lists to pack in precise scope without filler. The second sentence efficiently handles the alternative-tool routing. Every clause earns its place.

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

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

With no output schema and zero parameters, the description still describes the return fields ('pricePerYear' and 'total') and the VAT exclusion, and clarifies the domain (new registration vs renewal, 1/3/5 years, assisted service). Nothing needed to call this tool 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 and schema description coverage is 100%, so the baseline is 4. The description neither needs to nor does document any parameters, and it introduces no ambiguity.

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 ('Returns') and resource ('Global FinReg's LEI prices'), then enumerates the exact scope: every supported currency, excluding VAT, for new registration and renewal, across 1/3/5-year terms, with pricePerYear and total. It also distinguishes itself from get_registration_quote and get_renewal_quote, so an agent can tell it apart from any 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?

Explicitly routes the agent to alternatives: 'For the exact total for one LEI, including VAT, use get_registration_quote or get_renewal_quote.' That gives a clear when-not condition and names the correct tools, leaving no inference needed.

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 say readOnlyHint=false, idempotentHint=true, openWorldHint=true. The description adds real behavioral context beyond them: the quote depends on POA signing state, reflects the account's currency setting, may return an already-started unpaid order, and surfaces a vatNote conditional that drives a follow-up VAT 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?

Front-loaded with the return content and dense with decision-relevant instructions, with no filler. The sentence 'The limited POA must be signed first, or (download, email) on its way' is garbled and costs some clarity.

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, yet the description enumerates the returned fields and even an edge-case field (vatNote) and side data (existing unpaid order). Combined with schema documentation of all four parameters, an agent has everything needed to call and interpret it.

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 adds value by explaining the conditional trigger for vatCountry/vatNumber ('if vatNote says VAT could be taken off') and the requirement to reuse the same VAT pair on the order tool. It does not add much about the leiId or years semantics 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+resource ('Returns the price of registering a draft LEI application') and enumerates the returned breakdown (net, VAT, total, currency, payment methods, existing unpaid order). It is clearly distinguishable from siblings like get_renewal_quote and get_prices by scoping to LEI registration.

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 sequencing and alternatives: POA must be signed first, ask the user for currency and use set_currency if unstated, request vatCountry/vatNumber when vatNote indicates VAT removal, and confirm the price with the user before calling create_registration_order. Both when-to-use and when-not-to-proceed are covered.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds that the response includes amount, duration and paid status, which is useful, but says nothing about format, missing-order behavior, or permissions.

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

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

A single front-loaded sentence with no filler; the resource and the notable return fields come first. It could carry one more sentence of routing or constraint context without becoming bloated, but nothing present 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 simple get-by-id read tool, annotations cover safety, the one parameter is fully documented in the schema (including id construction), and the description names the key returned fields, so an agent can call it correctly. Missing sibling routing and any partial-return caveat keep it from being fully complete.

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

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

Schema coverage is 100% and the single parameter's schema description already explains how to construct the id (LEI GUID + 'Renewal' + year, with the expiry-year rule). The description adds no parameter 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 and resource ('Returns a renewal order') and scopes it to 'one of the user's LEIs', which is clear enough for an agent to distinguish it from the create/list/quote siblings. It does not explicitly differentiate from the nearby get_renewal_payment_status or get_renewal_quote, 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?

There is no when-to-use guidance and no mention of alternatives such as get_renewal_payment_status (paid status) or get_renewal_quote (pricing), even though the description itself surfaces 'whether it is paid'. Retrieval by id is implied, but the agent is left to infer when this tool is the right choice.

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, closed-world), so the bar is lower. The description still adds value by naming the payment channels checked and, importantly, disclosing the return shape ('true or false') in the absence of an 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 short sentences, no filler, with the core action front-loaded and the return type trailing as a useful clarification.

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 boolean check with no output schema, the description supplies the return type and payment coverage, which is close to sufficient. It does not address failure or not-found behavior (e.g., unknown order id), which is the remaining minor 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?

Schema description coverage is 100% and the single parameter's description is already detailed (GUID + 'Renewal' + year, with the expiry-year edge case). The description adds no further meaning about renewalOrderId, 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 and resource (checks whether a renewal order has been paid) and enumerates the accepted payment routes (card via NETS/Stripe, or bank transfer). It is clearly separable from the other check_* status siblings because it is scoped to renewal orders.

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: an agent can infer this is called after create_renewal_order to confirm payment. There is no explicit when-to-use statement, no mention of the related get_renewal_order or download_invoice siblings, and no stated prerequisites.

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 stays consistent while adding context the annotations cannot: the exact price breakdown returned, the presence of payment methods, and that any already-started unpaid renewal order is surfaced. It does not discuss pagination, error cases, or what happens to a stale quote, 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?

Dense but front-loaded: what it returns comes first, then the currency prerequisite, then the VAT branch, then the confirmation requirement before ordering. Every sentence carries an instruction, though the single long paragraph could be split into steps for faster scanning.

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 quote tool with no output schema, the description supplies the return shape, the currency prerequisite, the VAT-number branch, and the hand-off to create_renewal_order. An agent has everything needed to call it and act on the result without further discovery.

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 real semantics beyond the schema: it explains the conditional trigger for vatCountry/vatNumber (vatNote says VAT may come off) and the cross-tool rule that the same VAT pair must be passed to the order tool. The leiId source is only documented in the schema, not the description.

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 ('Returns the price of renewing one of the user's LEIs') with scope (1, 3 or 5 years) and enumerates the returned fields. It is clearly distinguishable from get_prices, get_registration_quote and get_renewal_order 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 explicit preconditions and routing: if currency is unspecified, ask the user and call set_currency; if vatNote indicates VAT is removable, collect the EU VAT number and pass vatCountry/vatNumber. It also names the downstream tool (create_renewal_order) and states the required user agreement step before calling it.

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 readOnlyHint=false with idempotentHint=true, and the description explains why: this produces a link the user must personally sign, constrained to directors/board members, followed by a status check. That actor-permission requirement and the human-in-the-loop flow are real context beyond the annotation flags, though nothing is said about link expiry or regeneration.

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: what it returns first, then the actor constraint, then the next step. No filler and nothing buried.

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 annotations covering the safety profile, a single well-documented parameter, and no output schema, the description supplies preconditions, actor requirements, and the follow-up call. The only omission is link lifetime/validity, which is minor for this kind of 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?

Only one parameter, and the schema description already documents it fully (GUID from start_lei_transfer or list_my_leis, explicitly not the 20-character LEI number) at 100% coverage. The description adds no syntax or sourcing 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 and resource ('Returns the page where the user signs the transfer POA of an LEI'), names the returned artifact (signingUrl), and scopes it to 'a transfer waiting for its POA'. The 'transfer POA' wording cleanly separates it from the sibling get_limited_poa_signing_link without needing 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 a clear precondition (transfer waiting for its POA) and an explicit post-action routing to check_transfer_status, plus the actor constraint that the user must be a director or board member. It never states when not to use it or names the limited-POA alternative, so it falls just short of full when/when-not 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 only declare the generic profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false); the description goes well beyond by disclosing that the link is single-use, expires in 30 minutes, accepts PDF/JPG/PNG up to 4 MB, and can be consumed either via browser or as multipart/form-data (field 'file') or a raw body. That is exactly the operational context an agent needs and cannot get from the structured fields.

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 dense sentences that are front-loaded with the return value and scope, then usage, then mechanics, then follow-up. Every sentence carries information, though the HTTP-POST sentence and the browser-upload sentence could be tightened slightly without loss.

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

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

With no output schema and only two params, the description still covers what comes back (uploadUrl), its lifetime and one-time nature, accepted formats and size, both submission methods, and the correct next tool to call. Nothing needed 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 both leiId and document are already fully documented in the schema, including the source tools for leiId. The description restates the document categories but adds no format, constraint, or edge-case detail beyond the schema, 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 (returns a one-time upload link / uploadUrl) and scopes it to concrete document types: limited POA, transfer POA, or supporting documents of a new LEI application. An agent can immediately distinguish it from the sibling base64 upload tools (upload_registration_document, upload_signed_limited_poa, upload_signed_transfer_poa).

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 names the alternative and the condition that selects it: 'Use this instead of the base64 upload tools for any file you can't pass exactly as text, which is most PDFs.' It also prescribes the follow-up path (check_registration_status or check_transfer_status) and both invocation modes (user browser vs. direct HTTP POST).

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 the safe, non-openWorld profile, so the description does not need to re-establish safety. It does add one genuine behavioral rule — LEIs with a renewal already in progress are excluded — which prevents a misread of the result set, but says nothing about ordering, pagination, or empty results.

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

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

A single front-loaded sentence with the return type and both filter conditions, and zero filler. Nothing could be removed without losing information.

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

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

For a zero-parameter read tool with no output schema, stating that the return is a set of LEI ids plus the two inclusion/exclusion criteria is sufficient to call and interpret it. It is only lightly thin on what an agent should do next with those ids.

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

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

The tool takes no parameters, so there is no parameter semantics burden and the description cannot be faulted for gaps; baseline 4 applies. Nothing in the schema-needed sense is missing.

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

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

States a specific verb and resource (returns the ids of the user's LEIs) plus a precise filter condition (due for renewal, no renewal in progress). It is distinguishable from list_my_leis by the filter, though it never names the sibling to sharpen the contrast.

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 purpose implies the usage context — checking which LEIs need a renewal order — but there is no explicit when-to-use statement, no exclusion of alternatives such as list_my_leis or get_my_lei, and no indication of what to do with the returned ids.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds useful scope context (registration and renewal invoices only), but says nothing about pagination, ordering, or whether results are scoped to the authenticated user versus all users.

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 short sentence with the resource front-loaded and zero filler. Nothing could be trimmed without losing meaning.

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

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

With no parameters, no output schema, and annotations covering the read-only safety profile, the description is nearly sufficient for an agent to call it correctly. It could do slightly more by noting result shape (list of invoice records) or pagination behavior, but the gap is minor for a zero-argument listing tool.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain; the baseline of 4 applies. The description correctly implies no filtering inputs are needed.

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

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

States a specific verb and resource (lists the user's invoices) and narrows the scope to LEI registrations and renewals. It does not explicitly differentiate itself from close siblings like get_invoice or download_invoice, but an agent can infer this is the collection-level listing.

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: nothing tells the agent to call this for an overview rather than get_invoice (single record) when an ID is known, and no prerequisites or auth requirements are stated. The description only supplies the purpose, leaving selection entirely 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 safety (readOnly, idempotent, non-destructive, closed-world), and the description adds the return content and user scope. It still omits ordering, pagination, auth requirements, and empty-result behavior, so it is helpful 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?

A single front-loaded sentence with no filler; the parenthetical is dense but earns its place by naming consumers of the returned id.

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-parameter read-only list with no output schema, it describes the returned fields and the key id dependency, which is close to complete. It could be stronger by stating ordering or whether an empty list is returned.

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 are no input parameters, so there is no parameter semantics to clarify; per rubric this is baseline 4. The description adds no parameter info because none exists.

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 ('Lists') and resource ('all LEIs of the user'), and the 'all' scope plus mention of get_my_lei makes clear it is the collection counterpart to the single-record getter. The returned fields are 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?

Gives clear usage context by explaining that the returned id is used by get_my_lei, get_invoice, and renewal order ids, helping an agent choose it when it needs an identifier. It does not state when not to use it or explicitly contrast list_leis_due_for_renewal.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds non-obvious behavior beyond that: the precedence of elfCode over localName and the fact that regionCode is only relevant for region-varying countries. It does not disclose failure behavior when no match is found.

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

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

A single front-loaded sentence with the verb, the resource, and the lookup precedence packed in; no filler, no restatement of the title, and the optional-region caveat is placed last where it belongs.

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 four-parameter read-only lookup with full schema coverage and annotations covering safety, the description is nearly sufficient — it explains purpose, precedence, and region scoping. The one gap is that with no output schema it does not indicate what is returned or what happens on a miss, which for a lookup tool an agent would benefit from knowing.

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 four parameters are already documented with examples (H8VP, Anpartsselskab, DK). The description adds meaning the schema does not: the lookup precedence between elfCode and localName, and the conditional applicability of regionCode. That is a modest but real gain over the baseline 3.

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 (looks up) and a precisely scoped resource (an entity legal form from the ISO 20275 ELF code list, within a country). The ISO standard reference and the country scoping make the tool unmistakable, and no sibling (create_user, get_lei_record, get_prices, search_lei_by_company_name) overlaps with 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?

The description gives an explicit resolution order — 'by ELF code first, otherwise by the legal form's local name, optionally within a region' — which tells the agent exactly which parameter to prefer and when regionCode applies. It stops short of stating what to do when neither code nor name resolves, so it is clear context rather than a full when/when-not guide.

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, openWorld, non-destructive), so the bar is lower. The description adds value by naming the returned fields (LEI, country, GlobalFinReg lookup link), which annotations do not convey; it omits anything about result ordering or partial-match 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 zero filler: the first states the action and scope, the second states the return contents. Nothing is buried or redundant.

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

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

With no output schema, the description usefully compensates by enumerating the returned fields, and the input contract is fully covered by the schema. It omits pagination/truncation behavior when more than 'limit' entities match, which is the only notable gap for a search tool.

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

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

Schema coverage is 100% - both 'query' (3-character minimum) and 'limit' (1-50, default 10) are fully documented in the schema. The description adds no syntax or format detail beyond what the schema already provides, 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 ('Searches the global LEI register by legal entity name'), which is far more informative than the title alone. It is distinguishable from siblings like get_lei_record by the name-based lookup, though it never explicitly contrasts itself with them.

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: an agent can infer you call this when you have a company name and want its LEI. There is no explicit when-to-use, when-not-to-use, or pointer to alternatives such as get_lei_record for lookups by an already-known LEI.

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=false, idempotent=true, non-destructive, openWorld), so the bar is lower. The description still adds real context: it is a mutation that must be user-confirmed before submission, LEI details override manual fields, and how it chains to document upload.

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?

Purpose is front-loaded and every sentence carries routing or parameter-selection information. It is dense and slightly run-on as a single paragraph listing many fields, but there is little waste.

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

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

For a 13-parameter mutating workflow tool this is close to complete: it gives the step position, the branch logic, the confirmation requirement, and the next tool. No output schema exists, but for a setter that is acceptable; only the alternative routes are left unnamed.

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 every parameter and the baseline is 3. The description adds the conditional grouping (leiNumber vs. the registration set) and flags which fields are optional 'if you know them', but no syntax or format 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+resource ('sets the company the Concordium identity is for') and situates itself as 'the regular route, step 1'. It names the follow-up sibling (get_concordium_document_upload_link) and lookup_legal_form, so an agent can place it in the flow 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?

Gives an explicit branch condition: supply leiNumber if the company has an LEI (details pulled from the LEI record), otherwise the registration fields. It also states a prerequisite ('Confirm the details with the user first') and the next step. It does not, however, name the alternative routes it contrasts 'the regular route' against, so a sibling-exclusion is only implied.

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

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

Goes well beyond the annotations by disclosing that calling again replaces the person (consistent with idempotentHint=true), that the response contains personVerificationUrl, and exactly what the signatory must do next (sign in, Veriff passport/licence photo and selfie, camera needed). It also states the name must match the ID and company documents, which is real operational context.

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 workflow position and the core action, then layers in operational detail. It is somewhat long with a few stacked clauses, but each sentence carries useful information with no padding.

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

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

Despite having no output schema, the description explains the meaningful return value (personVerificationUrl) and its downstream flow. Combined with the input requirements and replacement semantics, an agent has everything needed to call it 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 all five parameters are already documented. The description reinforces that name, email and phone come from the user and that idCredPub originates from start_concordium_company_verification, but adds little syntax or format detail beyond the schema, making the baseline 3 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 ('sets the company's UBO or authorised signatory') and clarifies who that person is ('the person whose ID is checked'). It is clearly distinguishable from siblings like set_concordium_company_details and start_concordium_company_verification.

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?

Positions the tool in the workflow ('the regular route, step 3') and tells the agent to collect name, email and phone from the user, plus the idCredPub linkage to start_concordium_company_verification. It lacks explicit when-not/alternative guidance (e.g. when to use the non-regular route), so it falls short of a 5.

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=false, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavior beyond that: switching currency also switches the card payment provider (NETS or Stripe), and accounts with agreed partner prices are blocked. It does not say what happens to in-flight quotes/orders or what an error looks like in the blocked case, so it falls just 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?

Four sentences, all substantive: definition and scope first, then the side effect, then the pre-call workflow guidance, then the limitation. No filler, and the most decision-relevant information is 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?

For a one-parameter mutation tool with no output schema and rich annotations, the description covers everything an agent needs: what changes, the downstream effects, when to invoke it, which tools to consult first, and when it will fail. Nothing material 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% and the single currencyCode parameter is already documented with format and examples (EUR, DKK, SEK, NOK, GBP, USD) in the schema. The description adds no format or validation detail beyond what the schema provides, 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+resource ('Changes the currency on the user's account') and immediately scopes it by explaining that every quote and order (renewals, new registrations, checkouts) uses it. No sibling tool performs currency changes, and the description also discloses the secondary effect on the card payment provider, so an agent can distinguish this from quoting/pricing tools like get_prices.

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 both ways: 'ask the user which currency they want to be charged in, unless they already said' and 'Only call this when the user asked for another currency.' It routes the agent to supporting tools (get_current_user for the current currency, get_prices for prices) and states an exclusion case (accounts with agreed partner prices cannot change currency here).

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, idempotentHint=true), and the description adds real behavioral context beyond them: the wallet-originated precondition and the fact that the response enumerates two selectable routes ('fast' vs 'regular') with their eligibility criteria. It does not mention auth requirements or failure modes.

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 action, then the prerequisite, then the parameter instruction and the return shape. It is longer than most definitions but nearly every sentence carries operational information; a little compression of the route descriptions is possible.

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 mutation tool with no output schema, the description compensates by describing the two returned routes and the user-choice requirement. What remains unstated is authorization needs and what happens on repeat invocation, though idempotentHint covers part of that.

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

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

Schema coverage is 100% and the schema already gives the link format and example, so the baseline is 3. The description adds value by explaining where the value comes from ('Ask the user for that whole link') and that either the full URL or just the IdCredPub is acceptable.

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 ('Starts verifying a company for a Concordium company identity') and situates it in the wallet-initiated flow, which separates it from status-check siblings like check_concordium_verification_status and from set_concordium_company_details.

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 ('The request always starts in the wallet') and an explicit instruction to ask the user for the whole link and pass it here, plus the rule to always let the user choose the route. It does not name sibling alternatives or say when not to call it, so it stops short of a 5.

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?

Beyond the annotations (readOnlyHint=false, idempotentHint=true, openWorldHint=true), it states that the application is saved as a draft, that the poaMethod='sign' path returns a signingUrl, that 'download' needs a later upload_signed_limited_poa, and that calling again returns the existing application. This is behavioral context annotations cannot express.

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 front-loads the core action and the POA prerequisite early, and every sentence carries information. It is a long, run-on block though, so the POA option list could be easier to scan if separated.

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 with no output schema, the description covers the return signals ('documentsNeeded', what to do next, signingUrl) and the multi-step POA flow, leaving no obvious gap in what an agent needs to call it 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 base is 3, but the description adds real meaning: it ties the poaMethod choices ('sign', 'email', 'download') to their consequences and names the required parent-entity branches for 'application'. Minor gap: it doesn't re-note the signer* fields, but those are already well documented in the schema.

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

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

A specific verb and resource ('Starts an application for a new LEI in the user's account, saved as a draft') plus an explicit boundary against start_lei_transfer when the entity already has an LEI with another issuer. An agent can separate this tool from its siblings from the first sentence 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?

It gives an explicit pre-check (search_lei_by_company_name), a rule for the alternative (if it has one with another issuer, use start_lei_transfer), and an explicit instruction to ask the user about poaMethod before calling. When-to-use and when-to-use-something-else are both stated.

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

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

Annotations already declare readOnly=false/idempotent=true, but the description adds substantial context: free of charge, the legal POA requirement, what each method returns (signingUrl), the renewalRequired signal when the LEI expires within two months, and explicit idempotency behavior ('Calling again ... returns the transfer already started'). This goes well beyond structured 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?

Purpose and the call-before instruction are front-loaded, and every clause earns its place given a 9-parameter, branching flow. The semicolon-dense enumeration of POA methods is information-rich rather than padded, though it is a long single block that 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?

With no output schema, the description compensates by naming the meaningful return signals (signingUrl, renewalRequired, already-started state) and the renewal interplay. For a 9-param mutation with branching flows it gives the agent everything needed to call it 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 baseline is 3, but the description adds cross-parameter semantics: poaMethod values, and which optional params apply per method (signerRole for 'sign', signerEmail/name/position for 'email') plus the user-default fallbacks. That is meaningful routing logic beyond the flat schema, though it still defers to the schema for types/formats.

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

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

Starts with a specific verb+resource ('Starts the transfer of an LEI ... to Global FinReg') and scopes it to the user's account. It is clearly distinguishable from siblings like start_lei_registration and create_renewal_order, and it flags the free-of-charge nature and the POA prerequisite up front.

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 instructs the agent to ask the user about poaMethod before calling, then enumerates the three options with the condition that selects each ('sign' if the user is a director/board member, 'email' to delegate, 'download' to print-and-upload). It also names the follow-up tool upload_signed_transfer_poa for the download path and warns about the renewal case.

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=false and idempotentHint=false; the description adds real context beyond that: the append-not-replace behavior ('each call adds one document'), the input format constraint (base64 text), and the accepted file types/size. It stops short of describing failure modes (e.g. upload to a non-draft application) or rate limits, so it is strong but not complete.

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 action and constraints, then the trigger condition, then the alternative-path routing. No redundancy and no filler; every clause carries an operational constraint.

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

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

With no output schema and 100% schema coverage, the description covers what an agent needs: format, size, trigger, per-call behavior, and the sibling alternative. It leaves minor gaps around what happens after upload (e.g. needing to re-check registration status) and whether duplicate documentType uploads are allowed.

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 each of the three parameters is already documented, so the baseline of 3 applies. The description does add illustrative document examples (business register extract, articles of association, fund prospectus) that hint at which documentType values matter in practice, but it does not explain the enum values themselves beyond what the schema lists.

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 ('Uploads a supporting document for a draft LEI application') and immediately constrains scope with accepted formats and the 4 MB size cap. It is clearly distinguishable from the sibling get_upload_link, which it explicitly names as the alternative path for PDFs.

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 trigger condition ('Needed when start_lei_registration or check_registration_status says documentsNeeded') and an explicit routing rule for when NOT to use it ('for a file you can't pass exactly as text (most PDFs) use get_upload_link'). It also states the per-call semantics ('Each call adds one document'), so an agent knows whether one call is enough.

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 mutation profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false), but the description adds real behavioral context not present there: the 4 MB size ceiling, the accepted MIME types (PDF/JPG/PNG), the base64 encoding requirement, and an anti-fabrication guardrail that the POA must be one the user actually gave as signed.

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, each earning its place, with the core action and payload described first and the routing rule and precondition following. No filler or 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 write tool with no output schema, the description covers format, size, encoding, the fallback path, and the trust precondition. It does not say what happens if a POA was already uploaded (the idempotentHint implies replacement) or whether the application must be in a particular draft state, which are the only meaningful gaps.

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 meaning beyond the schema for 'content': the 4 MB ceiling and the accepted formats, which are not stated in the property description ('base64-encoded'). It does not add anything for leiId, which the schema already sources from start_lei_registration/list_my_leis.

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 (uploads) plus the exact resource (the hand-signed limited POA for a draft LEI application) and the transport form (base64 text). It is clearly distinguishable from the sibling upload_signed_transfer_poa and from get_upload_link, which it names directly.

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 when-to-use ('files small enough to pass exactly as text'), when-not ('for anything else (most PDFs)'), the named alternative with the argument to pass (get_upload_link with document 'limited_poa'), and a precondition ('Only upload a POA the user gave you as signed'). Nothing is left to inference.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond them: the accepted formats and 4 MB cap, that content must be base64 text, and what happens downstream ('Global FinReg then checks the transfer and sends it to the LEI's current issuer'). It stops short of describing the response or failure modes.

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 core action and constraint, then the routing alternative, then the downstream effect. It is dense with parentheticals but every clause carries information; nothing is 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?

No output schema exists, so the description correctly explains what happens after upload. Combined with annotations covering idempotency and non-destructiveness, an agent has enough to call it correctly; only the return/error shape is 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 and the schema already explains both parameters. The description nonetheless adds meaning for 'content' that the schema omits – accepted formats (PDF/JPG/PNG) and the 4 MB size ceiling – and frames 'leiId' as a transfer awaiting its POA.

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 ('Uploads the transfer POA the user has signed by hand'), plus the file formats and size limit, and distinguishes itself from the sibling get_upload_link and from upload_signed_limited_poa. An agent can tell exactly which upload path this is.

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 names the boundary condition ('Only for files small enough to pass exactly as text') and the alternative with its exact argument ('for anything else (most PDFs) use get_upload_link with document "transfer_poa"'). It also adds a precondition guardrail: only upload a POA the user gave you as signed.

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, openWorld, non-destructive, so the description correctly spends its words on what annotations cannot say: VIES may be unavailable, invalid numbers surface as errors rather than a negative result, and some countries withhold name/address data. It also tells the agent to confirm the returned entity with the user before proceeding, which is real operational guidance.

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

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

The purpose and the when-to-use condition are front-loaded, and the return/error behavior closes the paragraph. It is a dense single paragraph; a sentence break before the return-value discussion would aid scanning, but no sentence is 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 two-parameter read with no output schema, the description covers everything an agent needs: what it validates, what it returns, the caveat that some fields may be absent, how failures appear, and where the result feeds next. Nothing material is left to inference.

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

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

Schema coverage is 100%, so the baseline is 3; the description goes beyond it by explaining that vatCountry and vatNumber are the values carried forward into the quote and order tools, making their downstream role concrete. It does not restate the formatting rules already in the schema, which is 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?

The description names a specific verb and resource (checks an EU VAT number) and identifies the authoritative backend (the EU's VIES service), plus the business framing ('as the website does before an order'). That is enough for an agent to distinguish it from every sibling, none of which touch VAT.

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 exact triggering condition ('when a quote adds VAT for an entity in another EU country and the user gives its VAT number'), the outcome of a hit (reverse charge removes VAT), and the follow-up path (pass vatCountry/vatNumber to get_renewal_quote, get_registration_quote, or the order tool). Alternatives and post-conditions are both explicit.

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