すぐFAX SuguFAX – AI fax credits (API key)

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=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds nothing beyond that—no auth requirements, no rate limits, no indication of whether a missing account returns zero or an error.

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 no filler or redundancy. It is not verbose, though it is also close to the minimum possible content.

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-param read tool with no output schema, the description should ideally say what the response contains (e.g. remaining credit amount and units) and whether an error occurs with no credits. It omits both, leaving the agent to call blind, but the operation is simple enough that this is a modest gap rather than a blocking one.

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 meaning for the description to carry. Baseline 4 applies; nothing is missing or misleading.

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 clear verb+resource (check AI credit balance) and the resource is distinct from all siblings (upload links, fax price, fax status, send fax). However, it is essentially a natural-language restatement of the tool name and title with no added scope detail (which account, which credit pool, what unit). Adequate but thin.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. The siblings are all fax-related, so there is little genuine ambiguity, but the description provides no routing signal at all.

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/non-destructive, so the bar is lower; the description nonetheless adds real value by specifying the currency and tax treatment (日本円・税込), the eligibility-verification behavior, and concrete unsupported prefixes (携帯電話番号・0990・0570). It does not describe failure messages or rate limits.

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 what is computed, then the eligibility caveat, then the safety reassurance. Every sentence carries distinct information and nothing is padding.

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

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

With no output schema, the description does the work of explaining the return content: a JPY tax-included price plus destination-compatibility. That covers the essentials for a 2-param lookup, though it could say how an unsupported number is surfaced (error vs. flag).

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 both fax_number and pages are already fully documented, including format examples and the 1–100 range. The description only restates that price derives from destination and page count, adding no syntax or constraint detail beyond the schema — the baseline 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 (confirm/check) and resource (FAX price in JPY, tax included), and scopes the inputs (destination + page count). It is immediately distinguishable from siblings like send_fax and get_fax_status, and even discloses the eligibility-check side effect.

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 closing line '何も送信されません' clearly frames this as a pre-send lookup rather than an action, which is the key usage context against send_fax. However, it never explicitly names the alternative or states the when-not condition (e.g., 'use this before send_fax'), so it falls short of a 5.

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

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

Annotations already declare 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 the safety profile (destructive, non-idempotent, open-world write). The description adds real context beyond that: credit consumption (1 credit per fax, up to 100 pages regardless of page count), upload_id being single-use, and the 10MB/100-page file limits and scheduling window.

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 and credit cost, followed by file-source options and limits. It is a single dense paragraph, so it is efficient but lacks visual structure and slightly compresses a lot into one block.

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 an 8-parameter mutation tool with no output schema, the description covers document sources, size/page constraints, credit cost, and scheduling adequately. It does not describe the success/failure response the caller should expect, which is a modest gap given no output schema exists.

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 schema already documents each parameter individually. The description adds genuine meaning beyond the schema by stating the four document sources are mutually exclusive ('いずれか1つ'), which no individual parameter description conveys.

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 — '実際にFAXを送信します' (actually sends a FAX) — and the '実際に' framing implicitly contrasts with the preparatory/query siblings (create_upload_link, get_fax_price, get_fax_status). It never names those siblings explicitly, so it falls short of full sibling differentiation.

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 on the four mutually exclusive document sources and which to prefer ('通常は create_upload_link をお使いください'), plus that scheduled_at defers sending. It does not state when to call get_fax_price first or get_fax_status afterward, so no explicit when-not guidance.

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