SuguFAX (すぐFAX)

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

Annotations only declare the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false); the description adds substantive traits beyond that: 30-minute expiry, one-time use, format and 10MB size limits, and the explicit statement that creating the link sends nothing and costs nothing. These are exactly the constraints an agent needs before invoking.

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 limits are front-loaded in the first sentence, and the workflow note follows. The clause about smartphone/PC upload and camera capture is marketing filler that does not help an agent decide or invoke, slightly diluting an otherwise tight definition.

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 still conveys the key return artifact (upload_url) and the follow-up handle (upload_id) needed for the next call. Combined with format/size/expiry constraints and the no-side-effect note, an agent has everything required to use this 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?

The tool takes zero input parameters, which is the baseline-4 case. The description does name the runtime artifacts (upload_url, upload_id) that flow through the tool, adding useful meaning about what the call ultimately produces.

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 (creates a secure one-time upload URL) and scopes it precisely (FAX documents, PDF/JPG/PNG, max 10MB). It also positions the tool in the workflow by naming send_fax and the upload_id handoff, so an agent can distinguish it from get_fax_price/get_fax_status/send_fax 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?

Clear sequencing guidance: create the link first, have the user upload to upload_url, then pass upload_id to send_fax. It also clarifies that this step is side-effect free (nothing sent, no charge). It does not explicitly state when NOT to use it or alternatives, which keeps it short of a 5.

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

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

Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false, so the safety profile is covered; the description adds that nothing is transmitted and, more usefully, that it performs destination eligibility validation and rejects mobile/0990/0570 numbers. It does not mention rate limits or whether pricing can change, 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?

Three short sentences, each earning its place: what is returned, the extra eligibility signal, and the no-side-effect guarantee. Front-loaded with the primary outcome and free of 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 does carry return-value burden and does so reasonably: price plus supportability, with currency and tax basis specified. Given the flat 3-parameter schema and strong annotation coverage, this is close to complete; only the return shape/format of a rejection is unspecified.

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

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

Schema description coverage is 100%, so the baseline is 3. The description restates the destination/page-count inputs and adds the currency/tax semantics (日本円・税込) and the unsupported-number rule, but says nothing about promo_code or the accepted number formats that the schema already covers.

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

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

Specific verb+resource: it returns the FAX price in JPY (tax included) derived from destination and page count, and additionally reports whether the destination is supported. That is clearly distinct from send_fax, though the description never names the sibling it differs from, 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?

Usage is implied rather than stated: an agent can infer this is the pre-send pricing/eligibility check, reinforced by '何も送信されません'. There is no explicit 'use this instead of X when Y' routing against send_fax or get_fax_status, so it is only minimum-viable 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 readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond them: the set of possible statuses and the fact that a completion report URL is returned only once finished. It does not discuss polling cadence or status transitions, which would be the remaining 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?

Two dense sentences with zero filler; the token source and the status-check behavior are front-loaded before the conditional return-value note.

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 carry the return burden and it partially discharges it by disclosing the completion-report URL. Status values are listed, though the full response shape and any polling expectation are not described.

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 token parameter is documented in the schema itself, so the description adds little semantic detail beyond restating that the token comes from send_fax. Baseline 3 applies when the schema carries the parameter burden.

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 (confirm FAX send status) and enumerates the concrete status values (awaiting payment, reserved, sending, complete, etc.). It also names the sibling send_fax as the origin of the token, so an agent can place it correctly in the workflow 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?

Clearly establishes the usage context: call it with the token produced by send_fax to check on a submission. It does not state any when-not-to-use condition or whether repeated polling is expected, but the trigger condition 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 destructiveHint, non-idempotent, and open-world behavior, but the description adds critical process semantics they cannot convey: payment is required via checkout_url and sending is asynchronous (auto-sent only after payment), plus format/size/page limits and single-use upload_id. It stops short of describing failure modes or retry 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?

Front-loads the core action and return value before enumerating document options and constraints. It is a dense single block but every clause carries operative information; only the parenthetical detail is slightly heavy.

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 explains the return value (checkout_url) and the payment-then-send flow, and it covers the mutually exclusive input sources for a 9-parameter tool. Missing only error/rejection handling details, which keeps it from a 5.

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 real value by stating that exactly one of upload_id/file/document_url/document_base64 must be supplied and by attaching constraints (700KB, 10MB, 100 pages, Japanese-time scheduling) that the schema does not enforce. This is meaningfully beyond field-by-field docs.

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) and the concrete return value (a Stripe checkout_url in JPY), and distinguishes itself from the sibling create_upload_link by explaining that upload_id originates there. An agent can tell this is the send-and-pay entry point rather than a pricing or status query.

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 context for each document source option (upload_id for device files, file for ChatGPT attachments, document_url for public PDFs, document_base64 for small files) and mentions the scheduling path. It does not explicitly say when to prefer get_fax_price or get_fax_status, so routing among all siblings is only partially covered.

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