Income Checker

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

Annotations only declare readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds real context beyond that: the tool merely mints a checkout link rather than charging, credits are non-expiring, and fulfilment is asynchronous ('added once payment completes'). It omits link lifetime and 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?

Three sentences, no filler: the action leads, the enumerable price data follows, and the handoff instruction closes. Nothing could be cut without losing required 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 one-parameter tool with no output schema, the description covers what the agent most needs: what comes back (a link) and when the purchase actually lands. Minor gaps remain around link expiry and error/refund 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 enum is self-documenting, so the baseline is 3. The description goes further by mapping each allowed quantity to its price ($5/$15/$25/$50/$125/$250), which the schema does not contain and which an agent needs to answer user questions.

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: 'Creates a secure Stripe checkout link for a pack of non-expiring verification credits.' This is unmistakably distinct from every sibling (income/rent math, reports, verification requests), so an agent can select it 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 workflow: create the link, hand it to the user, and credits land after payment completes. That tells the agent this tool does not itself complete a purchase. It stops short of naming alternatives or when-not-to-use conditions, 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 readOnly/idempotent/non-destructive/openWorld=false, so the safety profile is covered. The description adds genuine behavioral context beyond that: the output is flags for follow-up, and the tool is not an authentication or fraud-proof mechanism, which sets correct expectations about the result.

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 checks, how to supply data, and what it does not do. The enumerated checks come first and every clause carries information; nothing is redundant with the name or title.

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

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

With no output schema, the description carries the burden of describing results and does so at a high level ("flags items for follow-up"). Combined with the annotations covering the operation profile, an agent has enough to invoke it correctly, though the exact shape of the flags is left unspecified.

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

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

Schema coverage is only 45% across 11 parameters, so the description must compensate. It does so by tying the checks to the inputs (gross, deductions, net, hours × rate, period length, pay date, YTD totals), making the purpose of most parameters inferable even where the schema has no per-field 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 (checks) and resource (figures on a pay stub) and enumerates exactly what is validated: gross-minus-deductions vs net, hours × rate, SS/Medicare rates, period length, YTD totals, round numbers. This clearly separates it from sibling extraction/verification tools like monthly_income_from_pay and start_income_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?

"Read the numbers off the stub and pass them in" gives the operating context, and the closing sentence gives explicit exclusions (does not authenticate a document or prove fraud). It stops short of naming which sibling to use for verification/authentication instead, so alternatives are implied rather than 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, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds a useful behavioral hint — output includes 'common lender bands' — but says nothing about whether the result is a number, a band label, or a breakdown, which matters since no output schema exists.

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 terse fragment with no wasted words, but it is under-specified rather than crisp — there is no verb and no front-loaded statement of what the caller gets back. Efficient but too thin for a three-parameter calculator.

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 should describe the return, and it only hints at 'lender bands' without describing the ratios themselves or their interpretation. Adequate for a simple calculator, but gaps remain for an agent needing to act on the 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 67%, with monthly_gross_income left undocumented. The description's front-end/back-end framing implicitly maps monthly_housing to the front-end ratio and other_monthly_debts to the back-end, adding mild interpretive value, but it never explains the missing parameter or input units.

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

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

The description clearly names the resource — front-end (housing) and back-end debt-to-income ratios — and even scopes the calculation split. An agent can tell this is a DTI calculator, though it never names siblings like rent_to_income or rent_affordability to disambiguate the family of ratio 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?

No statement of when to use this versus the many sibling calculators (rent_to_income, rent_affordability, monthly_income_from_pay). The agent is left to infer that this is the tool to pick when both housing and other debts matter.

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 openWorldHint=false, so safety is covered. The description adds that the target is the authenticated user (auth context) and, with no output schema present, carries the burden of disclosing the returned fields (email, remaining credits) — useful behavioral detail beyond the 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 sentence that front-loads the subject (the signed-in user's account) and lists the two returned values. There is no filler or repetition of the tool name.

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

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

For a zero-parameter, read-only account lookup with no output schema, the description covers the essential return contents and the implicit auth requirement. It does not mention error or unauthenticated states, but nothing critical for calling the 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?

Zero parameters, so the schema contributes nothing to interpret and the baseline is 4. The description correctly implies the tool is argument-free by scoping it to 'the signed-in user' rather than accepting an identifier.

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 (Shows) and resource (the signed-in user's account) and enumerates exactly what is returned: email and remaining verification credits. No sibling tool in the set (calculators, verification actions, buy_credits) overlaps with this account-read capability, so an agent can route to it unambiguously.

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

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

Usage is implied rather than stated: 'signed-in user's' tells the agent this is a self-account lookup with no arguments, which makes the when-to-use fairly obvious. However, there is no explicit guidance on when to call it versus siblings like buy_credits (e.g. to check balance before purchasing) and no exclusions.

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

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

Annotations cover the safety profile (readOnlyHint=true, openWorldHint=false), so the bar is lower. The description still adds real behavioral value beyond them: the prerequisite of a completed verification and, importantly, the instruction to 'present figures as estimates, never as verified or approved income,' which shapes how an agent must handle and report the 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?

Two tight sentences with zero filler; the tool's output contents are front-loaded and the interpretational caveat follows immediately. Every sentence 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, the description usefully enumerates the returned fields, and it flags the estimation caveat. It falls short only on parameter semantics and on failure/prerequisite behavior, which are minor gaps for a single-param read tool.

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

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

Schema description coverage is 0% for the single required verification_id, so the description carries the burden of explaining it. It only obliquely hints at the parameter via 'a completed verification' and never states that the ID must reference a finished verification or what formats are valid, leaving the required parameter largely unexplained.

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 ('income analysis... for a completed verification') and enumerates the payload (estimated monthly income, income sources, other deposits, account balances). It is clearly distinguishable from siblings like monthly_income_from_pay or get_account, 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?

The phrase 'for a completed verification' implies a prerequisite (the verification must be finished), which is useful usage context. However, there is no explicit when-to-use/when-not, no guidance on what happens with an incomplete verification_id, and no routing to the many sibling income tools.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that the content is explanatory (a how-to, not an action) and enumerates what it covers, including 'their limits', but says nothing about the depth, format, or coverage boundaries of the 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?

Two sentences, front-loaded with the purpose and followed by the trigger condition. Every clause earns its place, with minor redundancy between 'check or verify' and 'verify, check, or prove'.

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

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

For a simple, read-only, one-optional-param advisory tool with no output schema, the description adequately conveys what the tool does and what topics it covers. The only omission is that it does not hint at the shape or length of the returned guidance.

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 optional enum parameter with 100% schema description coverage, so the schema fully documents it. The description never references the 'audience' parameter or how it tailors the answer, so it adds no 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?

States a specific verb and resource ('Explains how to check or verify a person's income') and lists the covered subject types and methods (bank-based income analysis, pay stubs, limits). It reads clearly as an informational tool, implicitly distinct from action siblings like start_income_verification or send_verification_request, though it never names an alternative.

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

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

Gives an explicit trigger: 'Use when someone asks how to verify, check, or prove income.' This is clear context for invocation, but it offers no exclusions or routing to related tools such as list_verifications or start_income_verification.

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 openWorldHint=false, so the safety profile is covered; the description adds genuinely new behavior beyond that by specifying sort order ('newest first') and result contents ('status and report links'). It does not disclose pagination behavior despite the limit cap of 50.

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 tightly written sentence with the operation, scope, ordering, and payload all front-loaded. No filler or redundancy.

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

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

For a simple two-parameter read tool with no output schema, the description covers what is returned and in what order, which is helpful. However, it omits any mention of the status filter or page-size limit that are its only two knobs, leaving an agent to discover them solely from the schema.

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

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

Schema description coverage is only 50% (the status enum has no per-value explanation and limit is a bare 'Default 10'), and the description adds nothing about either parameter. It never says results can be filtered by status or bounded by limit, so it fails to compensate for the coverage gap.

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

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

States a specific verb ('Lists'), a precise resource ('income verification requests'), and scope ('the signed-in user's'), which separates it from write siblings like send_verification_request and start_income_verification. It stops short of naming a specific sibling to avoid, so it lands just below the top band.

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 read-only framing and 'signed-in user's' scope imply the retrieval use case, but there is no explicit statement of when to call this versus checking a single request or starting a new one. No exclusions or prerequisites are 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 already establish readOnly, idempotent, non-destructive, closed-world semantics, so the safety profile is covered. The description usefully discloses that it emits a set of derived figures (gross monthly, annual, biweekly, weekly, hourly), but says nothing about rounding, assumptions, or the default-hours behavior beyond what the schema states.

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

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

One compact sentence with the input frequencies front-loaded before the output list; no filler. It could be marginally tighter but every clause earns its place.

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

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

For a stateless calculator with annotations carrying the safety profile and no output schema needed, the description covers what the tool accepts and returns. Only the absence of usage routing against sibling calculators leaves a small gap.

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

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

Schema description coverage is 67% and the schema already documents amount, frequency, and hours_per_week (with default 40). The description's spelling out of frequency labels ('every two weeks', 'twice a month') adds modest mapping value but no syntax or constraint detail beyond the schema.

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

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

States a specific verb ('Converts') and resource (pay amount) and enumerates both the accepted frequencies and the produced outputs, so the transformation is unambiguous. It doesn't distinguish itself from calculator siblings like rent_to_income or prorated_rent, but the core purpose is clear.

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

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

No indication of when to use this versus the other income tools (how_to_verify_income, start_income_verification, rent_to_income, etc.), nor any prerequisites or exclusions. Usage must be inferred entirely from the name.

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. The description adds the time-window semantics (move-in date through month end) but says nothing about rounding, currency, or whether the result is a bare number, which would be genuinely useful context for a calculator.

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 defines the quantity and its time boundary with no filler. Every clause earns its place.

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

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

For a small pure-calculation tool with complete safety annotations and no output schema, the definition covers the essential scope. Its only shortfall is not stating that the return is a numeric rent amount, which the phrase 'rent owed' largely implies.

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 67%; the most semantically complex parameter (method, with its three formulas) is already fully documented in the schema. The description only faintly reinforces move_in_date by describing the partial-month window and adds nothing about monthly_rent, so 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 computed quantity (rent owed) and its exact scope (move-in date through the end of that month), which neatly distinguishes it from ratio-style siblings like rent_to_income and rent_affordability. No sibling is named or explicitly contrasted, so it stops short of a 5.

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

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

The phrase 'partial first month' implicitly tells the agent when this applies, but there is no explicit guidance on when to use it versus alternatives such as rent_affordability, and no prerequisites or exclusions are given. Usage is inferable but not 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 readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuine behavioral context by disclosing which formulas are applied and that the comfortable range is capped at 36% total debt. It does not say what changes when monthly_debts is omitted, which is the main behavioral gap.

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

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

A single dense sentence with no filler, and the primary input/output relationship is front-loaded. The rule list is long but each item is substantive rather than 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?

For a two-parameter calculator with no output schema and annotations covering safety, the description supplies the key missing context (the rules that produce the answer). It stops short of explaining behavior when the optional debts parameter is absent or what the returned figures look like.

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%: monthly_debts is documented in the schema, monthly_gross_income is not. The description reinforces the income input and the '36% total debt' cap implies how monthly_debts is used, but it adds no format, units, or optionality details 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?

Names a specific computed output (affordable rent) from a specific input (gross monthly income), and enumerates the rules applied, which distinguishes it from the mere ratio tool rent_to_income. It does not explicitly say how it differs from sibling rent_to_income, 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, no statement of when to prefer this over rent_to_income or debt_to_income, and no prerequisites. Usage must be inferred from the name and the list of rules.

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, closed-world. Description adds the multiplier rules (2.5x/3x/3.5x) and the input-mode logic, which is useful behavioral context beyond annotations, but nothing about output format or rounding.

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 dense sentence front-loads the three computation modes, followed by a compact input-format instruction. No 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 2-param read-only calculator with no output schema, the description covers input semantics and expected computations well. It doesn't state output shape or default multiplier, 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?

Schema covers monthly_income (gross monthly) but monthly_rent has no description and no params are required. The description compensates by specifying monthly figures and mapping which parameter drives which output mode, going 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 specific computations: income needed from rent at 2.5x/3x/3.5x, max rent from income at 3x, and ratio when both given. Distinguishes scope through three input modes, clearly different from siblings like rent_affordability or debt_to_income.

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?

Implicit usage is clear: supply rent to get required income, income to get max rent, both to get ratio. Instructs 'Pass monthly figures'. No explicit when-not or alternative naming, but modes are self-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?

Goes well beyond the annotations: it discloses the credit cost, that an email is sent to a third party, and that the operation is asynchronous with the report only available after the applicant acts. These are the facts an agent needs to avoid burning credits or misreading an empty immediate response; the annotations only supply the generic non-read-only, non-idempotent profile.

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: capability, then precondition, then follow-up path. Cost and side effect are front-loaded before the procedural instruction, and nothing is repeated from the schema or annotations.

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 tells the agent not to expect the result synchronously and where to retrieve it. For a non-idempotent tool that spends a credit it could say more about duplicate-call risk and failure modes, but the core invocation picture is 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 50% – applicant_name and applicant_email carry no schema descriptions, and the description compensates by instructing the agent to confirm those two values with the user, implying they drive who receives the email. The two documented optional parameters (purpose, requested_by_name) need no further explanation.

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

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

States a concrete verb and resource chain: consumes one credit to create a bank-based income check, emails the applicant a Plaid link. The mechanism (Plaid bank connection) and channel (email) are specific enough to separate it from report-reading siblings like get_report.

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 ('confirm the applicant's name and email with the user before calling') and routes the agent to the follow-up tools (list_verifications, get_report) once the applicant connects. It does not, however, explain when to choose this over the similarly named sibling start_income_verification, which is the most likely confusion point.

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 non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the tool does not perform the check itself but hands back a link plus steps, and it clarifies the target subjects. It stops short of saying what the link leads to or whether credits 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?

Two tight sentences, front-loaded with what is returned and then the selection condition. 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?

For a parameterless tool with annotations covering safety and idempotency, the description covers purpose, routing and return shape adequately. Minor residual gaps remain about the link's destination and its relationship to credit-consuming siblings such as buy_credits.

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

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

The tool takes zero parameters, so the schema baseline is 4. The description's enumeration of who the report can be requested for (tenant, applicant, borrower, yourself) adds framing that the empty schema cannot 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 (returns the link and steps to request) and a specific resource (a bank-based income report from Income Checker), and enumerates the subjects it applies to (tenant, applicant, borrower, yourself). It also distinguishes itself from the look-alike sibling how_to_verify_income by explicitly scoping to actually verifying rather than learning how.

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 second sentence gives an explicit use condition and a contrast: use it when the user wants to actually verify/check income, not just learn how. That effectively routes the agent away from how_to_verify_income, though it doesn't name that tool or address other siblings like send_verification_request or list_verifications.

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