Faxette EU

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

Discloses the non-obvious two-step protocol the annotations cannot convey: the tool returns document_id/upload_url/upload_headers, the PUT must happen within 5 minutes, and document_id must reach create_fax within an hour. It also states that nothing is faxed or charged, which is the key reassurance for an agent worried about side effects, and is consistent with destructiveHint=false and idempotentHint=false (calling once per file avoids duplicates).

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?

Every sentence is load-bearing: purpose, ordering, return contract, timing windows, and the fallback. The critical fallback is front-loaded-adjacent rather than buried, and there is 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?

Even though an output schema exists, the description supplies the temporal and sequencing contract that the schema cannot express. For a five-required-parameter upload-prep tool with a mandatory follow-up upload, 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?

Schema coverage is 100%, so the baseline is 3, but the description contributes constraints absent from the schema: concrete size ceiling (20 MB) and the accepted formats. It also explains what document_id is for downstream, tying output values to the next call. Minor omission: HEIF is in the enum but not listed in the prose format list.

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 ("add a file ... to a fax") and immediately scopes the artifact types accepted. It is clearly distinguishable from create_fax and send_fax, which are the natural siblings an agent might confuse it with.

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 ordering ("call it once per file, before create_fax, in the order the files should be faxed") and an explicit negative case: if the bytes can't be read, call create_fax without document_ids instead. Both the when and the when-not are named, plus the alternative path.

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

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

Beyond the annotations (readOnlyHint=false, idempotentHint=false), the description discloses the key behavioral facts an agent can't get from structured data: nothing is sent or charged until payment on the status page, and each call creates a separate fax. That directly explains the non-idempotent, non-destructive write profile in operational terms.

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 precondition is front-loaded and every sentence carries actionable content — preconditions, return value, billing semantics, document linkage, cardinaality, and status alternatives. It runs slightly long as a single paragraph, with the send-related caveat ('nothing is sent or charged until they pay') buried mid-sentence rather than surfaced.

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 create tool with a mutation profile, three params, and an output schema, the description covers preconditions, the returned status_url, cost/send timing, idempotency-like semantics, and follow-up tools. Nothing an agent needs to invoke it correctly or set expectations is missing.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds cross-tool meaning the schema lacks: document_ids must come from create_document and their order determines fax order. The email precondition (omit when signed in) and the requirement to confirm the fax number also reinforce the parameter story. It could have noted the 10-document cap, though the schema carries it.

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

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

The description states a concrete verb and resource: it creates the fax and returns status_url, the page where the person reviews and pays. That is far more specific than the title 'Start a fax'. The one gap is that it never clarifies its relationship to the sibling send_fax, so an agent must infer that creating is distinct from sending.

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

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

It gives explicit preconditions (the person confirmed the fax number and supplied an email if not signed in), says to pass document_ids from create_document, and notes that omitting them leaves the fax waiting for files. It also routes status checks to get_fax_status or get_fax. It stops short of naming send_fax as an alternative, which is the obvious ambiguity left open.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so 'It changes nothing' is largely redundant. The genuinely additive disclosure is that calling it while unauthenticated triggers a sign-in flow — a side effect an agent cannot infer from the annotations, and one that explains why a read-only call might produce a prompt.

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 purpose, then the prerequisite, then the safety note. Every sentence carries distinct information; no filler or restatement of the title.

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

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

An output schema exists, so return values needn't be spelled out, and the one non-obvious behavioral wrinkle (auth requirement and sign-in prompting) is covered explicitly. For a zero-parameter read tool this is complete enough to call correctly on the first try.

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

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

The tool takes zero parameters, so there is no parameter semantics to document; baseline 4 applies. The description correctly says nothing about inputs and instead spends its words on behavior.

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

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

States a specific verb and resource ('see which Faxette account the person signed in with') and enumerates the returned fields: name, email, credit, and US/EU copy. This is unambiguously distinct from the fax/document siblings (send_fax, get_faxes, create_document), which all operate on fax artifacts rather than the signed-in account.

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 triggering condition ('Use this to see which Faxette account...') plus a prerequisite: the person must be signed in to Faxette. No explicit exclusions or named alternatives, but the sibling set contains no competing account-inspection tool, so nothing is left ambiguous.

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, yet the description adds two non-obvious operational facts: a polling rate limit while a fax is sending, and the auth behavior that calling it while the user is signed out triggers a sign-in flow. 'It changes nothing' reinforces rather than contradicts the readOnly annotation.

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

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

Three tight sentences, front-loaded with the purpose, then id provenance, then the two operational constraints. No filler and nothing repeated.

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, so the enumeration of returned fields is a bonus rather than a requirement. Auth requirements, rate limiting, id source, and the no-side-effect guarantee cover everything needed to invoke a single-parameter read tool correctly.

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

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

Schema coverage is 100% and the parameter's own description already says the id comes from get_faxes or create_fax, so the description's id guidance is essentially duplicative. Baseline 3 applies since the schema carries the parameter 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+resource and scope ('one fax from the person's Faxette account') and enumerates what comes back: status, price, payment, document file names, history. The singular 'one fax' implicitly separates it from get_faxes, but it never explicitly distinguishes itself from get_fax_status, which a reader could plausibly confuse it with.

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

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

Gives clear usage context: call it for a single fax, pass the id obtained from get_faxes or create_fax, and throttle to once a minute while sending. It does not name get_fax_status as an alternative or say when that sibling is preferred, so the routing guidance is incomplete rather than absent.

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

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

Adds substantial context beyond annotations: pagination behavior ('Returns 25 at a time, newest first'), the page/next_page contract, authentication behavior ('Needs the person to sign in... asks the app to sign them in'), and safety ('It changes nothing'). This is richer than the readOnly/idempotent hints alone.

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 when to use, then pagination, filtering, alternative tool, auth, and safety. Every sentence is functional with no repetition or 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?

Given the output schema exists and annotations cover safety, the description supplies everything an agent needs: trigger conditions, pagination mechanics, filtering, auth behavior, and the sibling alternative. Nothing essential is missing.

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

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

Schema coverage is 100% so the baseline is 3, but the description adds practical usage: pass next_page back as page and filter with status using examples like ["failed"] or ["delivered"]. It does not explain the full enum state list, but the schema handles that.

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 ('faxes they've sent from their Faxette account') and scopes it to a person's own sent faxes. It explicitly differentiates from the sibling 'get_fax' by naming it as the tool for a single fax's details.

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

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

Gives concrete trigger examples ('what they sent last week or which faxes failed') and a clear alternative ('Use get_fax for one fax's details'). Also indicates filtering usage with the status parameter.

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 beyond the readOnly/idempotent annotations with a real operational constraint ('while a fax is sending, call it at most once a minute') and explains the meaning of checkout_available. 'It changes nothing' merely restates readOnlyHint, so it adds no new information and keeps this 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?

Four short sentences, front-loaded with the trigger condition, followed by behavior and then the rate limit. Nothing is padded and every clause carries usable 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?

With annotations covering safety and an output schema covering return shape, the description supplies the remaining pieces an agent needs: when to call it, the rate limit during sending, and what checkout_available means.

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 status_url and its format are already fully documented in the schema. The description reinforces that it is the create_fax return value but adds no new syntax or format detail, matching the baseline for fully covered schemas.

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 ('reads the fax from its status_url and returns its status, page count, price, payment and attempts') and lists exactly what comes back. This clearly separates it from siblings like get_fax and get_faxes, which operate on fax content or lists rather than a single status_url.

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

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

Gives concrete triggers: when the person asks how their fax is doing or whether it is ready to pay. It does not name an alternative tool or state when not to use this one, which keeps it short of a 5, 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 flag destructiveHint/openWorldHint, and the description adds the critical facts beyond them: this spends real credit, consent must be explicit, and invoking while unauthenticated triggers a sign-in flow rather than failing. That is exactly the behavioral context annotations cannot convey.

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

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

Purpose and funding source are front-loaded, followed by prerequisites and the fallback path in logical order with no filler. It is slightly dense with multi-clause sentences where a two-line structure would read faster, but every sentence carries information.

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

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

For a monetary, non-idempotent mutation with an output schema, the description covers consent requirements, prerequisite reads, authentication needs, and the insufficient-credit fallback. Nothing an agent needs before calling is missing.

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

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

Schema coverage is 100% and both parameters are documented in detail, including the price_changed refusal path for amount_cents. The description reinforces the workflow (confirm price via get_fax before calling) but adds no syntax or value semantics the schema lacks, 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 ('send a fax') plus the funding source ('from the person's Faxette credit'), which is the exact distinction from siblings like create_fax. An agent can tell this apart from fax creation 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?

Explicit preconditions and sequencing: call get_fax first, confirm credit_price, obtain clear agreement, call only once. It also names the alternative path (status page) when get_account shows insufficient credit, and routes to get_account for the check.

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