Penny Engine — Agent Operations

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

Annotations already declare readOnlyHint, openWorldHint=false, and destructiveHint=false, so safety is covered. The description adds 'deterministic' and 'no signup' context, which is useful, but says nothing about output shape or bounds on inputs.

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 short, front-loaded fragment with no waste, though it is too terse to carry much meaning.

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

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

For a computational tool with zero schema descriptions and no output schema, the description leaves units, scaling, and return shape unspecified; an agent cannot confidently 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 0% and the description adds no meaning for the three required parameters (costPerClick, conversionRatePct, contributionPerOrderUsd) – an agent must infer units and how conversionRatePct is scaled.

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 the resource and outcome (customer acquisition cost and break-even click price), giving an agent a specific sense of what is computed. It is distinguishable from siblings like penny_margin or penny_marketplace_profit, though it doesn't name the formula or units.

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?

'Free, no signup, deterministic' hints at usage context, but there is no explicit when-to-use vs alternatives guidance among the sibling pricing/profit tools. Usage is only implied.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false; the description reinforces this with concrete behavior ('does not execute, purchase, research live web content') and adds that unsupported requests are labeled explicitly, plus a cost/auth note ('Free, no signup'). It stops short of describing the shape of the returned routing 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 short sentences, each carrying a distinct constraint (scope, exclusions, cost/behavior), with the positive purpose front-loaded. No filler.

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

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

With no output schema, the description should carry return-value meaning; it partially does by stating that unsupported requests are labeled explicitly, implying the response distinguishes supported from unsupported. An agent still does not know the format of a successful routing answer, but nothing critical to invoking it is missing.

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

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

Schema coverage is 0% for the single 'task' parameter, and the description adds no guidance on what the string should contain (goal phrasing, expected length, how to phrase an unsupported request). With only one free-text input, the gap is minor but real.

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) and resource (agent task to existing Penny Engine capabilities), and immediately bounds the scope with 'capabilities only'. This clearly distinguishes it from the sibling tools, which are concrete single-purpose calculators/extractors rather than a router.

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

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

Gives explicit exclusions ('does not execute, purchase, research live web content, or claim to handle arbitrary tasks') which tell an agent when this tool is the wrong choice. It does not name a specific alternative tool for unsupported cases, so it falls short of the top band.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered; the description still adds useful context ('No external network calls. Free, no signup') that confirms offline, no-auth operation. It stops short of describing the report/output shape or how duplicates are reported, but the annotation baseline lowers the burden.

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 scope, followed by a compact list of what is checked and a one-line trust note. Every sentence earns some place, though 'Free, no signup' leans promotional rather than operational.

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 batch-audit tool with no output schema, the description says what it checks but not what a caller receives (findings list, per-record status, summary), and one of the two parameters is unexplained. Adequate but with clear gaps given the missing structured return documentation.

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%, so the description must carry the parameter meaning. It does explain the 50-item cap and ties the audit to fields like SKU, URLs, and cost/price/fee inputs via 'estimated net contribution per order', but the key knob targetMarginPct and per-field semantics (feePct, shippingCost) are left entirely to inference.

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 (batch-audit), the resource (up to 50 product records), and the exact checks performed (duplicate SKUs, missing attributes, malformed URLs, net contribution per order). An agent can distinguish this bulk-audit tool from point-estimate siblings like penny_margin or penny_target_price without opening any schema.

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

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

It gives usage contexts ('scheduled ecommerce catalog ingestion and agent product publishing'), which implies when the tool fits, but never states when NOT to use it or names an alternative sibling for single-record or margin-only work. The routing signal is suggestive rather than decisive.

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 the safety profile is partly covered. The description reinforces and extends this by stating it does not sign, pay, or execute a paid call, and that CSV preflight is FREE while the quote is fixed at $0.001. That is useful cost/side-effect context 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?

One dense but front-loaded sentence packing the return payload, the free-preflight note, and the no-execution caveat into essential clauses. Slightly cramped and comma-heavy, but no filler sentences and nothing is buried at the end.

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 does the work of enumerating the return payload (route, exact quote, required input, sample, checkout instructions), and it discloses cost and non-execution. For a read-only selection tool with a nested optional input object, an agent has enough to call it correctly, though the maxPriceUsd semantics remain 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 description coverage is only 33%, so the description should carry weight. It mentions 'required input,' a 'sample,' and an optional FREE CSV preflight, which loosely maps to the task/input params, but it does not clarify maxPriceUsd's filtering role or the task string's 3-180 char constraint. Partial compensation only.

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

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

The description names a specific verb and resource: it returns the single best Penny Engine payable route plus a $0.001 quote, required input, sample, and checkout instructions. That is concrete enough to distinguish it from pure utilities like penny_slugify or penny_csv_to_json. However, it never differentiates itself from penny_capability_router, which sounds like an overlapping routing tool, so sibling disambiguation is incomplete.

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 implies usage ('Given an agent's real task') and clarifies the negative case ('does not sign, pay or execute a paid call'), which is helpful context. But there is no explicit when-to-use vs. when-not, and no named alternative among the 15 siblings despite penny_capability_router and penny_campaign_economics plausibly overlapping.

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, and openWorldHint=false, so the safety profile is covered. The description adds genuinely new context beyond the structured fields — 'no signup' implies no auth is required and 'deterministic' implies stable repeatable output for identical inputs. It does not explain units, defaults, or what the returned quote 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?

Two short sentences, front-loaded with the core purpose and with no filler. It is slightly cryptic ('by labor and target margin') where a few more words would have removed ambiguity without bloat.

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

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

For a 6-parameter calculator with zero schema descriptions and no output schema, the description is too thin: no units, no defaults for the four optional params, and no indication of what the quote result looks like. An agent can guess the domain but not how 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 0% across 6 parameters, so the description carries the full burden and largely fails it. It alludes conceptually to 'labor' and 'target margin,' loosely hinting at hours/hourlyWage/laborBurdenPct/targetMarginPct, but gives no meaning or format for overheadUsd, suppliesUsd, or how percentage parameters are expressed (0-100 vs 0-1).

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: it produces a commercial cleaning quote derived from labor inputs and a target margin. That distinguishes it reasonably well from generic siblings like penny_margin and penny_target_price. It stops short of naming an alternative, so it is clear but not sibling-differentiating at the top level.

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

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

The description gives no when-to-use or when-not-to-use guidance, nor does it point at an alternative tool. 'Free, no signup, deterministic' is a trust/access statement rather than usage direction, leaving selection to inference 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?

The annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, covering the safety profile. The description adds useful operational context: it is free, requires no signup, produces deterministic output, and returns a 'bounded' array, all of which go 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?

The description is two compact sentences with the core function front-loaded and no filler. The second sentence, while brief, adds differentiating context.

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 conversion tool with annotated safety and no output schema, the description covers the basic output shape ('bounded array of JSON records') but leaves key details unspecified: how many records constitute the bound, what happens with malformed CSV, or input size limits. An agent could invoke it but may be surprised by truncation or errors.

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 sole parameter 'csv' has 0% schema description coverage. The description only repeats 'CSV text', which adds little beyond the parameter name, and gives no details on format, size limits, or encoding. It does not 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?

The description uses a specific verb 'Transform' and names both the input (CSV text) and output (bounded array of JSON records), making the tool's function unmistakable. It is clearly distinguishable from all siblings, none of which perform CSV-to-JSON conversion.

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

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

The description offers no guidance on when to use this tool versus alternatives, and no preconditions or exclusions. The tagline 'Free, no signup, deterministic' describes properties, not usage context.

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 the safety profile is covered. The description adds genuinely useful context beyond that: that checkout is priced at $0.001 in Base USDC and that the tool never charges, signs, or executes the paid call, which an agent needs to understand the economic/authorization model.

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

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

Two tight sentences that front-load the free/preflight nature before the payment detail. No padding, though terms like 'work order' and 'Base USDC checkout instructions' are terse enough to be slightly cryptic.

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 tool taking a nested object with required job entries and an array cap of 20, plus a margin parameter and a price ceiling, the description gives no guidance on input construction. With no output schema, an agent also cannot learn what the preflight returns or how to consume the checkout instructions.

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% and the input schema is non-trivial, with nested jobs (id/result/expectations), a csv string with 15-9500 char bounds, targetMarginPct, and maxPriceUsd. The description only obliquely maps 'catalog audit' and 'agent-output-batch-qa' to the goal enum and explains none of the other parameters or the nested structure, 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/role (FREE preflight) and names the two work orders it serves (catalog audit, agent-output-batch-qa), and clarifies it produces checkout instructions rather than executing. It is distinguishable from penny_catalog_audit, which appears to be the paid execution this preflights, though the sibling relationship is only implied.

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 word 'preflight' and the two goal values imply this is run before committing to the paid call, and 'Never charges' hints it is a safe dry run. However, it names no alternative tool and gives no explicit when-to-use/when-not condition, leaving the routing 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, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuinely new behavioral facts: no script execution, no network access, and deterministic output. It stops short of stating failure behavior on malformed or empty HTML.

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 single sentence naming the operation and its outputs, with the constraint clause trailing. 'Free, no signup, deterministic' is partly promotional filler, though 'deterministic' has real behavioral value.

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 enumerates the returned fields, which is the most important thing an agent needs. It is adequate for a stateless one-input transform, with minor gaps around error handling and HTML size/encoding limits.

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% and the single 'html' property is undocumented, so the description carries the load. 'Supplied HTML' usefully disambiguates the parameter as raw markup rather than a URL, which is the main ambiguity for a one-param extractor.

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 ('Extract') plus an enumerated resource set (page title, meta tags, headings, JSON-LD) scoped to supplied HTML. This cleanly separates it from any sibling that fetches or cleans URLs, and an agent knows exactly what comes out.

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?

'From supplied HTML without browsing or executing scripts' effectively states the precondition: you must already hold the markup, and this is not a fetcher. No sibling alternative is named and there are no explicit exclusion cases, but the usage context is unambiguous.

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=true, destructive=false and closed-world, so the safety profile is given. The description adds the non-retention guarantee ('without retaining it') and determinism, which are behavioral traits beyond annotations, but says nothing about size limits for 'bounded' input, output format, or error behavior.

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

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

Two short sentences with no filler, and the core action is front-loaded. 'Free, no signup, deterministic' is slightly marketing-flavored but compact.

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 one simple parameter and no output schema, the description is nearly sufficient, but the undefined 'bounded' limit and the unspecified inspection result leave an agent without enough to call it confidently or know what it will get back.

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% and the single parameter 'text' is undocumented. The description mentions 'bounded JSON input' but gives no format, size limit, or constraint details to compensate for the missing schema 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 (parse and inspect) and resource (bounded JSON input), and distinguishes itself from the JSON-conversion sibling penny_csv_to_json. It does not explain what 'inspect' yields, but the tool's role is discernible.

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 tool versus alternatives such as penny_csv_to_json or penny_html_extract, and no prerequisites or exclusions. Usage is only implied by the word 'JSON'.

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=false, so the safety profile is covered. The description adds one genuine behavioral trait beyond that: 'deterministic' plus 'free, no signup', signalling no auth and repeatable pure computation. It does not describe output shape or edge-case handling (e.g. zero variableCost).

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

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

Two short sentences, front-loaded with the capability before the operational metadata. Efficient, though 'Free, no signup' is marginally redundant with the read-only, closed-world profile already implied by 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 and no annotation detail on return values, the description's list of computed quantities is the only signal of what comes back, and it gives no format or rounding detail. For a pure-calculation tool with 3 undocumented parameters this is adequate but leaves real 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 description coverage is 0% for all three parameters, so the description carries the full burden and fails it. 'Break-even units' hints that fixedCost participates, but neither price, variableCost, nor fixedCost is explained, and no units/currency convention is stated (e.g. per-unit vs total fixed cost).

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 the three concrete outputs (unit margin, markup, break-even units), which is specific enough to separate this unit-economics calculator from siblings like penny_target_price or penny_marketplace_profit. It is output-oriented rather than verb-oriented, but the agent can tell what it computes.

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

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

No when-to-use guidance and no alternatives are named. Nothing tells the agent when this tool should be chosen over penny_target_price, penny_marketplace_profit, or penny_campaign_economics, all of which compute related economics figures.

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, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description usefully adds that the computation is deterministic and requires no signup/auth, but says nothing about units, currency, rounding, or what the result represents.

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

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

Two short, front-loaded sentences with no filler; the core definition comes first and the operational note second. It is tight, though the second sentence serves marketing more than invocation.

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 7-parameter calculator with no output schema and 0% parameter documentation, the description is thin. It should at minimum explain the return value (net contribution figure) and the interpretation of percentage/currency inputs; neither 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 0% across 7 parameters, so the description must carry the burden and it does not. It gestures at cost categories (goods, fees, ads, shipping) but never clarifies that platformFeePct is a percentage, what units shippingCharged uses, or whether adCost is per-unit or total.

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 the resource precisely ('ecommerce net contribution after goods, fees, ads and shipping'), which tells an agent exactly what is computed. However, it never distinguishes itself from the sibling penny_margin or penny_target_price, which an agent could easily mistake for the same calculation.

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 statement of when to use this tool versus penny_margin, penny_campaign_economics, or penny_target_price, and no prerequisites or exclusions. The 'Free, no signup' note is a convenience claim, not usage guidance.

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

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

Annotations already declare readOnly, non-destructive, closed-world. Description adds 'free, no signup, deterministic' which is useful context especially deterministic behavior. However, no detail on how unsupported characters are handled, length limits, or idempotency beyond 'deterministic'.

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 concise sentences with zero waste; purpose front-loaded, then notable traits. Well-sized for a simple utility.

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?

Complete enough for a single-parameter, annotation-rich utility with no output schema. Missing edge-case handling details (invalid characters, non-ASCII) that would make it 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?

0% schema coverage and the single 'text' parameter is un-described in both schema and description. Description explains the general input ('short string') and output (lowercase ASCII URL slug), which is meaningful, but doesn't clarify the 'text' parameter's constraints. Baseline for 1 param is high, but the coverage gap holds it to a 3.

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

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

States a specific verb (turn into slug), resource (short string to lowercase ASCII URL slug), and transformation outcome. Distinguishable from sibling penny_url_clean and penny_csv_to_json by the slug conversion focus.

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 usage via 'Turn a short string into...' and 'slug', but offers no explicit when-to-use or exclusions vs siblings like penny_url_clean. Free/no signup/deterministic hints at 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 declare readOnlyHint, non-destructive, and closed-world. The description usefully adds that no signup/auth is required and that results are deterministic, which is genuine behavioral context an agent cannot get from the annotations alone. It still omits the formula assumptions and output shape.

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 fragments with the purpose front-loaded and no wasted prose. 'Simple' is filler, and the terseness arguably costs clarity, but there is nothing to trim.

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

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

For a four-parameter financial calculator with no output schema and no parameter documentation, the description should explain input units/formats and at least sketch the return value. It provides neither the formula framing nor any output indication, leaving the agent to guess at percent-vs-decimal conventions.

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% across four parameters, two of them required, so the description carries the full burden and largely fails. Only 'monthly churn' loosely hints at the meaning/periodicity of monthlyChurnPct; it says nothing about units (percent vs fraction), what grossMarginPct or acquisitionCostUsd do, or which inputs are optional.

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 computation: lifetime value estimated from monthly churn, which is more than a restatement of the tool name. It does not, however, differentiate this calculator from financial siblings such as penny_margin, penny_target_price, or penny_marketplace_profit, and it never states the inputs it consumes.

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 or when-not-to-use guidance and no alternative tool is named. 'Free, no signup, deterministic' is a property statement, not usage routing, and the agent is left to infer this is a modeling calculator rather than a data-fetching 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 readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so safety is covered. The description adds genuine non-schema context: no signup/auth required and deterministic output, which tells the agent results are reproducible and credential-free.

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, purpose front-loaded, zero filler. Every clause carries information (what it solves, cost model, operational traits).

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

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

No output schema exists, so the description should indicate what comes back (e.g. a single price value) and in what units, but it does not. Combined with 0% schema coverage on four parameters, an agent lacks the detail needed to invoke this confidently.

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 4 parameters, so the description carries the full burden. It gestures at the concepts (cost, fees, target margin) but never maps them to parameter names, never says 'cost' is the sole required input, and never states units (fraction vs percent) or defaults for feePct/feeFixed/targetMarginPct.

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: 'Find minimum price for target gross margin after fees', which tells the agent it is a pricing/margin solve rather than a plain margin calculation. It does not explicitly name or contrast with close siblings such as penny_margin or penny_marketplace_profit, so an agent must infer the boundary.

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

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

No when-to-use, when-not-to-use, or alternative routing is given. With siblings like penny_margin and penny_marketplace_profit in the same family, the agent gets no signal about which to pick; usage is only implied by the wording.

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, non-destructive and open-world behavior, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: the data source (public RSS), freshness constraint (cached 10 minutes), and the absence of customer/sales data. It does not, however, describe the returned fields or classification output format.

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 compact sentences, front-loaded with what it does and followed by source/freshness/access caveats. No redundant restatement, though the density means each clause carries several facts.

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 return-value burden, and while it explains the nature of results (rising queries + intent classification) it stops short of describing the actual returned fields or structure. Data source, caching, and access terms are otherwise well covered for a simple read-only fetch 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 both parameters (limit, commercialOnly) are fully documented in the schema. The description's mention of 'purchase-intent classification' loosely relates to commercialOnly but adds no syntax or format detail beyond the schema. Baseline 3 is appropriate.

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

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

States a specific verb (Get) and resource (recent US Google Trends rising-search queries) plus the added value (heuristic purchase-intent classification). It also names the goal — identifying digital product research candidates — so an agent can tell it apart from the sibling economics/utility tools at a glance.

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 stated goal of finding product research candidates, but there is no explicit when-to-use, when-not-to-use, or named alternative among siblings. The agent must infer when this trend-fetching tool is appropriate versus other penny_ 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=true and destructiveHint=false, but the description adds genuinely new behavioral facts: no network fetch occurs, no signup/auth is required, and the operation is deterministic. That is meaningful context beyond the annotations, though it says nothing about return format or edge-case handling (malformed URLs, non-HTTP schemes).

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 stating the action, then three terse qualifiers. No padding, and the most decision-relevant constraint ('without fetching') comes early.

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

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

For a 2-parameter, no-output-schema utility with annotations present, the description covers the core action and safety-adjacent traits. It still leaves the removeAllQuery parameter's semantics and the return value (cleaned URL string? object?) unstated, which is a real gap for an agent deciding how to call it.

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

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

Schema description coverage is 0% for both parameters. The description implies a default of removing only 'common tracking parameters', which hints at what removeAllQuery toggles, but it never explains that boolean or the url parameter's accepted format. With zero schema documentation, the description does not compensate.

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: 'Remove common tracking parameters from HTTP links'. The qualifier 'without fetching' implicitly separates it from fetch/extract siblings like penny_html_extract. However, no sibling is named, so the differentiation is inferential rather than explicit.

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 'without fetching' implies the usage condition (when you have a link and want it normalized offline rather than retrieved). But there is no explicit when-to-use statement, no exclusion, and no named alternative among the many penny_* siblings, so the agent must infer the trigger.

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