ProfitDrawer

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

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered; the description adds real value by disclosing the exact amortization method and warning that results are a close estimate that lenders may differ on. It does not address edge cases such as a payment too small to ever amortize the balance or a zero balance, which is the main remaining 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?

Purpose is front-loaded in the first clause, followed by a compact method parenthetical and two short caveat sentences. The parenthetical is slightly dense but earns its place by making the calculation reproducible; nothing is redundant with the 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 a full output schema, rich annotations, and 100% schema coverage, the description need only explain method and precision, which it does. The only missing piece is behavior for degenerate inputs (payment <= monthly interest), which would matter for a purely computational 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 100%, so balance, apr_percent, monthly_payment and extra_payment are already documented with units and examples. The description reinforces what extra_payment does for the outcome but adds no format, range, or interaction 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: it computes months-to-payoff and total interest for a loan, plus the savings from an extra payment. The mechanics (APR/12 interest added, payment subtracted) and the sibling calculators' distinct domains make it unambiguous which tool to pick.

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: this is for amortizing a loan with a fixed monthly payment, optionally with an extra payment, and it names the reference implementation at profitdrawer.com so the agent knows the intended scenario. It does not state exclusions or when a sibling calculator would be preferable, but the other siblings cover different domains (jobs, tax, startup costs).

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 real behavioral detail beyond them: the 95% margin cap that silently clamps inputs, and the secondary outputs (profit per job, monthly revenue, break-even jobs). It does not mention error behavior or what happens with zero hours.

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

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

Three short sentences, front-loaded with the core formula, then outputs, then the clamping caveat. The formula chain is dense but each element earns its place; the external URL reference is marginal but provides verifiability.

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 deterministic pure-calculation tool with an output schema, annotations, and fully documented parameters, nothing needed to call it correctly is missing. The clamping rule and the extra return metrics are the only things structured fields could not convey, and both are covered.

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 is already documented; the description's formula does clarify the relationship between monthly_overhead and jobs_per_month, but that relationship is also stated in the schema. Baseline 3 is appropriate since the schema carries the semantics.

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

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

States a specific verb and resource ('works out a price for one service job') and spells out the exact formulas used, so there is no ambiguity about what is computed. It is clearly distinct from the sibling calculators (loan payoff, tax set-aside, startup costs).

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

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

Usage is implied by the name and the formula rather than stated: there is no explicit guidance on when to prefer this over calculate_loan_payoff or estimate_startup_costs, nor any note on prerequisites. The reference to the public calculator URL gives context but not selection criteria.

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 read-only, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description still adds real value by disclosing the two exact formulas (including the 92.35% x 15.3% self-employment tax breakdown), the supported period granularities, and the important caveat that results are an estimate, not tax advice.

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 verb and the core formula, then supporting detail, then the disclaimer in the final clause. Fairly dense but every clause carries information; only the URL reference is arguably non-essential.

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 tool is a simple three-parameter pure calculation and an output schema exists, so return-value explanation is unnecessary. The description supplies both formulas, period scope, and the estimate disclaimer, leaving little an agent would need to look up. A minor gap is the absence of an example or note on how rounding/currency is reported.

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 three parameters are already documented including the period enum and percent units. The description reinforces that percent is applied to per-period profit and that results are expressed per month/quarter/year, but adds no format or unit 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 ('Estimates how much of a self-employed profit to set aside for taxes') and immediately gives the exact arithmetic, so the agent knows precisely what is computed rather than just the topic. Clearly distinguishable from the arithmetic-style siblings like calculate_loan_payoff or calculate_price_per_job.

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: the agent must infer that this applies to self-employed profit estimated for a month, quarter or year. There is no explicit when-to-use/when-not or named alternative among the calculation siblings. The 'not tax advice' caveat frames the output's authority but is not a usage rule.

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 the exact formula, the rounding behavior, the key assumption of no sales, and the replacement semantics between presets and supplied cost lists. These are meaningful behavioral details for interpreting the calculation correctly.

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 calculation and rounding rule, then covers the preset behavior. It is appropriately sized, though the website-reference sentence and preset enumeration add some density.

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 rich annotations, full schema descriptions, an output schema, and a clear formula explanation, the description gives an agent everything needed to call the tool and interpret its calculation assumptions.

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 useful inter-parameter semantics: cost lists replace preset lines, and presets are rough examples, not quotes. It could say more about starting_cash or the distinction between cost arrays, but the schema already covers those.

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 calculation: summing one-time and monthly startup costs, computing cash left and runway, with rounding details. It clearly separates this startup-cost calculation from sibling tools like loan payoff or tax set-aside calculators by domain and output.

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 explains how presets interact with passed cost lists and that preset amounts are examples, which guides parameter use. However, it does not explicitly state when to use this tool versus the sibling calculators or when not to use 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 already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description's remaining behavioral content is a list of returned fields, which largely duplicates the output schema, and it says nothing about what happens with a missing or invalid 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 verb and resource before the field enumeration. The long comma-separated field list is dense and partially redundant with the output schema, but nothing is padded or off-topic.

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 lookup with full annotation coverage and an output schema, the description supplies everything needed to select and invoke it correctly. The only gap is error/not-found behavior, which is minor given the structured fields already present.

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 id parameter is already documented in the schema as 'as returned by search_profitdrawer'. The description repeats the same provenance hint ('Ids come from search_profitdrawer') without adding format or constraint 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 one answer published by ProfitDrawer by id') and enumerates the payload contents, making clear this is a single-record fetch rather than a search. The contrast with the sibling search_profitdrawer is implicit but unmistakable from 'one answer ... by id' and 'Ids come from search_profitdrawer'.

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 establishes the usage context clearly: use this after search_profitdrawer to resolve a specific id into a full answer. It does not state any when-not conditions or error behavior for unknown ids, but for a simple lookup tool the sequencing guidance is sufficient.

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 closed-world, so the safety bar is low. The description adds genuinely new behavioral context: every fact carries a source and the About page URL is included, telling the agent the data is attributed and static rather than user-generated.

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: the core claim comes first, then the field inventory. No preamble, no restatement of the title, and every clause tells the agent something it can use.

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 an output schema present, return-value detail is not required, and with zero parameters there is nothing else to specify. Fields, provenance and the About URL are all covered; nothing an agent needs in order to call this correctly is missing.

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

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

Zero parameters, so per the baseline this scores 4. The description correctly implies a call with no arguments and spends no words on nonexistent parameters.

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 ('Returns') plus resource ('public facts about ProfitDrawer') with an enumerated field list including description, website, founding year, currency and social profiles. The resource is clearly distinct from the sibling calculators and list/query tools, though the description never explicitly distinguishes it from search_profitdrawer, the closest neighbor.

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: the field list hints at answering 'who/what is ProfitDrawer' questions. There is no explicit when-to-use statement, no exclusion of search_profitdrawer or get_answer for the same questions, and no mention that no arguments are required.

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 that returned entries carry description, answer count, and category page URL, but that overlaps with the existing output schema and adds no new behavioral context such as pagination or result cap.

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 resource first and the exposed fields after. No filler, no restatement of the title beyond the verb-resource phrase.

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 listing tool with an output schema, annotations, and a closed-world hint, the description is sufficient to call it correctly. Nothing an agent needs is missing.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No misleading parameter hints are introduced.

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 (categories of ProfitDrawer's published answers), plus the fields exposed. It is clear what the tool does, but it never contrasts itself with siblings like list_products or search_profitdrawer, which also offer discovery paths.

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 use case (browsing published answer categories) is implied by 'published answers', but there is no explicit when-to-use, when-not-to-use, or routing to get_answer/search_profitdrawer for actually retrieving answers. An agent must infer the workflow position.

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 without description text. The description adds genuine context beyond that: the product domain (spreadsheets through printed goods), that prices are in USD, and that both a product page URL and an Etsy listing URL are returned. It omits pagination/limit behavior and how filters combine, which keeps it from a 5.

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

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

Two sentences with the purpose and returned fields front-loaded, then filters. The parenthetical product list ('spreadsheets, printables, templates, planners and printed goods') partially duplicates the collection enum's own descriptions, which is mild waste but not damaging.

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 an output schema present, the description needn't enumerate return values, and all parameters are schema-documented. For a zero-required-parameter, read-only catalog listing, everything an agent needs to decide and invoke is present.

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 five parameters including enum values, lengths and defaults are already documented in the schema. The description restates four of the five filters at a looser granularity and omits `limit` entirely, adding no semantics 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 ('Lists') and resource ('ProfitDrawer products'), and enumerates the product domain plus the fields returned (name, USD price, formats, availability, URLs). It does not distinguish itself from the sibling search_profitdrawer, which an agent could plausibly pick instead, 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 description implies browsing/filtering by naming 'Optional filters: words to match, collection, maximum price and file format', which hints at when the tool applies. But it never says when to prefer it over search_profitdrawer or list_categories, and gives no exclusions or 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 closed-world, so the safety profile is fully covered. The description adds genuine context beyond that — rows carry an IRS source URL and a checked date, and the response includes the dataset page URL and license — but is silent on truncation behavior when limit is hit or on what happens with unknown filter keys.

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 the dataset enumeration, then response contents — a sensible order with no filler sentences. The inline parenthetical dataset list is somewhat dense but each element is load-bearing.

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 a full input schema and an output schema present, return-value detail is largely redundant, yet the description correctly orients the agent to provenance fields. The remaining gap is that filterable column names are knowable only by trying, which matters for a tool whose main optional capability is filtering.

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 slug, limit, and filters including the substring vs exact-match semantics and the example. The description only restates 'filter by column values' and adds no information about which column keys actually exist per dataset, which is the one thing the schema cannot tell the agent.

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?

Opens with a specific verb and resource ('Returns rows from the datasets published by ProfitDrawer') and enumerates exactly which datasets are covered. An agent knows precisely what it retrieves, though it doesn't distinguish this from adjacent retrieval siblings like get_answer or search_profitdrawer.

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?

States that filtering by column values is optional, which implies the retrieval-vs-filtered-retrieval usage pattern. It gives no explicit when-to-use guidance, no conditions that would favor search_profitdrawer or get_answer, 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 already declare readOnly, idempotent, closed-world and non-destructive behavior, so the safety profile is covered. The description adds the result cap (up to 10) and the per-result fields, which gives the agent a real sense of what comes back beyond the hint flags. It does not discuss ranking or empty-result behavior, keeping it out of 5 territory.

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 verb and resource, then the useful category enumeration, then the result shape and next step. Every sentence carries information, though the category list is dense and could have been compressed.

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?

An output schema exists, yet the description still summarizes the return shape, and it names the follow-up tool for full text. For a two-parameter search tool, an agent has everything needed to invoke it correctly and act on results.

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

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

Schema coverage is 100% and both parameters are documented in the schema, including the 1-10 limit bound and default. The description adds only marginal semantics (the category list suggests useful query terms), so the 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 (searches) and a precisely scoped resource (questions and answers published by ProfitDrawer), then enumerates the topical categories covered. It is clearly distinguished from the sibling get_answer, which retrieves full text by id.

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

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

Explicitly routes the agent: use get_answer with an id for the full text and source, which is the natural follow-up after a search hit. It lacks an explicit statement about when this is preferable to sibling retrieval tools like query_dataset or list_categories, so it falls short of a full 5.

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