SecureLend Underwriting

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

Annotations already indicate this is a non-readonly, non-destructive write. The description adds key behavioral details: it drafts but does not send, and returns an existing draft for repeated identical misses, which is important idempotency information. It lacks details on permissions required or where the draft is stored.

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

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

Three tight sentences, front-loaded with the primary output (naming missing items), then the conditional draft behavior, then idempotency. Every sentence earns its place with no wasted words.

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

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

For a single-parameter tool with no output schema, the description covers purpose, side effects, and idempotency. It could more explicitly describe the return shape (e.g., list of missing items plus draft object), but it is largely complete for an agent 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% with caseId documented as CaseSchema.id. The description adds no parameter semantics beyond what the schema provides, so the baseline score 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?

The description specifies the core action (identify missing pack documents and required numbers) and the side effect (draft a chase email without sending it). It distinguishes from a send tool by stating 'does not send it', but does not explicitly contrast with siblings like draft_memo_from_file, so it falls short of full sibling differentiation.

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: use when chasing missing documents. It gives a condition for drafting (file has borrower email) but does not state when to use this tool versus alternatives or mention prerequisites like the case existing. No explicit when-not guidance is provided.

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

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

Adds real value beyond the readOnly/non-destructive annotations: it discloses the privacy posture of the blind registry and explicitly enumerates the only fields returned, including negative guarantees ('never returns lender identity or invoice details'). It does not explain token-vs-fields precedence or what happens if both are supplied.

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: purpose first, accepted inputs second, return contract third. No redundant restatement of the name or title and nothing that fails to earn its place.

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

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

With no output schema, the description correctly compensates by listing the returned fields and their limits, which is what an agent needs to interpret the result. The only remaining gap is validation behavior for partial or mixed input modes.

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

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

Schema coverage is 100%, so the baseline is 3; the description earns an extra point by clarifying that the token is an alternative path to the five field parameters rather than an additional filter, a relationship the schema alone does not make explicit. It still does not say which fields are mandatory when the field-mode is chosen (required parameters list is empty).

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 ('Check whether an invoice has already been financed') plus the scope ('on the blind registry'), so there is no ambiguity about what the call does. It does not explicitly name the sibling write paths (register_financed_invoice / release_financed_invoice), so sibling differentiation is left implicit.

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 concrete invocation guidance by naming the two accepted input modes: the five invoice fields, or a token. It does not state when to prefer this over alternatives such as read_package or screen_sanctions, so context is clear but exclusions are absent.

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 not read-only and not destructive, so the mutation profile is partly covered. The description usefully adds the non-deterministic source rule (tenant model when saved, otherwise file template), but says nothing about whether a memo is persisted, whether repeat calls overwrite, or what permissions/costs are involved.

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

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

Three short sentences, zero filler, with the core action front-loaded. Nothing is padded or restated for its own sake.

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

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

There is no output schema, and the description never indicates what comes back (memo text, a draft object, an ID) or where the result lives, which matters for a non-read-only generation tool. The input side is fully covered by the schema, so the gap is limited to return 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% and the single param already carries the 'CaseSchema.id' description, so the schema does the work. The description's 'Same CaseSchema.id as Draft from file' only reinforces that, adding no new syntax, format, or sourcing guidance.

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: drafting a credit memo from the case file, which is clearly distinct from the read/open/walk siblings. The secondary sentence references 'Draft from file', a tool not present in the sibling list, which is mildly confusing but doesn't obscure the core purpose.

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

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

No statement of when to choose this over alternatives or whether it is a terminal step after read_case/walk_credit_file. The implicit comparison to 'Draft from file' hints at an alternative but never says which condition selects which tool.

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

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

Annotations already declare a non-read-only, non-destructive, closed-world mutation, so the safety profile is covered. The description adds one genuinely useful behavioral fact — that any tenant id in the arguments is ignored and the caller's tenant is always used — but says nothing about duplicate handling, idempotency, or what a successful open returns.

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

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

Three short sentences with the scope constraint front-loaded and no padding. The middle sentence ("Same record as New file") is the only one of questionable value given it names an internal concept the agent may not resolve.

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?

A creation tool with no output schema should at minimum say what comes back (e.g., the new case id) so the agent can chain into read_case or walk_credit_file. Combined with four params at 25% coverage and no required-field guidance, an agent cannot confidently construct a correct call from this description.

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

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

Schema coverage is only 25% (just the optional `id`), and the description explains none of email, source, or legalName, nor what happens when all are omitted since nothing is required. Worse, its one parameter-related claim concerns a "tenant id in the arguments" that does not exist in a schema with additionalProperties=false, so it cannot guide actual argument construction.

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 ("Open a case") and scopes it to "the caller's tenant", which is meaningful. The cross-reference "Same record as New file" gestures at equivalence with a UI action but assumes the reader knows what "New file" is, and siblings like read_case are not contrasted.

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 statement of when to call this versus read_case, chase_missing_documents, or start_underwriting_package, and no prerequisites (what must exist on the tenant before a case can be opened). Only an implied usage from the verb "Open".

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds a useful behavioral constraint – 'No storage keys' – and enumerates returned data, which helps the agent understand the response shape 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?

One front-loaded sentence with zero waste: the verb and resource come first, followed by a compact field list and a security note. Every segment 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?

Given a read-only tool with full annotation coverage, no output schema, and a single well-documented parameter, the description is complete. It lists the returned data fields and notes the exclusion of storage keys, which is exactly 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 description coverage is 100%, and the single parameter caseId is documented in the schema as 'CaseSchema.id'. The description does not add any syntax or format details beyond the schema, but baseline 3 is appropriate when the schema fully covers the parameter.

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 'Read' and resource 'one case', then enumerates the fields returned. It is clearly distinguishable from siblings like read_package or read_listed_company by its case-centric scope, though it does not explicitly name or contrast those alternatives.

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

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

The description says what the tool returns but gives no guidance on when to use it versus sibling tools such as walk_credit_file or read_package. No prerequisites, when-not conditions, or alternative paths are mentioned.

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 openWorldHint=true, and the description correctly discloses the write side effect plus its conditional guard ("ambiguous names write nothing"), which is genuinely useful. However, it omits that omitting caseId will open or reuse a case (that only appears in the schema), and says nothing about external-source failures despite openWorldHint=true.

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, verb and resource front-loaded, with the conditional side-effect caveat in the second position where it belongs. No filler.

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

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

For a 4-parameter, open-world tool that can mutate case state with no output schema, the definition leaves important gaps: what the tool returns, whether a case is created when caseId is omitted, and how lookup failures surface. The safety profile is covered by annotations, but the identification-parameter ambiguity remains unaddressed.

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

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

With only 50% schema description coverage, the description must compensate and does not. It never explains the cik-vs-query duality, which is the key decision for this tool, nor the meaning of asOf beyond the schema's format hint.

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 ("Fetches the annual filing") and adds the non-obvious side effect (attaches a citation to the open case). It does not distinguish itself from the sibling resolve_listed_company, which an agent would plausibly confuse with a company-lookup step.

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?

"when the company resolves uniquely" and "Ambiguous names write nothing" imply usage context, but there is no explicit routing: nothing says to call resolve_listed_company first, or when to prefer cik over query. Alternatives are 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?

With readOnlyHint/destructiveHint already covering the safety profile, the description still adds real context: it will not re-run checks (so results may be stale relative to the current file) and the POST requires an OAuth bearer token with scope 'lender'. It stops short of describing what the returned package contains or any size/pagination 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?

Four short sentences with zero filler, and the core action is front-loaded before the behavioral and auth caveats. The 'POST' phrasing is slightly awkward for a read tool but not wasteful.

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

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

Coverage of auth, idempotency, and identifier choice is good, but with no output schema and no parameter descriptions the caller is left without any sense of what a package response contains or how ambiguity in the two identifiers resolves. Adequate but with clear 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 0%, so the description must carry parameter meaning. It does clarify that packageId and caseId are alternative lookup keys scoped to the caller's workspace, but it never explains the difference between a package and a case identifier, which one wins if both are supplied, or any expected format.

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 ('Read an underwriting package') and adds a scoping clause ('Does not re-run the checks') that separates it from the write-side sibling start_underwriting_package. It does not explicitly name read_case vs read_package, so the sibling differentiation is only partial.

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

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

'Does not re-run the checks' implies you should go elsewhere (likely start_underwriting_package) to execute checks, and 'Pass packageId or caseId' tells the caller either identifier works. However, no alternative tool is named and no when-not condition, precedence rule, or behavior for passing both/neither is given.

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

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

Annotations only cover the safety profile (not read-only, not destructive, closed-world); the description adds genuinely non-obvious behavior: only a keyed HMAC token and registrar hash are persisted, and a conflict result is returned when another lender has registered the invoice. It stops short of saying what happens on same-lender re-registration (idempotency) or what a successful response contains.

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: purpose first, then the privacy guarantee, then the conflict outcome. Every sentence carries distinct information with no repetition of 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 mutation tool with annotations covering safety and a fully documented schema, the description supplies the two things structured fields cannot: what data is actually persisted and the duplicate-registration outcome. The remaining gap is the success-path return value and the all-optional parameter contract, which is a minor omission given the rich schema.

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

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

Schema coverage is 100%, so every parameter already has a description; the description's only added semantic is that supplier, debtor, invoice number, and amount are hashed rather than stored, which clarifies their handling but not their requiredness. It does not address that all seven parameters are optional or how caseId/purchaseId relate to the direct fields.

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 ('Register a financed invoice') plus the destination ('blind anti-fraud registry'), which is far more informative than the title alone. It does not name or distinguish against the close siblings check_invoice_financed and release_financed_invoice, so the agent must infer the boundary itself.

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 phrase 'another lender already registered it' — the reader infers this is the write counterpart to check_invoice_financed, but that tool is never named and no when-not-to-use condition (e.g. before/after check) is given. No prerequisites or ordering guidance are 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?

The description says 'Delete', yet the annotations declare destructiveHint=false and readOnlyHint=false, which understates an irreversible removal of a registry record. The added authorization constraint ('Only the registering workspace can delete its token') is genuinely useful context that annotations do not provide, which keeps this above a 1.

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

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

Two sentences, no filler, with the action and the permitted trigger front-loaded before the permission caveat. 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?

The description only covers the token-deletion path and ignores the second mode exposed by the schema, where caseId plus purchaseId release a purchase row from Book. With 8 optional parameters and no output schema, the agent is left to infer which parameter combination is valid for which mode.

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 every parameter including the optional token, caseId and purchaseId is already documented in the schema. The description adds no format or combination guidance beyond the note about token ownership, 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 — 'Delete a financed invoice registration from the blind anti-fraud registry' — which is clearly distinguishable from the sibling register_financed_invoice. However, it never names the counterpart tool, so the agent must infer the pairing itself.

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 lifecycle trigger ('when the invoice is paid off or withdrawn') that tells the agent when this tool applies. It stops short of naming alternatives, so it does not help the agent decide between releasing by token versus by case/purchase row, or versus check_invoice_financed first.

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, destructiveHint=false, openWorldHint=true, so 'Writes nothing' largely repeats structured data. The genuinely additive disclosure is that ambiguity yields candidates rather than an error, but permissions, rate limits, and candidate resolution policy remain unstated.

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

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

Three terse, front-loaded sentences with no filler; the return-shape sentence is the most valuable. 'Writes nothing' is mildly redundant against the readOnlyHint annotation.

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

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

There is no output schema, so the description must characterize the response, and 'the candidates' is left undefined (count, fields, confidence). For an entity-resolution tool where ambiguity is the central behavior, this leaves an agent without enough to act on a multi-candidate result.

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

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

Schema coverage is 50%: asOf documents only its format, and query has no schema description. The description compensates for query by listing the accepted identifier forms, but asOf is left entirely unexplained — an agent cannot tell whether it is a point-in-time cutoff for ticker history or just metadata.

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 (resolve) plus the accepted identifier types (ticker, legal name, CIK) and the return shape (one company or candidates). It is clearly distinct from read_listed_company, though it never names that sibling to cement the differentiation.

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?

Use is implied — resolving a free-form identifier into a company — and the 'one chosen company or the candidates' clause hints at disambiguation. However, there is no explicit when-to-use-vs-read_listed_company guidance, no prerequisites, and no explanation of what to do when multiple candidates come back.

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

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

Adds real context beyond annotations: it discloses the walk_pending intermediate return and that it does not finalize an approval. Annotations say readOnlyHint=false, so the agent knows it writes, but the description never says what artifact the score produces or whether it can be re-run safely.

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 short declarative sentences, each carrying a distinct constraint, with the core action front-loaded. Nothing is repeated or padded.

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

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

Covers the action, the input precondition, and one return state, but with no output schema it should say more about what a score result contains, and it leaves the 'event' parameter entirely unexplained.

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

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

Schema coverage is only 50%, and the undocumented parameter is 'event', which the description never mentions at all – no hint whether it is a trigger label or an event name. Only caseId is indirectly covered by 'facts already on the open case'.

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: score case facts against the active underwriting pack/rubric. Explicitly bounds the tool with two negatives – it does not accept new facts and does not approve a loan – which separates it from mutating siblings like open_case or start_underwriting_package.

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?

Preconditions are implied clearly: the case must be open and a pack active, and facts must already exist on the case. It doesn't name an alternative tool for submitting new facts (e.g. the walk/chase tools), leaving the redirect 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, openWorldHint=true and destructiveHint=false, so the external-call and write profile is partly covered. The description adds a failure-mode note ('a missing key writes nothing and does not pass the file'), which is useful but phrased too ambiguously to be actionable.

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?

Very short and front-loaded, but two of the four sentences ('Same as Screen OpenSanctions', the missing-key clause) are redundant or unclear rather than informative.

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 and readOnlyHint=false imply the tool persists a screening result to the case, yet the description never says what is recorded or returned. Combined with partial parameter documentation, an agent cannot fully anticipate the effect of a call.

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

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

With only 33% schema coverage, the description should compensate more; it names the screening subject (name) and the SANCTIONS/PEP check type, but says nothing about caseId semantics, whether name is optional or where it is sourced, or default checkType behavior.

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?

Specific verb+resource: screens a name against OpenSanctions for SANCTIONS or PEP checks. The phrase 'Same as Screen OpenSanctions' is redundant filler rather than sibling differentiation, but the core action is unambiguous.

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

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

No guidance on when to screen versus when to use related siblings like resolve_listed_company or read_listed_company, and no prerequisites (e.g., API key requirement, case state) are stated beyond a cryptic hint.

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

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

Beyond the annotations, the description discloses important behavior: it returns three specific URL outputs, background checks may start automatically, a secured loan requires a complete guarantee, and the tool does not itself approve the loan. This gives the agent essential side-effect and approval-boundary context that annotations alone do not provide, with no contradiction.

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

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

The description is front-loaded with the core action and outputs, then moves to requirements, side effects, and approval boundaries. Every sentence carries useful information with no filler.

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

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

For a mutation tool with an open-world hint, nine parameters, low schema coverage, and no output schema, the description does well: it explains return values, automatic background checks, required fields, conditional guarantee requirements, and the human-review boundary. It still omits auth/permission expectations and more parameter semantics, so it is not 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 description coverage is only 22%, so the description must compensate. It adds useful conditional meaning ('a secured loan also needs a complete guarantee') and lists required fields, but it leaves many parameters (pricing, purpose, tenorMonths, amortisation, guarantee types/who/asset/limited/program) unexplained, so compensation is partial.

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 opens with a specific verb and resource: 'Create a new underwriting package for a borrower.' It also states the concrete outputs (deskUrl, dashboardUrl, exportUrl), which makes the tool's effect unmistakable and clearly distinguishes it from read-oriented siblings like read_package or open_case.

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 provides clear preconditions ('Requires borrower, amount, currency, and security; a secured loan also needs a complete guarantee') and boundary conditions ('Does not approve the loan. Human review remains required'). It does not explicitly name alternative tools or when not to use this one, 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 establish it is a non-read-only, non-destructive operation; the description adds meaningful behavior: it indexes/extracts/spreads, supports image PDFs, is idempotent in returning an existing running job, and does not perform memo drafting or approval. It could say more about side effects on the case or job lifecycle, but the description carries substantial behavioral 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?

Two compact sentences, front-loaded with the core operation and followed by job semantics and exclusions. No wasted 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 job-starting tool with no output schema, the description explains the multi-step process, idempotent job behavior, and exclusions. It leaves some ambiguity about what is returned or how job status/progress is observed, which keeps 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 description coverage is 100% and there is only one required parameter (caseId), so the schema already documents it. The description adds no additional parameter-level semantics; 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 specific actions (index, extract, spread financials) on a specific resource (the open case's credit file/package). It also explicitly separates itself from sibling jobs like drafting the memo and approving a loan.

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 context: use on an open case to process a package, and it either starts or returns an already-running walk job. It names two exclusions (no memo drafting, no approval), but doesn't explicitly contrast with siblings like start_underwriting_package or read_package.

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