avacast

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds critical behavior: the plaintext key is returned only once ('平文は今回だけ返します'), which is essential for the agent to store it. It also implies each call adds a new key, not a replacement. No contradiction with 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?

Two sentences, zero filler. The core purpose and the one-time return are front-loaded, with the prerequisite in a parenthetical. Every sentence earns its place.

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 operation with no output schema, the description covers the essential behavior (one-time return) and the prerequisite. It does not detail the response format or the exact location of the new key in the tenant, but these are minor given the annotations and schema cover the operation's safety profile.

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 all parameters have descriptions. The description adds meaning beyond the schema by explaining that api_key must be the key received at signup (the schema only says 'sk_live_…'). It also confirms environment defaults to live via the enum description, though this is already in the schema.

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?

Description states a specific verb (発行 = issue), the resource (API key), and scope (this tenant), and distinguishes it from siblings like create_avatar or create_session by naming the resource. It also clarifies live/test environments, making the purpose unambiguous.

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

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

Clear context: this tool issues an additional API key, with an explicit prerequisite (api_key from signup) stated in parentheses. However, it does not explicitly say when not to use it or name alternatives; the distinction from siblings is implied by the resource type rather than stated.

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?

With all annotations false, the description carries the behavioral burden and does so well: it discloses async latency (生成に 2〜3 分), the verified-tenant prerequisite, plan limits, and api_key requirement. It stops short of 5 because it does not discuss failure modes, duplicates, or cancellation 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 sentences with information front-loaded by importance: image requirements first, then wait time, prerequisites, and quota. Every sentence contributes operational value and there is no filler or duplication of schema details.

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?

It covers prerequisites, timing, and limits, but because there is no output schema, it omits what the response contains and how to obtain an identifier to pass to get_avatar for polling. An agent can invoke the tool, but the follow-up workflow is not fully specified.

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 meaningful constraints: accepted formats and size (PNG/JPEG、6MB まで), photo conditions, and that api_key comes from signup. This supplements the schema rather than repeating 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 specific verb and resource: 'アバターを作ります' (creates an avatar) and adds clear input constraints such as '正面・明るい・口を閉じた 1 人の写真'. This makes it easy to distinguish from sibling tools like delete_avatar, get_avatar, and create_api_key.

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 actionable context: generation takes 2–3 minutes and should be followed by polling get_avatar, only email-verified tenants can create, and per-plan limits apply. It does not explicitly state when-not-to-use or name alternatives, but the context is clear enough for an agent to decide when to call it.

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

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

Beyond the annotations, the description discloses important behavioral details: the URL leads to a one-time card-entry flow, the plan switches immediately after payment, and the billing basis is monthly pre-tax with metered overage. It also notes the api_key requirement. Nothing contradicts 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 compact and front-loaded with the core return value, followed by the workflow and pricing context. Each sentence earns its place, though it is slightly denser than strictly necessary for a two-parameter tool.

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 two-parameter tool with no output schema, the description covers the return value (Checkout URL), the required authentication, the effect, and the pricing model. It is complete enough for correct invocation, though it doesn't mention URL expiration or repeated-call behavior, which would be nice but not essential.

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

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

Schema description coverage is 100%, so the schema already explains both parameters. The description does add useful context by listing the plan values and noting that the api_key comes from signup, but it doesn't fundamentally expand on the schema's parameter meanings.

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 clearly states a specific action and resource: it returns a Stripe Checkout URL for paid plans (starter/standard/business). It also explains the intended outcome. However, it doesn't explicitly contrast itself with sibling tools like get_billing_portal, so it lacks explicit 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?

The description gives a clear use context: the user opens the returned URL and enters card details, and the plan switches immediately with only this one human step. This is enough to understand when to use it, but it does not explicitly state when not to use it or mention alternatives like get_billing_portal.

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 are all false, so the description carries the burden of explaining side effects and state changes. It adds valuable behavioral context: reserving an avatar slot, returning session credentials, and the fact that billing accrues while the session is open. This goes beyond what annotations state.

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 sentences with no filler. The core purpose is front-loaded, followed by a critical billing/lifecycle warning, and the auth note is concise. Every sentence earns its place.

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 with no output schema and a mutating side effect, the description covers the essential ground: what it does, what it returns, billing implications, and required auth. It does not enumerate error conditions or the full return payload, but given the schema coverage and annotations, this is not a critical gap.

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 input schema already documents all parameters. The description does not add meaningful parameter-level detail beyond noting that api_key comes from signup, which is marginal extra context.

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 clearly states the specific action: reserving an avatar slot and returning a client_token plus WebRTC connection info. The verb and resource are explicit墙, and the lifecycle contrast with end_session is immediately recognizable.

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 clear operational guidance: billing is based on session duration and end_session should be called when done. It also notes the api_key requirement. It does not explicitly contrast with get_session or list_sessions, but the context is largely 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 flag destructiveHint=true and idempotentHint=true, but the description adds meaningful context beyond them: presets are excluded from deletion, past session records persist, and the api_key must come from signup. No contradiction with 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?

Two compact Japanese sentences that front-load the core behavior and then the key limitations, with zero filler or redundant 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?

For a simple destructive tool, it covers what can and cannot be deleted, what persists afterward, and the auth requirement. Without an output schema, return behavior is undocumented, but this is a minor gap for a delete operation.

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 50% — api_key has a schema description but avatar_id does not. The description adds value for api_key (key received at signup), but adds nothing specific about avatar_id beyond what the tool name implies.

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 specific verb and resource ('deletes avatars you created yourself') and adds a distinguishing constraint (presets cannot be deleted). This clearly separates it from sibling tools like get_avatar, list_avatars, and create_avatar.

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 clear context: use on self-created avatars, not presets, and requires the api_key from signup. It doesn't explicitly name alternative sibling tools, but the preset exclusion acts as a clear when-not condition.

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 mark the tool as destructive, non-read-only, and idempotent, so the safety profile is covered. The description adds useful behavioral context beyond those annotations: closing the session frees the GPU allocation and forgetting to close it incurs charges. This does not contradict 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 compact, front-loads the action, and then adds the billing consequence and auth requirement. Every sentence earns its place, though the parenthetical about api_key is somewhat redundant with the schema's required designation.

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

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

The definition is adequate for a simple destructive action: it states the purpose, the resource affected, and the cost consequence, while annotations cover destructive and idempotent behavior. However, it does not mention return values, what happens to running workloads when the session is closed, or provide any session_id guidance, leaving some important operational context unclear.

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 description only elaborates on api_key, saying it is the key received at signup. session_id is not described in the schema or the description, and with only 50% schema description coverage the description should compensate for that gap but does not. Thus the agent is left to infer the meaning and format of session_id.

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 specific action ('セッションを閉じて') and the key outcome ('GPU の枠を返します'), so an agent knows this tool ends a session and releases resources. It is clearly distinguishable from siblings like create_session, get_session, and list_sessions, and even from interrupt by signaling a terminal close rather than a pause.

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 '閉じ忘れは請求に乗ります' gives the main usage cue: call this when you are done with the session to avoid continued billing. It does not explicitly compare this tool to alternatives such as interrupt, nor state when not to use it, so it misses the full 'when/when-not/alternatives' bar.

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 non-destructive. The description adds beyond that: the api_key is required and received at signup, and the tool is positioned as a diagnostic first stop for creation failures. No contradiction.

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 front-load the return data, then give usage guidance and an auth note. Every clause earns its place; no redundancy.

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

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

With a single parameter, no output schema, and safe annotations, the description covers what is returned, when to call, and what credential to use. Nothing needed to invoke the tool correctly is missing.

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

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

Schema coverage is 100% with the api_key parameter already described by name and format (sk_live_…). The description adds provenance – the key comes from signup – which is a small but useful increment over the schema. Baseline 3 plus this extra context justifies 4.

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 a concrete resource: account status with tenant name, plan, limits, email verification, and API key list. This makes it readily distinguishable from sibling tools like create_session or get_usage, even without naming them.

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 when-to-use: 'when sessions or avatars can't be created, check limits and verification status first.' This is actionable troubleshooting guidance. It doesn't enumerate exclusions or alternative tools, but the context is clear.

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, and destructiveHint=false, covering the safety profile. The description adds the return statuses and failure reason, but the api_key requirement is already present in the schema. It does not go beyond annotations to describe rate limits, errors, or side effects.

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 a single, front-loaded sentence that conveys the core purpose and a required-auth caveat without wasted words. It fits the tool's simplicity well.

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?

Since there is no output schema, the description correctly communicates the status values and failure reason. However, it omits error cases, behavior for invalid api_key or unknown avatar_id, and the intended workflow (e.g., polling after create_avatar). For a simple read tool this is acceptable but not 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?

Schema coverage is 50%: api_key has a description but avatar_id does not. The description adds context that the avatar must be one you created, which clarifies avatar_id ownership, but it does not define the ID format, how to obtain it, or what happens when it is invalid. The improvement over the schema is marginal.

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 clearly states a specific verb (returns) and resource (status of your own avatar), and enumerates the return values (preparing / ready / failed and failure reason). This distinguishes it from sibling tools like list_avatars or delete_avatar even without naming them.

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 explicit guidance about when to call this tool versus alternatives is provided. It does not mention using it after create_avatar to poll readiness, nor contrast it with list_avatars for enumerating avatars. The status values imply polling, but that is left 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 mark readOnlyHint=false, indicating the tool may have side effects (e.g., creating a billing portal session). The description only says 'returns the URL' and gives no hint about side effects or state changes. It adds no behavioral context beyond what annotations already imply, and fails to explain the non-read-only nature.

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, front-loaded with the core action, followed by use cases and a prerequisite. No wasted words; every clause adds 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?

For a simple one-parameter tool with no output schema, the description covers the purpose, return value, usage precondition, and key source. It lacks error handling or edge-case notes (e.g., what if no paid plan), but these are minor given the tool's simplicity.

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% with api_key already documented, but the description adds context that the key is 'received at signup,' which goes beyond the schema's 'sk_live_…' placeholder. This extra guidance helps the agent locate the correct key.

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 specific verb and resource: 'Returns the URL of Stripe's customer portal' and lists concrete use cases (change payment method, receipts, cancellation). It is clearly distinguishable from sibling tools like create_checkout or get_session, none of which serve the same billing-portal purpose.

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 provides a clear precondition: 'Can be used after subscribing to a paid plan.' It also notes the required api_key. However, it does not explicitly name alternative tools or say when NOT to use it, so it falls slightly short of full routing 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 read-only, idempotent, and non-destructive behavior, and the description's 'returns ... in Markdown' is consistent with that. It adds useful behavioral context by specifying the Markdown output format and the exact topics covered, which is not present in annotations or the schema.

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 compact sentence leads with the key action and resource ('avacast の組み込み方') and then itemizes the guide contents. Every element earns its place with no redundancy.

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 parameterless documentation tool with no output schema, the description is complete: it specifies what is returned, the format, and the covered topics. The read-only/idempotent annotations cover the safety profile, so nothing needed to call it correctly is missing.

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

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

The tool has zero parameters, so the schema is fully complete and the baseline is 4. There is nothing for the description to add about 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?

The description names a specific verb and resource: it returns (返します) the avacast integration guide. It enumerates the guide's contents (session creation, browser SDK, REST API, error codes), which clearly distinguishes this documentation tool from operational sibling tools like create_session and get_usage.

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 intended use is implied: an agent should call this when the user wants integration instructions or the error-code reference. However, it never explicitly states when to prefer this tool over the sibling API tools, nor does it mention alternatives or exclusions.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the api_key authentication requirement, which is beyond what annotations provide. It does not contradict any annotation, and while it adds the auth context, it omits details like whether the session can be queried after it ends or error behavior for invalid session_id.

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

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

A single, tightly-packed sentence that front-loads the return values and appends the auth requirement as a parenthetical. No filler or redundancy, though the two distinct pieces of information (return payload and auth prerequisite) could be structured slightly more explicitly.

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?

As a read-only state inspection tool with no output schema, the description compensates well by enumerating the return fields (state, queue length, connection time, expiry). However, the session_id parameter is left undocumented, and there is no guidance on edge cases like expired sessions or invalid keys, which an agent might reasonably need for a complete call.

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 50%: api_key is described in the schema ('API キー (sk_live_…)') and the description reinforces its origin ('signup で受け取ったキー'), adding value for that parameter. However, session_id has no schema description and the tool description provides no semantics for it, leaving a gap that neither the schema nor the description fills.

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 ('返します' - returns) with a clear resource (session state) and enumerates the exact fields returned: active/ended status, queue length, connection time, and expiry. This distinguishes it from siblings like create_session, end_session, and list_sessions, and reinforces the title without being tautological.

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 discloses a prerequisite: api_key is required and must be the one received at signup, which is useful context for invocation. However, it does not explicitly differentiate this tool from alternatives such as get_account or list_sessions, nor does it state when an agent should prefer get_session over list_sessions for inspecting a single session's state.

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, and destructiveHint=false, so the safety profile is covered. The description adds useful context by identifying the returned metrics and flagging connection time as the basis for billing, but it does not describe error behavior, response structure, or any operational side effects 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 a single, front-loaded sentence that directly names the return values and the authentication requirement. There is no filler or redundant verbiage, and the key context is placed prominently.

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 low complexity (one simple parameter, no nested objects, no output schema), the description adequately covers the tool's purpose, required input, and return values. It does not specify units for connection/speech time or response format, but the essential information an agent needs to call it correctly is present.

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

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

Schema description coverage is 100%, and the single api_key parameter is already documented as 'API キー (sk_live_…)'. The description adds the detail that the key is obtained at signup, which is mildly helpful, but it does not materially expand on the schema's semantics. Baseline 3 is appropriate given the high schema coverage.

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 specific verb ('返します' – returns) and a clearly defined resource: current-month connection time, speech time, session count, and plan limits. This is sufficiently distinct from sibling tools like get_account, get_session, list_sessions, and list_plans, so an agent can infer which sibling to choose.

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

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

The description explains what the tool returns and notes that an api_key is required, but it gives no guidance on when to choose this tool over alternatives such as get_account or list_plans. There are no explicit usage contexts, exclusions, or when-not-to-use conditions.

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 description adds useful behavioral context beyond annotations: it specifically states that the tool halts the current utterance and clears the queue, and it identifies the api_key source as signup. The 'discard' wording refers to runtime queue state, so it does not clearly contradict destructiveHint=false.

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 concise sentence plus a short parenthetical. The core behavior is front-loaded)Skip no filler and no redundant repetition of schema details.

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 low-complexity control tool, the core behavior and auth requirement are covered, and annotations add idempotency and non-destructiveness. However, session_id is left underdocumentedasi and no response/error behavior is mentioned, making this only minimally 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?

Schema coverage is only 50%: api_key has a schema descriptioncars, but session_id has none. The description reinforces the api_key requirement but does not explain what session_id refers to or that it must identify an active session. This leaves a significant parameter ambiguity.

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 concrete action: stop the currently-uttering sentence and discard remaining sentences in the queue. This clearly distinguishes it from siblings like speak and end_session by naming the exact resource and 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 intended use is implied by the action described, but there is no explicit when-to-use guidance, no mention of alternatives, and no exclusion criteria. The only extra precondition mentioned is the api_key requirement.

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?

アノテーションが readOnlyHint・idempotentHint・destructiveHint を既に提供しており、説明は「プリセットと ready のものだけ返す」というフィルタ条件と、API キーが signup 由来である認証前提を追加している。戻り値の細部やページングは説明されていないが、アノテーションが安全プロファイルを補完しているため十分。

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?

2 文に必須情報を集約し、冒頭で返すものの範囲を提示、続けて利用方法と認証要件を簡潔に述べている。無駄な文言がない。

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?

1 パラメータの低複雑度ツールで、認証要件・取得対象・create_session への接続という選択と実行に必要な文脈が揃っている。出力スキーマがないため戻り値の構造は明示されていないが、正しく呼び出すための重大な欠落はない。

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?

api_key はスキーマに必須・型・例が記載されており、スキーマの説明カバレッジは 100%。description は「signup で受け取ったキー」という由来を付け加えるが、パラメータの形式や挙動に関する追加情報は限定的で、ベースラインの 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?

「使えるアバターを返す」と明記され、プリセットとテナント内で作成済みの ready アバターという対象範囲を定義。create_session の avatar_id に使うという文脈により、get_avatar や create_avatar などの兄弟ツールと十分に区別できる。

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?

create_session への id 受け渡しという具体的な利用シーンを示し、このツールをいつ呼ぶべきかが分かる。「api_key が必要」という前提も明記されている。ただし、list_voices など代替ツールとの使い分けや「これを使うべきでない場合」は明示されていない。

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 read-only, idempotent, non-destructive nature of the tool. The description adds the return-value scope but does not disclose additional behavioral details such as whether pricing data is cached, whether authentication is required, or whether plan availability changes.

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 compact sentences: the first states what the tool returns and front-loads the key output fields; the second adds practical next-step guidance. Every sentence contributes value with no redundancy 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?

With no output schema present, the description carries the burden of explaining return values, and it does so by listing the fields returned per plan. For a zero-parameter read-only tool, this is complete enough for an agent to call it successfully and understand the result.

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 has zero parameters and the schema coverage is 100%, so there is nothing for the description to explain about parameters. The baseline of 4 applies because no parameter semantics are needed.

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?

Description states a specific action ('returns') and resource ('per-plan') and enumerates the exact output fields: monthly fee, included connection minutes, concurrent sessions, max session length, and avatar count. This clearly distinguishes it from sibling list_* tools like list_sessions and list_avatars.

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 workflow context: try the Free signup plan first, then use create_checkout if the included limits are insufficient. This implies list_plans is the tool to consult before deciding on a plan, though it does not explicitly state exclusions or when not to use it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering safety. The description adds the return contents and the troubleshooting purpose, which is beyond annotation coverage. No contradiction. It doesn't disclose pagination or rate limits, but those are minor given the read-only nature.

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, front-loaded with the core function and return data, followed by the use case. No wasted words; the api_key note is brief and relevant.

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 read-only list tool with a simple output (status, end reason, connection seconds), the description is sufficient. It specifies the max count and the key use case. It lacks exact output formatting or pagination details, but these are not critical given the tool's simplicity and the annotations covering safety.

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%, with both limit and api_key fully documented (default, max, format). The description's mention of max 50 mirrors the schema's limit max. It adds no additional parameter semantics beyond what the schema already provides, 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?

The description states a specific verb ('返します' – returns) and resource ('直近のセッション' – recent sessions), and specifies the returned data (状態・終了理由・接続秒数). It clearly distinguishes from siblings like get_session (single session) and end_session (mutation).

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 a concrete use case: troubleshooting connectivity issues ('繋がらない・すぐ切れる問題の切り分けに使います'). It doesn't explicitly mention alternatives or when not to use, but the context is clear and relevant.

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, and destructiveHint=false. The description adds useful behavioral context: api_key comes from signup and the response has free vs Gemini-TTS voice tiers. It does not describe response shape or pagination, but for a simple one-parameter list with strong annotations this is acceptable.

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 a single compact sentence that front-loads the resource and purpose, then gives downstream usage, cost tier, and auth source. Every clause adds value, with no repetition of schema or annotation data.

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

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

For a one-parameter, read-only listing tool, the description is nearly complete: it explains what is returned, where the result is consumed, and the auth requirement. The absence of an output schema means a bit more detail about the exact response fields would help, but the phrase 'voice_id' and '一覧' convey enough for correct invocation.

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 api_key parameter already has type and format ('API キー (sk_live_…)'). The description's mention that the key is received at signup adds marginal context, but the schema carries the main semantic burden, so 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?

The description states a specific verb and resource: it returns a list of usable voices ('使える声 (voice_id) の一覧'). It also explicitly maps the output to the voice_id parameter used in create_session and create_avatar, which distinguishes it from sibling list_* tools.

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 clear context on when to use it: when you need a voice_id for create_session or create_avatar. It also adds a cost/free distinction between the Japanese standard voices and Gemini-TTS voices, helping the agent choose appropriately. It does not explicitly name an alternative or state when not to use it, so it misses the top bar.

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 mark this as non-read-only and idempotent; the description adds real side effects: it returns the link and sends an email, and opening the link consumes free-tier quota. It also notes the api_key requirement, which is useful beyond the schema. No contradiction with 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?

Two concise sentences with the core action first and the behavioral caveat second. The parenthetical auth note is relevant, though the quota phrasing ('無料枠の上限になります') is slightly awkward.

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

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

For a one-parameter tool with no output schema, the description covers the action, target, side effect, auth requirement, and quota impact. It could add what happens for already-confirmed tenants, but nothing essential is missing for a basic call.

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 single api_key parameter is already fully described in the schema (100% coverage). The description adds that the key is the one received at signup, which clarifies where to obtain 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 uses a specific verb ('再発行して返し、メールにも送ります') tied to a precise resource (confirmation link for email-unconfirmed tenants). It clearly distinguishes this tool from siblings like signup or create_session by identifying the unique action and target.

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 defines the applicable context: use when the tenant's email is unconfirmed. It does not name alternatives or explicitly state when not to use it, but the sibling list contains no competing resend/verification tool, so the context is sufficient.

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

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

The description goes well beyond the annotations by revealing that signup requires no password, returns an API key and verify link, and is conditional on verification: an unopened verify_url expires after one hour. It also discloses the free-tier quota expansion once verified. This gives the agent a realistic model of the tool's side effects.

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 four sentences each carry distinct information: account creation and returned values, immediate usability, verification and quota expansion, and expiration. The main result is front-loaded in the first sentence. There is no filler or repetition.

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

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

For a one-parameter tool with no output schema, the description covers the key return values (API key, verify_url) and the lifecycle behavior that would otherwise be unpredictable. It could mention handling of already-registered emails, but the essential success path is complete and actionable.

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 input schema already fully documents the single `email` parameter, so the baseline is 3. The description adds only that the email is used to create the account and receive the verify link, without adding format or validation details. This is adequate but does not meaningfully extend the schema.

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 specific verb and resource: it creates an avacast account with an email and returns an API key plus verify_url. It clearly distinguishes signup from siblings like create_api_key or create_session, which do not create the account. The no-password detail adds further precision.

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 clearly frames the signup scenario and explains that the returned key can be used immediately, which implies this is the entry point before other session/key tools. However, it does not explicitly name alternatives or state when not to use it, such as when resending verification or creating additional API keys. This is clear context without exclusions.

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

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

The annotations are all false (readOnlyHint=false, idempotentHint=false, etc.), so they convey only what the operation is NOT. The description adds genuine behavioral context beyond them: utterances are queued and played sequentially, calls before connection fail with session_not_connected, and an api_key is mandatory. No contradiction with 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?

Three compact sentences, each carrying distinct information: purpose plus ordering semantics, connection precondition plus error case, and authentication requirement. The purpose is front-loaded and there is no filler or repetition of schema 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 low-complexity tool with three flat required parameters, the description covers purpose, queue semantics, the connection precondition, the error result, and authentication. The main gap is that no output schema exists and the description never mentions the return/response shape, which an agent might need to evaluate the outcome of the call.

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 67% (session_id has no schema description). The description compensates partially: it links text to the queueing behavior, explains that api_key is the key issued at signup ('signup で受け取ったキー'), and frames session_id as the session whose avatar will speak. session_id remains the least-specified parameter in both the schema and the 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 action with a clear verb and resource: 'セッションのアバターにテキストを喋らせます' (makes the session's avatar speak text), including the scoping nuance that utterances are queued and spoken in order. The action is unique among the 20 sibling tools — the only related one, interrupt, is plainly a different operation, so there is no ambiguity.

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 an explicit temporal precondition — call only after the browser SDK connects via 'session.start' — and discloses the failure mode for violating it ('接続前は session_not_connected になります'). It does not name sibling alternatives (e.g., interrupt to stop speech), so it stops short of full routing guidance, but the when-to-use context is clear.

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