avacast

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

Annotations already declare readOnlyHint=false and idempotentHint=false, but the description adds a genuinely important behavioral fact: the plaintext secret is returned only this once (平文は今回だけ返します). This is critical operational context beyond the annotations. It stops short of 5 because it does not cover permissions 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 compact parenthetical clauses; the purpose is front-loaded and there is little waste. Slightly telegraphic style but efficient and readable.

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

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

No output schema exists, and the description supplies the key return-value fact (secret shown once only). It rounds out a creation tool adequately, though it omits any mention of the created key object's structure or scope.

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?

With 100% schema description coverage, the schema already documents name, api_key, and environment. The description adds marginal value by noting environment maps to live/test production-vs-test semantics and that api_key is a key issued via the admin panel. Baseline 3 is appropriate since the schema does the heavy lifting.

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 (発行 = issue) and resource (API キー) and scopes it to 'このテナント' (this tenant). It is clearly a creation tool distinct from read/destructive siblings. It does not explicitly name a sibling to differentiate from, so it falls 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?

It conveys context — issuing 'もう 1 本' (one additional key) with live/test variants — but gives no explicit when-to-use/when-not guidance or alternatives. Usage is only implied, which matches the 3 baseline.

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 readOnlyHint=false and openWorldHint=true, so the description earns credit for adding the non-obvious traits: asynchronous generation with a 2-3 minute latency and the need to poll get_avatar, plus tenant verification and quota limits. It stops short of describing failure modes or what happens when the quota is exhausted.

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 tight clauses, each with distinct value: input requirements, async latency and polling instruction, eligibility, and quota/auth note. Front-loaded with the actionable input spec, 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?

For a creation tool with no output schema, the description covers the essential gaps: input constraints, async behavior and how to observe completion, prerequisites, and auth requirements. It omits what a successful response returns, but polling get_avatar covers the observable outcome, so nothing critical 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 real constraints beyond the schema: the image must be a single person, front-facing, bright, mouth closed, and under 6MB. It does not clarify the image_url vs image_base64 choice or the voice parameters, but it adds genuine meaning for the critical image input.

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 (avatar creation) plus the exact input medium and constraints (one person, front-facing, bright, mouth closed, PNG/JPEG up to 6MB). This clearly separates it from siblings like list_avatars, get_avatar, and delete_avatar since it is the only tool that originates an avatar from an uploaded photo.

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?

Explicitly routes the agent to the follow-up tool ('wait for ready via get_avatar') and states two eligibility preconditions: email-verified tenant and per-plan creation quota. It does not state when not to use it versus alternatives, but the context it gives is concrete and actionable.

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 cover safety (readOnlyHint=true, destructiveHint=false, idempotentHint=true). The description adds meaningful context beyond that: the returned URL depends on current plan status, the user must confirm in the browser, and billing is tax-excluded monthly with usage-based overage. It does not describe error behavior or URL expiry, but it is solidly transparent for a read-only URL-returning tool.

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 front-loaded with the core purpose, then proceeds through conditional behavior, user action, and billing details. Each sentence is informative, though the tax/overage pricing note is tangential to tool selection and invocation. It is well-structured and not wasteful overall.

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 two required parameters, full schema coverage, clear annotations, and no output schema, the description is complete for this tool. It explains the return value as a URL, the two conditional URL types, the user confirmation step, and the api_key requirement. Nothing essential for calling 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 description coverage is 100%, so the schema already documents both parameters and the plan enum. The description adds that api_key is required and issued in the admin screen, and lists the plan enum values, but this is mostly redundant with the schema. Baseline 3 is appropriate.

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

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

The description states a specific verb and resource: it returns a URL for subscribing to a paid plan (starter/standard/business) or changing a plan. It distinguishes between the Stripe Checkout URL and the admin confirmation URL based on current plan status. It does not explicitly differentiate from sibling tools such as get_billing_portal, so it falls 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?

The description gives clear conditional usage: if not yet on a paid plan, it returns a Stripe Checkout URL; if already on a paid plan, it returns the admin change confirmation URL. It also explains that the user must open and confirm in a browser. It does not name alternatives or when-not-to-use cases against siblings, so it is a 4 rather than 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?

Beyond the annotations (non-read-only, non-idempotent, non-destructive), the description discloses the cost model (time-based billing tied to session duration), the auth requirement and where to obtain the key, and the payload returned. It does not mention concurrency limits or what happens on repeated calls despite idempotentHint=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?

Two tight sentences: the primary effect and return values come first, followed by the billing/cleanup obligation and the auth prerequisite. No redundant restatement of the tool name or 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?

With no output schema, the description usefully names the returned client_token and WebRTC info, and it covers auth, billing, and cleanup for a mutation-style tool with a nested object parameter. Error behavior and session concurrency limits are the remaining gaps.

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

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

Schema description coverage is 100% and every parameter, including nested metadata and voice_id syntax, is documented in the schema. The description only reinforces the api_key requirement rather than adding parameter-level meaning, so the baseline of 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 names a specific verb and resource — reserves an avatar slot and returns a client_token plus WebRTC connection info. This is clearly distinguishable from siblings like get_session, list_sessions, and end_session.

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 states the lifecycle context explicitly: billing accrues while the session is open, so end_session must be called when finished, and an api_key issued in the admin console is required. It stops short of naming alternative entry points or conditions 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 destructiveHint=true and idempotentHint=true, so the safety profile is covered structurally. The description still adds real value beyond them: the preset exclusion, the fact that past session records are retained, and the api_key requirement with its provenance.

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 clauses, front-loaded with the core action and each carrying distinct information (scope restriction, data retention, auth need). No filler or restatement of the name.

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 destructive mutation with no output schema, the description covers the important gaps: what is destroyed, what survives, and what auth is needed. Only the avatar_id parameter's semantics remain unaddressed.

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 but avatar_id is bare. The description enriches api_key by naming its source (admin panel-issued key), but adds nothing on avatar_id's format or origin, so it only partially compensates for the uncovered parameter.

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?

Names a specific verb and resource ('自分で作ったアバターを消します') and immediately scopes it with a constraint ('プリセットは消せません'), clearly distinguishing it from sibling write tools like create_avatar and read tools like list_avatars/get_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?

Provides a clear when-not condition (presets cannot be deleted) and states the authentication prerequisite (api_key issued via admin panel). It doesn't explicitly point to an alternative for finding a valid avatar_id, but the usage context is easy to infer.

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=true, idempotentHint=true, and readOnlyHint=false, and nothing in the description contradicts them. The description adds real behavioral context beyond the annotations: that ending frees a GPU slot and that leaving sessions open accrues billing charges, plus the api_key requirement.

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 clauses, front-loading the action and its effect, with the billing consequence and auth prerequisite appended parenthetically. No filler sentences.

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 mutation with no output schema and annotations covering safety/idempotency, the description supplies the essential missing context (GPU release, billing cost of omission, auth needs). Only the session_id semantics remain unaddressed.

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 documented in the schema and the description merely repeats that requirement, while session_id is undocumented in both places. The description does not compensate for the uncovered parameter, so this sits at the baseline for partial 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?

States a specific verb and resource ('セッションを閉じて' / close the session) plus the side effect of returning the GPU slot, which cleanly distinguishes it from siblings like get_session, list_sessions, and create_session. An agent can identify the operation 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?

The billing warning ('閉じ忘れは請求に乗ります') gives a strong implicit reason to call this when finished with a session, but there is no explicit when-to-use/when-not or named alternative against the get/list/interrupt siblings. Usage is implied rather than directed.

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 that the call needs a key issued in the admin panel, which is useful auth context, but it doesn't disclose anything about rate limits, pagination, or the sensitivity of returning API keys.

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

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

Two tight sentences: return content first, diagnostic use second, auth note last. The 'api_key is required' clause is mildly redundant with the schema's required field, which keeps it from a 5.

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?

There is no output schema, but the description enumerates the returned fields, which compensates well. Combined with annotations covering the read-only profile, an agent has what it needs to invoke this correctly, though limit/key semantics could be richer.

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?

With one parameter at 100% schema description coverage, the schema already documents api_key (including the sk_live_ format). The description only adds where the key is obtained, which is marginal value over the structured field, so the 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 clear verb+resource and enumerates the returned fields (tenant name, plan, limits, API key list), which is specific enough to distinguish it from the list_* and get_session/get_avatar siblings. It stops short of explicitly naming a sibling it overlaps with, so 4 rather than 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?

Gives a concrete diagnostic trigger: 'when sessions or avatars cannot be created, check the limits here first.' That is actionable context without naming the alternative tools, so it is clear guidance but not a full when/when-not matrix.

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 structurally. The description adds the authentication requirement (api_key needed, issued in the admin console) and the returned state machine, which is modest added value over 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?

Two sentences with the purpose front-loaded and the auth prerequisite tucked into a trailing parenthesis. Nothing is padded, though the api_key note could arguably sit in the schema only.

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 getter with no output schema, the description usefully carries the return contract (enum states plus failure reason) and the auth requirement, and annotations cover the safety profile. The main residual gap is the undocumented avatar_id and lack of guidance versus list_avatars.

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 format description but avatar_id has none. The description partially compensates by flagging api_key as required and stating where it is issued, but avatar_id remains undocumented in both places. Adequate but not rich.

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 (アバターの状態) and even enumerates the possible return values (preparing / ready / failed) plus the failure reason, which is unusually specific. It does not explicitly distinguish itself from list_avatars, but the singular scope and status-enum detail make 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?

There is no stated when-to-use or when-not-to-use guidance, and no alternative tool is named. The phrase 自分で作ったアバター implies a post-creation polling context, but that is left for the agent to infer 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?

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds the auth requirement ('api_key が必要: 管理画面で発行したキー') and the post-subscription precondition, which are genuine behavioral details not present in the structured fields.

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 compact sentence with parenthetical detail; the core action is front-loaded and no sentence is wasted. Slightly dense but appropriate for the amount of information conveyed.

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 tool with no output schema, the description covers what is returned (a portal URL), the precondition, and the auth need. Nothing critical is missing, though the return/error behavior is left implicit.

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% for the single api_key parameter, so the baseline is 3. The description reinforces that the key must be issued from the dashboard and shows the format, but adds little syntax or validation detail beyond 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 names a specific verb and resource ('Stripe の顧客ポータルの URL を返します') and enumerates what the portal lets the user do (payment method changes, receipts, cancellation). It is clearly distinct from create_checkout/list_plans, though it does not explicitly name the sibling an agent should pick instead.

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?

'有料プランの契約後に使えます' states a concrete precondition for use, which is real context beyond the name. It stops short of naming alternatives or stating when NOT to use it (e.g., for new subscriptions use create_checkout).

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 genuinely new behavior: the return format is Markdown, the content is documentation rather than data, and an api_key is required. No contradictions 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 plus a parenthetical; the resource and its contents are front-loaded before the usage advice and auth note. No filler, though the parenthetical auth note partially duplicates the schema's required field.

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 single-parameter documentation-retrieval tool with no output schema, the description supplies everything needed: what it returns, the format (Markdown), the topics covered, and the auth prerequisite. Nothing an agent needs to invoke 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?

Schema coverage is 100% and the single param is documented there, so baseline is 3. The description adds provenance the schema lacks — the key is issued in the admin console (管理画面で発行したキー) — which helps the agent understand how to obtain it, nudging above baseline.

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 (返します/returns) and resource (avacast の組み込み方), and enumerates the exact contents: セッションの作り方, ブラウザ SDK, REST API エンドポイント, エラーコード. An agent can immediately tell this apart from the CRUD siblings like create_session or 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?

Gives clear situational context: 「コードを書く前に一度読んでください」 tells the agent to consult this before writing code. It stops short of naming any alternative or stating when NOT to call it, but no sibling offers overlapping documentation, so the guidance 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?

With annotations already declaring readOnlyHint, idempotentHint, and non-destructive behavior, the description adds useful context: it lists the exact returned fields and notes that an api_key (issued in the admin panel) is required. It does not mention rate limits or error behavior, but the added return-value and auth details are valuable 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?

Two sentences, front-loaded with the returned information and followed by the mandatory auth note. There is no redundant or filler 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?

The description covers the return payload (since no output schema exists) and the auth requirement, and annotations cover the safety profile. The only gap is that session_id is not described anywhere, but for a simple read tool this is a minor omission.

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 50%: api_key has a schema description, session_id does not. The description reinforces api_key semantics by stating it is required and where it can be obtained, which adds meaning beyond the schema. However, session_id remains undocumented in both schema and description, so compensation is only partial.

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 returned resource (session status) and enumerates the exact fields returned (active/ended, queue length, connection duration, expiration). This distinguishes it from siblings like list_sessions (which lists many) and end_session (which mutates state).

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

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

Usage is implied by the need to know a specific session's state, but the description never states when to use this tool versus alternatives such as list_sessions or end_session. No exclusions or explicit routing guidance is provided.

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 cover safety (readOnly, idempotent, non-destructive), so the bar is lower. The description adds real value by explaining how to interpret cap_period: the stopping limit is the smaller of the plan limit and set_spending_cap, and that paid plans count over the billing period — semantics an agent could not derive from schema or 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 dense sentences, front-loaded with the returned metrics before the cap_period nuance and the key requirement. Compact for the amount of meaning conveyed, with 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?

No output schema exists, so the description carries the burden of describing return values — and it does: connection time, speech time, session count, plan limits, and cap_period semantics. Units and per-plan breakdown detail are left unstated, a minor gap for a single-object read tool whose safety profile is fully annotated.

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?

One required param at 100% schema coverage would baseline at 3, but the description adds provenance the schema lacks: the key must be the one issued in the admin panel. That is genuine added meaning beyond 'API キー (sk_live_…)'.

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 current month's usage metrics (connection time as billing basis, speech time, session count) plus plan limits. An agent can tell it apart from list_plans or get_account by the metric set, though it never explicitly names those siblings.

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 — you call it to check consumption against limits. It gives a prerequisite (api_key must be issued in the admin panel) but no explicit when-to-use/when-not-to-use guidance or alternative tools for the same question.

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 idempotentHint=true, destructiveHint=false and readOnlyHint=false, and the description usefully adds that queued utterances are discarded and that an admin-issued api_key is required. However, discarding pending speech reads as mildly at odds with destructiveHint=false, and no behavior is described for the no-op case (e.g. when nothing is speaking).

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

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

Two short sentences with the primary action front-loaded and no filler. The api_key parenthetical is arguably redundant with the required-parameters list, keeping it just short of ideal brevity.

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 mutating tool with no output schema this is nearly adequate, but it omits the session_id explanation, error/no-op behavior, and any routing versus end_session, leaving real gaps the structured fields do not fill.

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 is documented in the schema while session_id has no description anywhere. The description partially compensates by stating api_key is required and where to obtain it (admin panel), but it adds nothing about 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 pair — stop the currently playing utterance and discard queued utterances — which is more precise than the title "中断する". It implicitly distinguishes itself from siblings like end_session (session survives, only speech stops) but never names or contrasts with 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?

There is no explicit when-to-use guidance and no comparison to the obvious alternative, end_session, which also halts activity. The agent must infer that interrupt is a lightweight, session-preserving stop while end_session tears the session down.

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, and openWorldHint=false. The description adds useful behavioral context beyond annotations by stating that an api_key is required and that the key is issued from the admin panel.

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 front-loaded with the purpose, then adds the key usage detail and authentication requirement. Every sentence is short and 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 simple list tool with rich read-only annotations and complete one-parameter schema coverage, the description covers scope, downstream id usage, and authentication. No output schema exists, so return-value details are not required.

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 api_key is already documented as a string with the sk_live_ prefix. The description adds useful meaning by clarifying that the key is required and is issued in the admin panel, going beyond the schema's format-only note.

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 usable avatars, explicitly scoping them to presets and ready avatars created in this tenant. This distinguishes it from siblings like get_avatar, create_avatar, and delete_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?

The description gives clear downstream usage: use the returned id for create_session's avatar_id. It implies the context for selecting an avatar before creating a session, but it does not explicitly name alternatives such as get_avatar or state when not to use this tool.

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

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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior. The description adds useful context beyond annotations: it requires an api_key issued in the admin panel and enumerates the returned fields even though no output schema exists. It does not discuss rate limits or pagination details.

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 tightly written sentences: the first front-loads the returned plan details, and the second gives the usage comparison and auth requirement. Every clause adds distinct information, with 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?

For a low-complexity read-only list tool with rich annotations and a fully described single parameter, the description is complete enough. It enumerates return fields in lieu of an output schema, states the auth requirement, and routes the agent to get_usage for comparison.

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 api_key parameter is already documented as a string with an sk_live_ example. The description adds provenance beyond the schema by noting the key must be issued in the admin panel, which is useful but limited given only one parameter.

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 return resource and enumerates exactly what is returned: monthly price, included minutes, concurrent sessions, max session length, avatar count, and overage price per plan. It also names the sibling tool get_usage for comparison, making the resource and scope distinguishable.

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 explicitly tells the agent to compare with get_usage usage when choosing a plan, giving clear usage context. It does not state when not to use list_plans or cover other alternatives, so it falls short of the top score.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds genuinely new context: the 50-item cap and the requirement for an api_key issued in the admin panel, which the annotations do not 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?

Two compact sentences plus a parenthetical auth note, front-loading what is returned before the use case. Every clause carries information; 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 compensates by naming the returned fields (status, end reason, connection seconds) and the item cap. Auth and scope are covered; only the explicit relationship to get_session 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 description coverage is 100%, so both parameters are already documented in the schema, including the default 20 / max 50 on limit. The description reinforces the 50 cap but adds no syntax or format meaning beyond the schema — the baseline 3 for full 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?

States a specific verb and resource — returns "直近のセッション (最大 50 件)" — and even enumerates the payload fields (status, end reason, connection seconds). The plural, capped list framing implicitly distinguishes it from the single-session get_session sibling, though no sibling is named explicitly.

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 concrete when-to-use intent: isolating "can't connect / immediately disconnects" problems. It does not, however, state when to prefer this over get_session or create_session, so routing is inferred rather than explicit.

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

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

Annotations already declare readOnly, idempotent, non-destructive, non-openWorld, so the safety profile is covered. The description adds genuinely new context: the voice taxonomy (2 Japanese standard voices plus age-tagged Gemini-TTS voices) and the pricing note that cost does not vary by voice – useful traits not in 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 tight sentences, front-loaded with what the tool returns, then where the values are used, then catalog/pricing facts. No filler; the api_key note is parenthetical.

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 single-parameter read-only lister with no output schema, the description covers purpose, consumers, catalog composition, and cost behavior. It omits what fields each voice record returns, but with no output schema that is a minor 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 coverage is 100% and the single parameter (api_key) is fully documented in the schema. The description mentions api_key needs to be issued from the admin console, adding minor operational context, but nothing about the parameter's syntax beyond what the schema provides. 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+resource ('使える声 (voice_id) の一覧' – list of available voices) and immediately distinguishes itself from siblings by naming the exact downstream consumers (create_session, create_avatar) that need the voice_id. An agent can route to this tool 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?

Gives clear usage context by naming the two sibling tools that consume voice_id, which tells the agent when to call this first. It does not give explicit when-not-to-use or an alternative lister, but for a leaf enumeration tool this is strong.

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 declare destructive/idempotent/non-read-only, and the description adds substantial context beyond them: exceeding cap blocks new session creation, no charges accrue beyond the cap, only values at or below the current cap are accepted, and the admin-console workaround for raising it. It also flags the required api_key, addressing auth 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?

Dense but well front-loaded: the core action and unit come first, followed by consequences and the raise/remove path. Every sentence carries information, though the api_key note at the end is somewhat tacked on.

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?

There is no output schema, and the description compensates by disclosing the returned settings_url and its purpose, plus the auth requirement and the cap's effect. An agent has everything needed to call the tool and instruct the user 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 schema already documents both parameters, including the '<= current cap' constraint on minutes. The description restates those same semantics rather than adding format, unit, or boundary details beyond what the schema 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?

States a specific verb+resource: setting the monthly (or billing-period for paid plans) connection-time cap, expressed in minutes. No sibling tool touches spending caps, so an agent can identify this uniquely from the name and description alone.

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?

Explicitly defines when-to-use and when-not: it can only lower the current cap, and raising/removing the cap must instead be done by the user via the returned settings_url in the admin console. Also states the consequence of reaching the cap (no new sessions, no overage charges). Nothing 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 already indicate a non-read-only, open-world, non-idempotent, non-destructive call. The description adds behavior beyond that: utterances are queued and spoken sequentially, the call fails with session_not_connected if made before connection, and an admin-issued api_key is mandatory. It still does not describe return values 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 compact sentences with the core action first, then preconditions, then the auth requirement. No filler, though the error-code clause and the parenthetical auth note could be folded together.

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 3-required-parameter mutation tool with no output schema, the description covers the main things an agent needs: what happens, the required connection state, the failure code, and the auth requirement. Only 'session_id' semantics and response behavior are left unaddressed.

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%: 'text' and 'api_key' are documented in the schema, while 'session_id' has no description in either place. The description reinforces that api_key is an admin-issued key ('管理画面で発行したキー') and that a live session is implied, but adds no syntax or format detail beyond 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?

States a specific verb and resource: make the session's avatar speak given text. It also discloses the queueing behavior ('キューに積まれ、順に発話'), which is a meaningful detail. It does not explicitly differentiate from the sibling 'interrupt', which is the closest alternative.

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 precondition (call after the browser SDK connects via session.start) and the failure mode before connection (session_not_connected), plus the api_key requirement. It does not name a sibling alternative such as 'interrupt' for stopping speech, so it stops short of full when/when-not routing.

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