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

With no annotations, the description carries the full behavioral burden. It discloses the token prerequisite and module requirement, which are useful. However, it does not state whether the operation is reversible, what permissions are needed beyond the module, or what side effects occur — shortcomings for a mutation tool without annotation coverage.

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

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

Three short sentences, each earning its place, with the prerequisite front-loaded. 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 purpose and key usage conditions, and an output schema exists so return values need not be explained. But it leaves all four parameters without semantic guidance and omits side-effect details, creating clear gaps for a write operation with no annotations and 0% schema coverage.

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. It only indirectly references the token parameter by saying it comes from upload_attachment, and says nothing about project_id, filename, or description. The four parameters remain essentially 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?

States a specific verb and resource: registering an already-uploaded file to a project's Files module. It distinguishes itself from upload_attachment by specifying the token prerequisite, and notes the Documents module is not API-supported. However, it does not explicitly contrast with other file-related siblings like list_files or download_attachment.

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 clear prerequisites: first obtain a token via upload_attachment, and the files module must be enabled. It also indicates an alternative context by saying the Documents module is not API-supported, so use this instead. No explicit when-not-to-use case is given, but the conditions are sufficiently 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?

アノテーションがないため説明が全責任を負う。無効な tracker_id を Redmine が黙って別トラッカーに差し替えるという重要な挙動を開示しており、uploads の前提も述べている点は価値がある。しかし権限要件や作成の可逆性、失敗時の挙動には触れておらず、変異ツールとしての開示は不完全。

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?

目的を先頭に置き、その後に引数を簡潔に列挙する構造で無駄が少ない。引数説明は必要な粒度でまとまっており、冗長ではない。

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?

出力スキーマが存在するため戻り値の説明は不要。作成時の重要な注意点（トラッカーの差し替え、アップロードの前提）を網羅しており、9 パラメータのツールとして概ね完全。

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?

スキーマ説明カバレッジは 0% で 9 個のパラメータがあるため説明が補う必要がある。各引数に意味を与え、tracker_id の有効性制約、custom_fields と uploads の具体例、必須フラグまで明示しており、スキーマ以上の価値を提供している。

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?

「チケットを新規作成する」は明確な動詞+リソースで、update_issue や create_project などの兄弟ツールと混同しにくい。ただし、いつ使うべきかの兄弟ツールとの差別化には触れていない。

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?

明示的な when-to-use/when-not はないが、uploads には先に upload_attachment が必要、tracker_id は get_project で確認、priority_id/assigned_to_id は list_metadata で確認といった前提条件を埋め込んでいる。使用コンテキストは示唆されているが、代替ツールとの選択基準はない。

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 no annotations, the description carries the full behavioral burden. It usefully discloses the key behavioral trait that 'identifier' is immutable after creation (後から変更不可), plus defaults for is_public and a caveat that tracker_ids defaults are not 'all trackers'. However it says nothing about required permissions, error behavior, or side effects of creation.

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

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

Purpose is front-loaded in a single sentence, followed by a tight Args list with concrete examples. No filler or redundancy; the only minor cost is the two undocumented parameters that break the otherwise consistent list.

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 no explanation, and most parameters are described. But for a 7-param mutation tool with no annotations, it omits parent_id/description semantics and any mention of permissions or failure modes, leaving meaningful 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 0%, so the description must compensate, and it does: it documents name, identifier constraints (half-width lowercase/digits/hyphens, immutable), is_public default, enabled_module_names with example values, and tracker_ids behavior. Two params (parent_id, description) remain undocumented in both schema and description, which keeps it below a 5.

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 ('プロジェクトを新規作成する' = creates a new project), which cleanly separates it from read/update/delete siblings like get_project, update_project, and delete_project. It does not explicitly name those alternatives, so it stops short of full sibling differentiation.

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

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

There is no statement of when to use this tool versus alternatives, no prerequisites (e.g. required role/permissions to create a project), and no guidance on what happens on duplicate identifiers. Usage context is left entirely 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?

No annotations are provided, so the description must carry the full behavioral burden. It discloses that this creates a time entry and that spent_on defaults to today, but it does not describe permissions, side effects, reversibility, or what happens if both issue_id and project_id are supplied. For a mutation tool, this leaves significant gaps.

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 with the purpose, and then structured as an argument list. Each sentence and bullet adds practical 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?

An output schema exists, so return values need not be explained. However, this is a six-parameter mutation tool with no annotations and 0% schema description coverage, and the description omits comments entirely, leaves project_id only implicit, and provides no usage or safety context. It is therefore not complete enough for correct invocation in all cases.

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 explain all six parameters. It usefully explains hours, issue_id, activity_id, and spent_on, and mentions project_id as an alternative to issue_id, but it completely omits the comments parameter and does not give project_id its own clear argument description.

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

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

The description states a specific verb and resource: recording work time linked to a ticket or project. This clearly matches create_time_entry and distinguishes it from sibling tools like update_time_entry and list_time_entries, though it does not explicitly contrast itself with 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?

The description gives the core purpose and notes that issue_id or project_id is required, but it does not state when to use this tool versus update_time_entry, delete_time_entry, or list_time_entries. The only procedural hint is to check activity IDs via list_metadata, which is parameter guidance rather than usage guidance.

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

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

With no annotations, the description carries the full behavioral burden and does disclose the single most important trait: the deletion is irreversible (取り消し不可). However, it says nothing about permission/auth requirements, whether related objects (comments, attachments, time entries) are cascaded, or whether confirmation is needed for a destructive operation.

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 the destructive action front-loaded and the caveat in a parenthetical; no filler or redundant restatement of the tool 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?

An output schema exists, so return values need no explanation, and the irreversibility caveat is present. But for a destructive tool with zero annotation coverage, the absence of any cascade-effect, permission, or confirmation context leaves meaningful 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 0% for the single issue_id parameter, so the description would need to compensate. It never mentions the parameter, but 'issue_id' is self-explanatory from its name and type alone, so the practical cost is low. A baseline 3 reflects adequate-but-unadditive coverage.

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

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

The description names a specific verb (完全削除 - completely delete) and resource (チケット - ticket), and the scope qualifier '完全' distinguishes it from a soft-delete or status change. Combined with the tool name delete_issue, an agent can identify the operation at a glance.

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 steers the agent away from this tool in normal cases ('通常はステータス「却下」等を検討すること' - normally consider a 'rejected' status instead), which is real when-not-to-use guidance. It stops short of naming the specific sibling tool (update_issue) that performs that alternative.

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 no annotations provided, the description carries the full behavioral burden and does disclose the two most critical traits: that the deletion is total/cascading and irreversible (取り消し不可). It omits permission/auth requirements and whether any confirmation step exists, which are relevant for a destructive 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 compact sentence with the destructive scope and irreversibility front-loaded in a parenthetical. Zero waste, easy to scan before an irreversible operation.

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 the description adequately flags the destructive/cascading nature. It falls slightly short on permissions and confirmation context that an agent would want before an irreversible delete.

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 (project_id) at 0% schema description coverage, and the description never references it or clarifies its form. The schema supplies only the title, so the description fails to compensate for the coverage 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 verb (完全削除 - completely delete) and resource (プロジェクト - project), and clarifies cascade scope (tickets and Wiki also deleted). It does not, however, distinguish itself from siblings like delete_issue or delete_wiki_page beyond the obvious resource difference.

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 warns of the irreversible cascade effect but gives no guidance on when to use this versus alternatives (e.g., archiving, or individual deletes), states no prerequisites or confirmation expectations, and names no sibling tools.

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 no annotations provided, the description carries the full burden and successfully discloses the critical behavioral trait that the deletion is irreversible (取り消し不可). However, it does not mention permissions, whether the deletion is hard or soft, or any other side effects. Given the simplicity of the operation, disclosing irreversibility is the most important behavioral note, so a 4 is appropriate.

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, well-structured sentence that front-loads the action and appends the critical irreversibility warning. There is no wasted text, and it is appropriately sized for a simple delete tool.

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

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

The description covers the core purpose and the key behavioral trait (irreversibility), and an output schema exists so return values need not be explained. However, with 0% schema description coverage, the description should ideally explain what time_entry_id is or where to obtain it, and it lacks any usage context. It is minimally adequate but has clear 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 0%, so the description must compensate, but it provides no information about the single required parameter time_entry_id. While the parameter name itself is fairly self-explanatory, the description adds no meaning beyond what the schema's name and type already convey.

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 (削除する = delete) and a specific resource (作業時間の記録 = time entry record), clearly distinguishing it from sibling tools like create_time_entry, update_time_entry, and list_time_entries. An agent can immediately tell what the tool does 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 description provides no guidance on when to use this tool versus alternatives such as update_time_entry or delete_issue. It does not mention prerequisites, context, or exclusions. The only extra information is the irreversibility note, which is behavioral rather than usage guidance.

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

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

With no annotations, the description carries the full burden, and it does disclose the single most important trait: the deletion is irreversible. However, it omits other relevant behavior such as whether child/subpages are cascaded, permission or authorization requirements, and whether the action fails on a missing page — meaningful gaps for a destructive operation.

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 short sentence with zero filler, and the destructive warning is placed in-line at the end where it is visible. It is efficiently sized, though the terseness is partly the source of the missing behavioral detail.

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 no explanation, but for a destructive, unannotated tool with two fully undocumented parameters, the description is too thin. It does not cover permission needs, cascade effects, or how project_id and title jointly select the target.

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?

Both parameters (project_id, title) have 0% schema description coverage, so the description must compensate and does not. It never explains that the page is identified by exact title scoped to a specific project, nor whether title matching is case-sensitive or how duplicates are resolved.

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 (Wiki ページ), so an agent can tell it apart from read_wiki_page/list_wiki_pages/write_wiki_page in the sibling set. It does not explicitly name or contrast with those siblings, 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?

There is no statement of when to use this tool versus write_wiki_page or the other wiki siblings, and no prerequisites or preconditions (e.g. confirmation, project membership). The only guidance is the irreversibility warning, which is a caution rather than usage direction.

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 no annotations, the description carries the full behavioral burden. It usefully discloses the return encoding (text as-is, binary as base64) and truncation behavior when the size limit is exceeded. However, it says nothing about authorization requirements, error behavior for missing attachments, or what metadata accompanies the content.

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 that front-loads the core action (retrieve metadata and content) before the format and truncation details. No wasted words.

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 needn't be spelled out, and the tool is simple (2 params). Still, with zero annotation coverage and 0% parameter description coverage, the definition leaves the parameter contract and failure modes under-specified for an agent invoking it.

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. It obliquely explains the size-limit behavior ('上限超は本文省略'), which maps to max_bytes, but never names that parameter or its default, and says nothing about attachment_id. The two parameters remain largely undocumented in prose.

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: retrieves attachment metadata and content. This clearly distinguishes it from the sibling upload_attachment. It stops short of explicitly naming the sibling, but the download-vs-upload contrast is 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?

No guidance on when to use this tool versus alternatives, nor any prerequisites (permissions, whether the attachment must first be listed). The agent must infer usage 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.

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

No annotations are provided, so the description carries the full burden. It does disclose the rich payload (comments and attachments included), implying a read operation, but never states whether authentication or permissions are required, nor whether fetching is heavy — a meaningful gap for a tool returning comment history and attachments.

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 that front-loads the verb and resource, with the richest detail (comments, attachments) placed in a parenthetical. No waste, though it is terse to the point of being under-informative.

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 re-explained. For a one-parameter read tool this is close to adequate, but the lone parameter is undocumented and there is no positioning against the many sibling issue tools, leaving the definition minimally viable.

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% for the single required issue_id parameter, so the schema gives no semantics at all (only a bare integer type). The description does not mention issue_id, its format, or whether it is a ticket ID versus a database key, leaving the only parameter entirely 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?

States a specific verb (返す/return) and resource (チケット/ticket), and enumerates the payload scope (description, comment history, attachments). However, it does not distinguish itself from siblings like list_issues, update_issue, or delete_issue, so an agent gets no explicit routing signal.

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

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

There is no when-to-use or when-not-to-use guidance. With 23 sibling tools including list_issues and get_project, the description offers nothing about which to pick based on the agent's situation.

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 no annotations, the description carries the full behavioral burden. It makes clear this is a non-destructive read and discloses what the response contains, but says nothing about permissions, error behavior for a nonexistent/inaccessible project_id, or any 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?

Two short sentences with zero filler; the return scope leads and the usage condition follows. Well 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 spelled out further, and listing the key contents is a helpful extra. For a one-parameter read tool the definition is essentially complete, missing only parameter format detail and failure behavior.

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 project_id has 0% schema description coverage, and the description adds no information about its expected format (numeric ID vs. identifier/slug) or how to obtain it. The description does not compensate for the coverage 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 verb and resource ("プロジェクトの詳細を返す") and enumerates the payload scope (enabled trackers, modules, categories), which distinguishes it from list_projects and update_project. It stops short of naming a sibling tool explicitly, but the resource is 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?

Provides a concrete, actionable precondition: call this before creating a ticket to verify the tracker is enabled for the target project. That is clear when-to-use guidance, though it names no alternative tools for related lookups (e.g. list_metadata, list_projects).

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?

No annotations are provided, so the description carries the full burden. It implies a read-only listing but says nothing about pagination, ordering, permission requirements, or the fact that only a single project's files are returned — all relevant for a list endpoint. An output schema exists, but behavioral traits are still undisclosed.

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 no filler and the resource named up front. It is efficient, though arguably under-specified rather than optimally balanced.

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?

Because an output schema exists, return values need not be described. However, for a list tool with an undocumented required parameter and no behavioral notes, the description leaves gaps an agent must fill by trial or inference.

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% and the single required parameter project_id is undocumented in both schema and description. The description merely implies project scoping through the word プロジェクト but adds no format, constraint, or meaning beyond that.

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 (Files モジュール一覧), and names the module explicitly, so an agent can tell it apart from list_wiki_pages or list_issues. It does not, however, explicitly contrast itself with siblings like add_project_file or download_attachment.

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 on when to call this versus alternatives such as get_project or add_project_file, nor any stated prerequisites (e.g., the project must exist, permissions needed). Usage is only implied by the resource name.

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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose useful traits — default limit of 25, hard cap of 100, and the default status filter of 'open' — but says nothing about authentication, ordering, or pagination behavior, which matters for a listing endpoint.

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

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

Front-loads the purpose in one line, then gives a tight per-parameter list with no filler. The 'Args:' block is somewhat redundant in that it restates parameter names already visible in the schema, but the added value per line is high.

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

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

Given an output schema exists, return values need not be explained, and all input parameters are covered. The remaining gap is the absence of any comparative routing versus sibling list/search tools, plus no note on result ordering or pagination.

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 0% schema description coverage, the description fully compensates: it documents all five parameters, including accepted status_id values ('open'/'closed'/'*'/numeric ID), the 'me' shorthand for assigned_to_id, partial-match semantics for subject, and the limit default/max. This is meaning an agent could not derive from the bare 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 clear verb+resource ('チケット一覧を返す' — returns a list of tickets) with the filtering scope implied by the arg list. However, it does nothing to distinguish itself from siblings such as 'search' or 'get_issue', so an agent must infer the boundary.

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, no mention of when not to use it, and no routing to alternatives like 'search' or 'get_issue' for single-ticket lookups. The only usage hints are implicit parameter defaults (e.g. omitting project_id means all projects).

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?

No annotations are provided, so the description carries the full burden. It discloses that this is a bulk read of reference data (implying read-only, safe), but says nothing about permissions, caching, or volatility of the returned values. Adequate but thin for a no-annotation 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?

A single front-loaded sentence with no filler; the enumerations earn their place by telling the agent which reference categories to expect. Very efficient.

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

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

For a zero-parameter metadata lookup with an output schema present, the description needn't explain return values, and it does cover what categories are returned. Complete enough to call correctly, though a note on typical usage order (call before ID-based tools) would round it out.

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 document and the baseline of 4 applies. The description adds no parameter meaning because none is needed.

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

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

States a specific verb (返す/returns) and enumerates the resource types returned (tracker/status/priority/user/work classification), so an agent knows exactly what comes back. It doesn't explicitly differentiate itself from siblings, but the reference-data scope is distinct enough to be identifiable.

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『ID 指定に必要な参照情報』implies the tool should be called to obtain valid IDs before invoking ID-requiring tools, which is useful implied usage. However, it never states when to use it versus alternatives or gives explicit context/exclusions.

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

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

With no annotations, the description carries the full behavioral burden and discloses nothing beyond the read intent: no mention of pagination, result ordering, permission requirements, or project visibility scope. Only the implicit 'returns' wording signals it is non-mutating.

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 clause, front-loaded with the verb and resource and free of filler. It is efficient, though its brevity comes at the cost of the guidance and behavioral detail noted above.

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 value description is not required, and a zero-parameter list tool is simple enough that minimal text is survivable. Still, the absence of any usage or pagination context leaves it only marginally 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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to compensate for. No parameter syntax or format needs explaining.

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 ('Redmine のプロジェクト一覧を返す') and clearly distinguishes itself from the singular get_project sibling. It does not, however, contrast itself with create_project/update_project/delete_project or note list scope such as filtering.

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

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

No when-to-use guidance at all: nothing says to prefer this over get_project for a single project, or whether it should be combined with list_issues. The agent must infer usage from the name alone.

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?

No annotations are provided, so the description carries the full behavioral burden, yet it says nothing about permissions, whether results are paginated (the limit default of 25 is never mentioned), or result ordering. It discloses only that filtering is available, which is thin for a 6-parameter read 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 short and front-loaded, leading with the core action before the argument notes. It is well sized for the task, though the Args block is only partially complete rather than verbose.

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 6 parameters at 0% schema coverage and no annotations, the description should do more heavy lifting; instead it covers only half the parameters and omits pagination behavior entirely. The presence of an output schema excuses it from describing return values, but the input-side 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?

Schema description coverage is 0%, and the description documents only 3 of 6 parameters (user_id, from_date, to_date), omitting limit, issue_id, and project_id entirely. It does add useful format details ('me' sentinel value, YYYY-MM-DD), but half the parameters remain undocumented in both schema and description.

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

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

The description states a specific verb and resource ('作業時間の一覧を返す' = returns a list of time entries), which clearly distinguishes it from the mutation siblings create/update/delete_time_entry. It does not explicitly name or contrast with any alternative, but the list-vs-mutate distinction is inherent and 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?

The parenthetical '(フィルタ可)' merely notes that filtering is possible; it gives no guidance on when to use this tool versus other list tools (list_issues, list_projects) or when filters are required. No prerequisites, exclusions, or conditions are 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?

No annotations are provided, so the description carries the full disclosure burden, yet it says nothing about pagination, ordering, permissions required, or whether the listing is filtered. It only restates the read operation implied by the tool name, leaving behavioral traits undocumented.

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 short sentence is front-loaded and free of padding, but the brevity here reflects under-specification rather than efficient information density. For a tool with an undocumented parameter and no annotations, more content was warranted.

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 output schema exists, so return values need not be explained, but the definition still omits basic list-tool context such as pagination or result ordering. Given zero annotation and zero schema-description coverage, the description is too thin to call the tool correctly with confidence.

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 0% schema description coverage, the description must compensate but barely does: 'プロジェクトの' only indirectly signals that project_id scopes the result. It adds no format hints, no indication of which project identifier form is expected, and no eligibility constraints.

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 ('Wiki ページ一覧を返す' – returns a list of Wiki pages) and scopes it to a project, so the agent knows exactly what operation this is. However, it makes no attempt to distinguish itself from the closely related siblings read_wiki_page, write_wiki_page, and delete_wiki_page.

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

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

There is no when-to-use guidance, no mention of the alternative Wiki tools, and no stated preconditions (e.g. that the project must exist). The agent must infer usage purely from the name.

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 no annotations, the description carries the full burden. It implies a read but says nothing about permissions, behavior when the page or project does not exist, or any rate limits. Only the minimal fact that it returns page body text is conveyed.

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 short sentence with no wasted words, but it is terse to the point of under-specification rather than well-sized. Front-loaded and readable, just thin.

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 format need not be described, but for a two-parameter tool with 0% schema coverage and no annotations, the description leaves the agent without parameter meaning, prerequisites, or error behavior.

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 schema documents nothing about project_id or title. The description mentions neither parameter, offering no added meaning; only the self-evident names of the parameters carry any signal.

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 — returning the body of a Wiki page — which is more than a restatement of the name. It is clear what operation is performed, though it does not differentiate from siblings like list_wiki_pages or write_wiki_page.

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 on when to use this tool versus the other wiki tools (list_wiki_pages, write_wiki_page, delete_wiki_page). No prerequisites, no context for the intended scenario.

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?

No annotations are provided, so the description carries the full behavioral burden, yet it only names the content scope searched. It says nothing about result counts/pagination (the 25 default limit), permissions, or that the operation is read-only, all of which matter for a mutation-ambiguous tool with zero annotation coverage.

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

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

A single front-loaded sentence with no wasted words. It is efficient, though the brevity reflects under-specification rather than true conciseness.

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, but the rest is thin: 0% parameter coverage, no annotations, and unstated limit/pagination behavior. For a search tool spanning all content types, an agent is missing key invocation context.

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 would need to compensate for two undocumented parameters. It hints that a query exists via '全文検索' but adds no syntax, matching behavior, or scope for 'query', and never addresses the 'limit' parameter at all.

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 (full-text search) and resource (all of Redmine), with concrete scope examples (tickets, Wiki, news). However it does not distinguish itself from cross-cutting siblings like list_issues or list_wiki_pages, which a full-scope search overlaps with.

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

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

There is no when-to-use or when-not-to-use guidance and no mention of alternatives. The agent is left to infer that this is the right tool when it wants cross-content search rather than a scoped list call.

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 no annotations, the description carries the full burden, and it discloses a genuinely important trait: Redmine silently discards invalid custom_field values while still returning 204, so the caller should re-verify with get_issue. It also makes the uploads ordering dependency explicit. It stops short of covering permissions, reversibility, or the behavior of the remaining unlisted 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?

The purpose and the comment shortcut are front-loaded in one line, then a structured Args block follows. It is compact with no filler, though the mixed purpose-plus-parameter-prose format is slightly less front-loaded than ideal.

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 10-parameter mutation tool with no annotations and an output schema already covering returns, the description covers the tricky parameters well but omits 4 of them and says nothing about required permissions or whether changes are reversible. Adequate but with clear 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 0%, so the description must carry everything, and it documents 6 of 10 parameters with real semantics: status_id is a numeric ID to look up in list_metadata, done_ratio is 0-100, and custom_fields/uploads get concrete JSON shape examples plus a call-order note. subject, description, priority_id and assigned_to_id are left entirely undefined, which is the 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 opening line states a specific verb + resource ('チケットを更新する' / update a ticket), which clearly distinguishes it from siblings like create_issue, get_issue and delete_issue by operation. It does not, however, explicitly name any sibling or scoping distinction the way a top-tier definition would.

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

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

It gives a real usage hint for one case ('to add a comment, just pass notes') and points to prerequisites for two parameters (list_metadata for status_id, upload_attachment before uploads). It never states when to choose this over update_time_entry or update_project, or when not to use it, so selection guidance is only partial.

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 no annotations, the description carries the full burden. It does disclose one genuinely important behavior — that enabled_module_names and tracker_ids are replaced wholesale rather than merged — which is real value beyond the schema. However, it omits permission requirements, reversibility, and whether unlisted fields are left unchanged.

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 the critical replacement caveat front-loaded in parentheses. Efficient and quick to scan, though extremely terse.

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, but for a 7-parameter mutation tool with no annotations this description is thin: five parameters are undocumented and no permission or side-effect context is given. The replacement note helps but leaves the definition substantially incomplete.

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% for 7 parameters. The description adds meaningful semantics (full-replacement) for only 2 of them (enabled_module_names, tracker_ids) and says nothing about name, is_public, parent_id, project_id, or description. With low coverage it must compensate broadly but only does so for a fraction.

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 ('プロジェクトを更新する' / update a project), which is unambiguous against siblings like create_project, delete_project, and get_project. It stops short of explicit sibling differentiation, so it lands at 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?

There is no when-to-use guidance, no prerequisites, and no routing to alternatives. The parenthetical is a behavioral caveat, not usage guidance, so the agent gets no explicit signal about when this is the right 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?

No annotations are provided, so the description carries the full behavioral burden. It implies a mutation ('修正する') but says nothing about required permissions, partial-update semantics, or reversibility, leaving the agent without the context needed for a write operation.

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?

It is a single front-loaded sentence with no filler, which is structurally clean. But it is under-specified rather than concise, packing no actionable detail into its 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?

An output schema exists so return values need not be explained, but for a 5-parameter mutation with zero annotation coverage and zero schema description coverage, the description leaves the agent without parameter meaning, update semantics, or usage context.

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?

Five parameters exist at 0% schema description coverage, and the description mentions none of them (hours, comments, spent_on, activity_id, time_entry_id). It provides no compensating semantics, which is worse than the calibration baseline for fully undocumented parameters.

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 (修正する / modify) and resource (作業時間の記録 / time entry record), so the action is unambiguous. However, it offers no differentiation from the sibling mutation tools create_time_entry and delete_time_entry, which the rubric places at a 4.

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 on when to use this tool versus create_time_entry, delete_time_entry, or list_time_entries, and no prerequisites or conditions are stated. The agent must infer usage from the name alone.

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?

No annotations are provided, so the description carries the full burden. It discloses the non-obvious two-step token workflow, the token expiry behavior, and the encoding contract for content. It omits auth requirements and size/type limits, but the token lifecycle disclosure is exactly the kind of behavior an agent cannot infer.

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 lines, front-loaded with the action and result, then downstream usage, then encoding rules. No filler sentences; every clause carries distinct 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-value details need not be repeated, and the description already flags that the return is a token. Combined with the downstream-consumer mapping and expiry note, this is sufficient for correct invocation, with only secondary gaps (auth, limits, param exclusivity).

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, and it does: it tells the agent to use content_text for text and content_base64 for binary, which is real semantic guidance beyond the bare schema titles. It does not clarify mutual exclusivity or what happens if both/neither are supplied, and filename gets no 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?

States a specific verb and resource (upload a file to Redmine) and an unusual outcome (obtain a token), then names the exact sibling tools that consume that token. An agent can distinguish this two-step upload flow from add_project_file or create_issue 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?

Explicitly says the resulting token is consumed by create_issue/update_issue uploads or add_project_file, and warns that unused tokens expire after a period. It gives clear context for when this tool is a prerequisite, but does not state when to prefer this over add_project_file (which appears to be a one-step alternative) or any preconditions.

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 no annotations, the description carries the full behavioral burden. It does disclose the most important trait — that an existing page is silently overwritten — which is genuine data-loss context. However it omits edit-permission requirements, what happens to sub-pages or attachments, and any conflict/version behavior on a mutation 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?

Very compact, with the upsert scope front-loaded in the first sentence and the Args block kept short. The Args lines do restate the schema, but the added format/comment semantics justify their presence rather than pure duplication.

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. For a mutation tool with zero annotations the description is only partly complete: it covers the overwrite semantics but leaves permissions, prerequisites, and side effects on non-text content 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 description coverage is 0%, so the description must compensate. It adds real meaning for two params — text follows the project's Textile/Markdown configuration, and comments is the revision message — but says nothing about project_id or title beyond their obvious names. Partial compensation for the coverage 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 names a specific verb+resource ('Wiki ページを作成または更新する') and resolves the create-vs-update ambiguity with '(存在しなければ作成、あれば上書き)', which is meaningful because the tool name alone can't tell an agent whether it upserts or fails on collision. It implicitly separates itself from the read/list/delete wiki siblings, but never names them 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 when-to-use or when-not-to-use guidance and no mention of alternatives such as read_wiki_page (to inspect before overwriting) or delete_wiki_page. The upsert behavior is stated as a fact, not as guidance about when overwriting is appropriate versus when the agent should avoid a blind write.

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