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

The annotations already declare destructiveHint=false, idempotentHint=true, and readOnlyHint=false, so the safety profile is known from structured data. The description adds genuine value by clarifying that cancelling does not delete posts that have already been executed, which is not derivable from the annotations and is consistent with them.

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 the boundary condition (does not delete executed posts) immediately following. No filler or redundant restatement.

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

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

An output schema exists, so return values need not be described, and the non-destructive behavior and idempotency are covered. The only material gap is the lack of guidance on schedule_id provenance and on when to choose cancellation over an alternative 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?

There is only one parameter (schedule_id) and the schema description coverage is 0%, so the description must compensate but does so only marginally by referring to 'the specified scheduled post'. It does not explain the format of the schedule_id or where to obtain it, leaving an agent to infer this from sibling tools.

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 (cancel the automatic execution of the specified scheduled post) and clarifies the scope of the action. It distinguishes the operation from sibling operations like list_scheduled_posts through the explicit cancel semantics, though it doesn't name a sibling or alternative directly.

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 enough context to infer that this tool is for scheduled posts that have not yet executed, and that previously executed posts are out of scope. However, it provides no explicit when-to-use vs alternatives routing, such as pointing to a delete or edit counterpart when a scheduled entry should be modified rather than cancelled.

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 a non-read-only, non-destructive, non-idempotent, open-world call; the description adds substantive context beyond that: it persists the key ('保存する') and explicitly notes the original device is not invalidated. That last clause is valuable disambiguation an agent could not derive from annotations alone.

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

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

Two compact sentences, front-loaded with the action and followed by the one caveat that matters. Nothing redundant.

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

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

An output schema exists, so return values need not be described, and with no parameters the description covers the essential mutation behavior and side-effect scope. Minor gap: it does not state prerequisites such as authentication state or what happens on key mismatch.

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

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

The tool takes zero parameters, so there is nothing semantic to explain and the baseline is 4. The description correctly focuses on behavior rather than arguments.

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?

Specifies the operation precisely: receive the key after smartphone approval, verify it against the registered key, and save it. A clear verb+resource chain. It does not explicitly distinguish itself from the sibling claim_key_transfer, so it stops short of a 5.

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

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

The phrase 'after smartphone-side approval' implies a precondition and timing for when to call it. However, it never names or contrasts with claim_key_transfer or the email-login siblings, so the agent must infer which transfer tool to use.

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=false, idempotentHint=false, openWorldHint=true and destructiveHint=false, so the mutation profile is partly covered. The description adds that the operation targets the caller's own existing key and originates from a device screen, but it never discloses that the code is presumably single-use/non-idempotent, what happens to the key on the source device, or what failure looks like for an expired or invalid code – material for a key-migration mutation.

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 sentence with no filler, where the code's origin is placed before the action it enables. Nothing is repeated from the schema or annotations and no clause could be cut without losing information.

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

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

An output schema exists, so return values need not be explained. However, for a security-relevant, non-idempotent key-transfer mutation in a suite that also offers check_key_transfer, the description omits the ordering with that sibling and any note on one-time codes or post-claim state, which an agent needs to sequence the call 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 0% and the only parameter is titled simply 'Code', so the description does the real explanatory work: it specifies the format (8 digits) and the exact source (the '別の端末に移行' screen on the smartphone), which is what an agent actually needs to source the value. It stops short of stating expiry, leading-zero handling, or whether the code is case/format-normalized.

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: requesting takeover of the user's existing encryption key (本人の既存暗号鍵の引き継ぎを要求する), and it pins the trigger to an 8-digit code shown on the phone's migration screen. That is enough to distinguish it in intent from the sibling check_key_transfer, though it never names that sibling explicitly, so the differentiation requires the agent to infer it from the wording.

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 only usage context given is the provenance of the code ('スマホの「別の端末に移行」に表示される8桁コード'), which implicitly tells the agent this is used during a device-migration flow. There is no explicit when-to-use, no exclusion, and no statement about whether check_key_transfer should be called first or when this should be avoided. Usage is implied rather than guided.

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 and non-destructive, so safety is covered. The description adds genuinely new behavioral information beyond them: it explicitly states that tokens and encryption keys are not returned, which sets expectations about the response payload. It does not say what happens on an invalid or expired login, which would have completed the picture.

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, zero waste, with the core action front-loaded and the output caveat second. Nothing could be removed without losing information.

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

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

With zero parameters, rich annotations, and an output schema present, the description only needs to frame intent and scope, which it does. The one gap is failure behavior (what an agent should infer from an authentication failure), which is relevant to a tool whose stated purpose is login verification.

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

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

The tool takes no parameters, so the schema leaves nothing undocumented and the baseline of 4 applies. The description correctly adds no parameter discussion, which is appropriate here.

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 (read one's own profile) plus the intent (verify login), which is more than a restated name. It is distinguishable from the login siblings (start_email_login, verify_email_login) by being a post-login profile read, though it does not name those siblings 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?

The phrase 'to verify login' implies when the tool is used (session/token validation), but there is no explicit guidance on when to prefer it over verify_email_login or get_status, and no stated preconditions. Usage is inferable rather than spelled out.

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, and closed-world behavior. The description adds meaningful context beyond them: this check happens without communicating, i.e. it is a local/offline status probe.

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, front-loaded with the core action and followed by the key alternative. There is no wasted text.

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 an output schema available, the description need not explain return values. It covers the local-only nature and the get_profile handoff, though it leaves 'settings' somewhat broad.

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?

There are zero parameters, so there is no parameter semantics to explain. The baseline for a no-parameter tool is 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?

The description names a specific verb (confirm/check) and concrete resources: settings, saved sessions, and key presence. It also distinguishes itself from the sibling get_profile by assigning validity checks to that tool.

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 clearly implies this is the tool for checking local status without network communication, and explicitly routes validity checks to get_profile. It does not enumerate when not to use it beyond that alternative, but the main selection 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, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered externally. The description adds only which fields are returned, which duplicates the output schema rather than adding new behavioral context such as result ordering, completeness, or pagination.

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 tight sentence with the resource front-loaded and no filler. It is efficient, though the terseness leaves no room for the usage or scope cues an agent would benefit from.

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 zero parameters, an output schema to explain return values, and rich annotations covering safety and openness, the description carries little burden. What it provides is sufficient, though a note on whether all collections are returned versus a paged subset would close the remaining 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?

The tool takes zero parameters, so there is nothing to disambiguate and the baseline is 4. The description correctly spends no space on parameter explanation.

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 gives a concrete verb (取得する) and a specific resource (投稿先), and enumerates the attributes returned (ID, name, participant count). It distinguishes itself reasonably from siblings like list_posts or list_scheduled_posts by focusing on destinations rather than content, though it never uses the term 'collection' that appears in the tool name.

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 guidance about when to call this versus get_profile, list_posts, or other listing tools, and no prerequisites or exclusions are stated. The agent must infer usage purely from the tool name and the field list.

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, open-world, and non-destructive behavior, so the bar is lower. The description adds useful behavioral context: results are newest-first, pagination uses next_cursor, and the maximum is 100 records.

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

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

Three short sentences with no wasted language. Ordering, pagination continuation, and the record cap are front-loaded and easy to scan.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. Still, for a five-parameter list tool at 0% schema description coverage, the description is incomplete regarding collection_id, timezone_name, and before_timestamp_ms.

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 0%, so the description must carry parameter meaning. It explains cursor and implies a limit cap, but it leaves the required collection_id and the timezone_name and before_timestamp_ms parameters unexplained.

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

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

The description states a clear verb and resource: retrieve posting history in newest-first order. It adds useful scope details such as maximum 100 records and cursor continuation, but it does not distinguish this tool from siblings like search_posts_by_date or list_scheduled_posts.

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 explains pagination usage by saying the returned next_cursor should be passed with the same conditions. However, it gives no guidance on when to choose list_posts versus related tools such as search_posts_by_date or list_scheduled_posts.

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 already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds the notable detail that results carry stop reasons and a worker's last-confirmation timestamp, which is genuinely useful context, but it says nothing about ordering, pagination, or what limit=100 implies.

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 no waste, and the primary purpose is front-loaded before the parameter hint. It is efficient, though the second sentence is purely parameter-level and could carry more routing information at the same length.

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

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

An output schema exists, so the return fields need not be spelled out, and the description does hint at them anyway. However, for a list tool with a default limit of 100 and no exclusions stated, an agent still can't tell how to page through results or how ordering works.

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 0%, so the description must compensate for both parameters. It explains include_finished (finished/cancelled included when true) but leaves limit completely undefined — no cap, no pagination, no ordering implications — leaving half the surface undocumented.

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 specific resources (予約一覧, 停止理由, ワーカーの最終確認日時), so an agent knows this returns the scheduled-post queue. It does not explicitly distinguish itself from siblings such as list_posts or search_posts_by_date, so the differentiation rests on the tool name 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?

The only usage guidance is the include_finished switch, which explains a parameter rather than when to call this tool versus alternatives. Nothing says when to prefer this over list_posts or search_posts_by_date, or how to pair it with cancel_scheduled_post.

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 disclose that this is not read-only, is not idempotent, is open-world, and is non-destructive. The description adds useful behavior beyond that by clarifying that no send occurs and that the result includes destination, body, and a preparation ID. It does not mention authorization needs or limits, but the annotation coverage lowers the burden.

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 packed sentences with the main action and the no-send constraint front-loaded. There is no redundant or filler text.

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 presence of an output schema means return values need not be fully explained, and the annotations cover safety characteristics. Still, for a three-parameter preparation tool with 0% schema description coverage, the unexplained required collection_id leaves the definition only partially 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 description coverage is 0%, so the description must carry parameter meaning. It clarifies that video_path must be an absolute MP4 path and that comment is optional, but the required collection_id parameter is never explained as an input, leaving a significant gap.

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-resource pair: preparing an MP4 at an absolute path with an optional comment. It also states what is returned and explicitly says it does not send, which distinguishes it from send_prepared_video.

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 '送信はしない' makes the preparation-only scope clear and implies that sending belongs to a sibling such as send_prepared_video. However, it does not explicitly compare against prepare_video_batch or state when batch preparation is preferable.

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

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

Annotations flag readOnlyHint=false and idempotentHint=false, and the description adds the critical behavioral facts annotations cannot convey: nothing is transmitted and the call returns each rendered body plus job_ids. That materially tells the agent this is a non-side-effecting-in-the-world preparation step whose output must be carried forward. It still omits what happens on partial validation failure across the batch.

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, no filler, and the most decision-relevant fact (batch of 1–50, does not send) is front-loaded. Nothing could be removed without losing information.

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

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

With an output schema present, the description is not obligated to detail return values, and it still summarizes them (bodies and job_ids). Combined with the batch limit, an agent has enough to call it correctly; only error/partial-failure behavior and the follow-up send step are left unstated.

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 schema itself documents each nested field (video_path as absolute MP4 path, collection_id, optional comment), so the description needn't repeat them. What the description adds beyond the schema is the 1–50 item bound on the videos array, which appears nowhere in the schema's constraints — a genuinely valuable addition for the sole 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 names a specific verb (まとめて準備する / prepare in batch) and its resource (videos, destinations, comments), plus the batch size range 1–50. This clearly separates it from the single-item prepare_video and from the sending tools, though it never names those siblings 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?

"送信せず" (does not send) implies the two-step prepare-then-send flow and rules this tool out as the sender, which is useful implied guidance. However, it never says to use send_prepared_videos/send_prepared_videos next, nor when to prefer prepare_video over the batch variant, so the agent must infer the sequencing.

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 cover the safety profile (readOnly=false, destructive=false, idempotent=false, openWorld=true), and the description adds genuinely new behavioral facts: a 1–50 item batch cap, timezone-aware future scheduling, and sequential delivery spaced by an optional interval. It does not describe failure handling or partial-batch behavior, which matters for a non-idempotent batch mutation.

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

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

Three short sentences, front-loaded with the action and cardinality, then timing, then the operational prerequisite. Every sentence adds information and none repeats the schema.

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 an output schema present and annotations declaring the mutation profile, the description supplies what structured fields don't: batch size, timezone-aware future timing, interval pacing, and the worker dependency. Remaining gaps are error/partial-failure semantics and the relationship to the cancel/list siblings.

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 0%, so the description must carry parameter meaning and largely does: job_ids is bounded to 1–50 prepared IDs, publish_at must be a future datetime with timezone, and interval_seconds controls the spacing between sequential sends. Format details (e.g. the exact datetime string format) are still unstated.

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 (予約する/schedule) and resource (準備ID / prepared video IDs) plus a concrete batch bound of 1–50, which distinguishes it from the immediate-send sibling send_prepared_videos. It never names that sibling explicitly, so the differentiation is inferable rather than stated.

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 future-datetime requirement implies this is for deferred publishing rather than immediate sending, and 'ワーカー必須' (worker required) is a real precondition. However, no alternative tool is named and there is no statement of when not to use it versus send_prepared_videos or how it relates to cancel_scheduled_post.

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 this as a safe, read-only, idempotent, non-destructive operation. The description adds useful behavioral detail beyond that: the end date is inclusive, the default boundary is Tokyo 4 AM, and setting 0 switches to calendar-day boundaries.

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 short, front-loaded, and every clause adds useful information: search scope, inclusive end date, default boundary, and the special 0 value. There is no wasted text.

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?

Output schema exists, so return values need not be explained. Annotations cover safety. But with seven parameters and no schema descriptions, the description is not fully complete: pagination via limit/cursor and the role of collection_id remain unspecified.

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

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

Schema description coverage is 0%, so the description must carry the burden. It meaningfully explains the date parameters and timezone/day-boundary behavior, but it does not explain collection_id, limit, or cursor semantics, leaving several parameters undocumented.

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: searching posts by a YYYY-MM-DD date range. It is clearly distinct from a general listing tool in concept, but it does not explicitly differentiate itself from sibling tools such as list_posts or list_scheduled_posts.

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 date-range nature implies when the tool is appropriate, and the inclusive end date is clarified. However, there is no explicit guidance on when to use this instead of list_posts or other sibling listing tools, so usage is only implied.

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 tool clarifies a specific operational behavior—the absence of automatic resending post-request—which is a key piece of behavioral transparency not covered by the provided safety or hint annotations. This helps agents manage post-call expectations.

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 definition is extremely concise, using two sentences where the first sentence captures the primary action and the second provides the crucial behavioral constraint with zero fluff.

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 only one required parameter, the definition is robust. It defines the action, the specific input required, and a major operational limitation, making it highly useful for correct tool 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?

Given the minimal input schema, the description adds crucial meaning by clarifying that 'job_id' refers to the 'preparation ID' (準備ID), helping the agent map the abstract parameter name to the necessary resource identifier.

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 is highly specific, stating it 'attaches the video' for a 'preparation ID.' This clearly distinguishes it from preparation steps or generic video upload tools within the posting workflow.

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 provides critical guidance on usage by specifying a behavioral constraint: 'Does not automatically resend after the post request.' This helps agents understand the tool's limitations relative to a hypothetical tool that might handle auto-resending.

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 readOnlyHint=false and destructiveHint=false, so safety is partially covered. The description adds genuinely useful behavior beyond annotations: it sends in order, stops subsequent sends on failure, and on re-execution skips already-sent items. This resume/stop-on-failure semantics is valuable operational context. One caveat: the 'skips already-sent' resume behavior is in mild tension with idempotentHint=false, but since unsent items still fire on re-run, the tool remains non-idempotent, so it is not a hard 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 tight sentences: the first front-loads the action, the second adds failure and resume semantics. No filler. Slightly vague in using '準備ID' without anchoring it to job_ids, but overall efficient and well-ordered.

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

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

An output schema exists, so return values need not be explained. Annotations cover the safety profile and the description covers ordering, failure-stop, and resume behavior. What remains under-specified is prerequisite state (must videos be prepared first) and per-item result reporting, but the core behavior an agent needs to call it 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?

The single parameter job_ids has 0% schema description coverage, so the description must compensate. It does clarify that these are '準備ID' (preparation IDs) and that they are processed in order, which gives meaning to the array. However it does not specify format, ordering constraints, batch limits, or whether duplicates are allowed, leaving meaningful gaps.

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 ('送信する' = send) and resource ('準備ID' / prepared videos) and adds that they are sent 'in order.' An agent can distinguish this batch-send tool from prepare_video. It does not explicitly differentiate it from the sibling singular send_prepared_video, but the plural name plus 'in order' clarifies the batch nature.

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 describes what happens during execution but gives no guidance on when to use this tool vs alternatives like send_prepared_video (singular) or prepare_video. There is no mention of prerequisites (e.g., videos must first be prepared) or conditions selecting this tool over siblings, so an agent must infer usage.

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 write-like, non-idempotent, open-world profile, so the bar is lower. The description usefully adds the actual side effect — an email with a confirmation code is dispatched — but says nothing about rate limits, code expiry, or what happens if the address is unregistered.

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 zero waste, and the primary action is front-loaded ahead of the backup-email qualifier.

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

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

An output schema exists, so return values need not be described, and both parameters are covered. The remaining gap is flow context — how this hands off to verify_email_login and whether the code expires — which an agent would find useful.

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 0%, so the description has to carry the load, and it does: it explains that 'email' is the target's registered address and that 'backup=true' selects the registered backup email. Both parameters get meaning beyond their bare titles.

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 and target: it sends a confirmation code to the specified person's registered email, and the second sentence clarifies the backup-email variant. This distinguishes it from the sibling verify_email_login by the start/verify naming, though the description never names that sibling 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?

There is no statement of when to call this versus verify_email_login, nor any prerequisites (e.g. that the email must already be registered). Usage is only inferable from the tool name and the word 'start'.

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 this is not read-only, is open-world, and is non-idempotent. The description adds meaningful behavioral context beyond those hints: it persists login information and encrypts it with DPAPI, which is exactly the type of side effect an agent needs to know about. It does not cover invalid-code behavior or whether retries are safe.

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 with no wasted wording. It front-loads the verification action and then states the persistence side effect.

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 login verification tool with annotations and an output schema, the description covers purpose and persistence adequately. However, it omits flow prerequisites such as whether start_email_login must be called first, and it says nothing about invalid or expired code handling.

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 schema has 0% description coverage for the single required parameter, so the description must compensate. It clarifies that 'code' is an email confirmation code received from the user, but does not specify format, length, expiration, or case sensitivity.

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 (verify) and resource (email login code), and also states the post-verification side effect of saving login information. It does not explicitly distinguish itself from the sibling start_email_login, so sibling differentiation is left implicit.

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 implies this is the next step after receiving an email confirmation code, but it never states when to use this tool versus start_email_login or other login-related siblings. There are no prerequisites or exclusion conditions 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 declare readOnlyHint=false, idempotentHint=true, destructiveHint=false and openWorldHint=true; the description usefully adds that it reads remote data back and then writes to local records, explaining the read-write hybrid. It does not say what happens on a verification mismatch or whether a failure leaves local state untouched.

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 front-loaded sentence with no filler; the verification fields and the local update are packed in without waste. Slightly dense at the expense of readability but structurally sound.

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

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

An output schema exists, so return values need not be explained, and annotations cover the safety profile. However, an idempotent mutating verification tool should clarify the job_id semantics and the outcome of a failed check; those gaps remain.

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 parameter job_id has 0% schema description coverage and the description never mentions it, so the agent must guess what identifier it refers to (a prepared video job? a sent post?). It cannot compensate for the schema gap.

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 operation: read back the post, reconcile ID/sender/destination/encryption format/storage location, then update local records. The verb+resource is clear enough to act on, though it doesn't distinguish itself from siblings like get_status or prepare_video.

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 indication of when this tool should be chosen over alternatives such as get_status or prepare_video, nor any preconditions (e.g., the job must already be sent). Usage must be inferred entirely from the name.

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