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

With no annotations, the description carries the full burden and largely succeeds: it discloses that the feed is synthesized across REST endpoints, merged by timestamp, and that a single failed source never fails the feed (errors surface per-source in 'sources'). It does not mention auth requirements, rate limits, or whether 'truncated' implies pagination continuation.

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 one-line purpose and the design rationale before diving into Args and Returns. It is on the longer side, but given 0% schema coverage and a complex aggregation behavior, nearly every sentence earns its place.

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

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

Complete for a complex aggregation tool: it explains what is returned (project, bounds, count, truncated, events, sources), documents the event shape, and covers the partial-failure edge case. An output schema also exists, so return-value explanation is a bonus rather than a gap.

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

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

Schema coverage is 0%, so the description must compensate, and it does for every parameter: project (id or slug), from_date/to_date inclusive YYYY-MM-DD, activity_types subset with empty=all and list-or-CSV acceptance, limit 1-500, and max_per_source as the pre-merge per-source row cap. This adds real meaning far beyond 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 specific verb+resource: it 'synthesizes the feed' from per-resource REST endpoints and 'merges the events by timestamp' for recent project activity across issues, news, wiki, forums, time and files. This is clearly distinguishable from the per-resource siblings like redmine_list_news or redmine_list_time_entries because it produces a merged cross-resource timeline.

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?

Explains a strong usage rationale: Redmine's native /projects/:id/activity endpoint is not API-usable, so this tool exists to provide that aggregate view. However, it does not explicitly contrast when to prefer this merged feed over the individual per-resource list tools, leaving that routing decision 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?

With no annotations, the description carries the full burden and does so richly: empty notes rejected client-side, backslash-n stored literally, Markdown rendering rules, private visibility gated by the view_private_notes permission, REDMINE_MCP_READ_ONLY honored, and quiet-mode output reduction. These are exactly the mutating-operation and permission traits an agent needs.

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 the first line, then Args and behavioral notes follow in a logical order. The content is dense but nearly every sentence adds actionable detail; slightly verbose in the newline/Markdown guidance but justified by the 0% schema coverage.

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, return values need not be described, and the quiet-mode note still covers output shape. The description is complete across params, permissions, environment flags, and side effects for a 4-param mutation tool with no annotations.

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 for all four parameters: issue_id (numeric Redmine id), note (empty rejected, newline and Markdown conventions), private (view_private_notes permission), and quiet (reduced ids+status output). This is meaning well beyond the bare type/title schema.

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

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

States a specific verb and resource ('Append a comment (journal entry) to an existing issue') and immediately distinguishes itself from status-changing siblings ('comments don't change status'). An agent can tell this apart from redmine_update_journal or redmine_close_issue without opening a 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?

Implicitly contextualizes usage by noting it is a direct PUT with no pre-fetch or workflow check, and describes the private/quiet options. However, it never routes the agent explicitly to alternatives (e.g., redmine_update_journal for editing an existing note) or states when-not to use this tool. Usage is implied 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?

The description mentions it honors REDMINE_MCP_READ_ONLY, which provides a behavioral constraint. However, with no annotations provided, the description should disclose more, such as permissions required, side effects, or error conditions. The read-only note is helpful but insufficient.

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 very concise at two sentences, with no unnecessary words. The purpose is front-loaded, and the behavioral note follows efficiently.

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

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

With a simple tool and an output schema, the description need not explain return values, but it lacks essential context such as how to obtain valid user_id and group_id, and whether adding a duplicate user causes an error. The zero schema coverage and missing usage guidance make it 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 description coverage is 0%, so the description must explain the parameters. It does not define user_id or group_id, leaving the agent without context on what values to provide or where to find them.

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

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

The description clearly states 'Add a user to a group,' which is a specific verb and resource. This distinguishes it from sibling tools like redmine_remove_group_user and redmine_create_group.

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 alternatives. No mention of prerequisites (e.g., whether the group and user must exist) or when not to use it.

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

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

With no annotations provided, the description carries full burden. It mentions the read-only flag but does not disclose other behavioral traits such as whether the action is reversible, error handling, or side effects beyond basic 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?

The description is extremely concise: one sentence for purpose, then a compact args list, and one line for the read-only flag. Every sentence adds value with no redundancy.

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

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

Given no annotations and the presence of an output schema, the description covers purpose, parameters, and a behavioral constraint. However, it does not describe return values or error conditions, leaving some gaps for a mutation tool.

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 compensates by explaining each parameter: project_id (id or slug), user_id (user or group id), role_ids (list of role ids, required non-empty). This adds meaningful context beyond the schema's type-only fields.

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 'Add a member to a project,' which is a clear, specific verb+resource. It distinguishes from siblings like redmine_remove_membership and redmine_update_membership.

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 includes parameter requirements (role_ids is required and non-empty) and notes the REDMINE_MCP_READ_ONLY constraint, but it does not provide guidance on when to use this tool versus alternatives like redmine_add_group_user.

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 reveals that the tool honors a read-only flag and that the delay parameter is only meaningful for certain relation types. This gives good insight into behavior, though it omits details on failure modes or idempotency.

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 structured with clear parameter explanations and uses bullet-like formatting. It is slightly verbose due to the extensive listing of relation types, but every sentence adds necessary 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?

Given the presence of an output schema, return values are covered. Parameters are thoroughly explained. However, common error conditions and authentication requirements are not mentioned, which would be helpful for completeness.

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

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

The input schema has 0% description coverage, yet the description explains each parameter in depth: issue_id, target_issue_id, relation_type with a full list of valid values and aliases, and delay with its specific meaning for precedes/follows. This adds substantial value beyond the schema.

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

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

The description clearly states 'Create a relation between two issues' and specifies the source issue, target issue, relation type, and delay. This distinguishes it from sibling tools like redmine_remove_relation.

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 context by mentioning that it honors REDMINE_MCP_READ_ONLY and that cross-project relations require a specific Redmine setting. However, it does not explicitly state when not to use this tool vs alternatives like redmine_set_parent_issue.

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

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

The description reveals that the tool is idempotent on the Redmine side and honors the REDMINE_MCP_READ_ONLY flag. Since no annotations are provided, this behavioral information is valuable and goes beyond what the schema offers.

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 extremely concise and well-structured: a clear one-sentence purpose, blank line, then parameter descriptions and additional behavioral notes. Every sentence adds value without unnecessary verbosity.

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

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

For a simple two-parameter tool, the description covers purpose, parameters, idempotency, and read-only behavior. With an output schema present, return values are not needed. However, it does not mention error behavior (e.g., if issue not found) or authentication requirements.

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

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

The description clearly explains both parameters: 'issue_id' as 'numeric Redmine issue id' and 'user_id' as 'numeric user id to add to the watcher list'. This adds meaning beyond the schema's titles and compensates for the 0% schema description 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 clearly states 'Add a user as a watcher of an issue', specifying the verb 'add', the resource 'watcher', and the context 'issue'. This distinguishes it from sibling tools like 'remove_watcher' and 'list_watchers'.

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 mentions idempotency and read-only mode but does not provide explicit guidance on when to use this tool versus alternatives. It relies on the name and basic description to imply usage context. No 'when not to use' or alternatives listed.

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 provided. The description discloses reversibility and honors read-only flag, but does not detail side effects or data changes.

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

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

Concise: two sentences for purpose and parameter, no unnecessary 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?

Adequate for a one-parameter tool with output schema. Covers version, reversibility, and a configuration note.

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%, so description compensates by specifying 'numeric id or identifier slug' for project_id, adding meaning beyond the string type.

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

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

The description clearly states the tool archives a project, specifies the Redmine version (5.0+), and notes reversibility. It distinguishes from siblings like 'delete' or 'unarchive'.

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?

Mentions reversibility and the read-only flag, but does not explicitly provide when-to-use vs alternatives or prerequisites.

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 bears the full burden. It discloses that the tool is a thin wrapper over `redmine_update_issue` and honors a read-only flag. It does not describe any side effects, permissions required, or the return value (though output schema exists). The disclosure is adequate but could be more comprehensive.

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 very concise, using a structured format with Args section. Every sentence adds value: defining the action, explaining parameters, noting the wrapper relationship, and mentioning the read-only flag. No redundancy or 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?

Given the simplicity of the tool (2 params) and the presence of an output schema (not shown), the description covers the essential behavior: assignment, clearing, wrapper context, and read-only respect. It could additionally mention error conditions or expected output, but overall it is sufficiently 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 input schema has 0% description coverage, so the description must compensate. It clarifies both parameters: `issue_id` is numeric, `version_id` is numeric and passing 0 clears the version. This adds essential meaning beyond the schema's type/title. It does not explain where to find `issue_id` or `version_id`, but the context is sufficient.

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

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

The description clearly states the action: 'Assign (or clear) an issue's target version.' It specifies the resource (issue) and the field (target version). It also distinguishes itself from the sibling tool `redmine_update_issue` by noting it's a thin wrapper that specifically sets `fixed_version_id`.

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

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

The description explains when to pass `version_id` as 0 to clear the version, and notes that it honors `REDMINE_MCP_READ_ONLY`, indicating a read-only mode. However, it does not explicitly state when this tool should be used over the more general `redmine_update_issue` or when not to use it.

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

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

No annotations provided, so description must cover behavioral traits. It explains stop_on_error behavior and honors REDMINE_MCP_READ_ONLY flag, indicating read-only mode may prevent changes. Describes return format. Missing details on destructive nature or permanence.

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?

Description is short, well-structured with Args and returns. Every sentence adds value. No unnecessary 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?

Given 3 parameters and an output schema, the description covers core behavior, input constraints, error handling, and read-only awareness. Enough for an agent to use 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 has 0% description coverage. Description adds meaning for all parameters: issue_ids (list of numeric IDs, ≤100), note (optional shared comment), stop_on_error (halt on failures). This compensates fully 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?

Description clearly states the action (close), the resource (issues), and the scope (many in one call). It distinguishes from sibling tools like redmine_close_issue (single) and redmine_bulk_update_issues (different action).

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?

Implied usage for bulk closing issues with optional notes and error handling. Mentions limit of ≤100 IDs per call. Lacks explicit when-not-to-use, but 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?

With no annotations available, the description carries the full behavioral burden and does so extensively: it explains duplicate pre-check semantics, rate-limit pacing rationale, stop-on-error destinations, concurrency mutual exclusion with pacing, 5xx batch aborts, read-only environment honoring, and quiet-mode return reduction.

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 long but appropriately so for a six-parameter bulk operation with complex concurrency and idempotency semantics. It is front-loaded with the core purpose and then structured into Args and Returns sections, with every sentence conveying operational 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?

Given no annotations, six parameters, 0% schema description coverage, and an output schema, the description is complete: it covers purpose, parameter semantics, return summary, error handling, pacing, concurrency interactions, and environment restrictions. Nothing essential for correct invocation appears missing.

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

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

Schema description coverage is 0%, so the description must compensate, and it does so fully: it documents all six parameters, required issue spec fields, allowed duplicate modes, pacing behavior, concurrency constraints, and quiet-mode effects. This is far beyond what the schema provides.

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 starts with a specific verb and resource: 'Bulk-create issues with subject idempotency.' It immediately distinguishes this tool from single-issue creation and bulk updates by emphasizing bulk creation and the subject-based idempotency mechanism.

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 makes clear this is for bulk creation with detailed duplicate-handling modes and a maximum of 100 issues per call. It references redmine_create_issue for matching optional fields, but it does not explicitly state when to prefer this tool over single-issue creation or when not to use it.

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

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

With no annotations, the description carries the burden well: it discloses the per-issue rate cap and how pacing_seconds addresses it, that 0 disables pacing, how stop_on_error truncates the run and surfaces skipped_for_stop_on_error, and that REDMINE_MCP_READ_ONLY is honored. It does not state whether already-created entries are rolled back on failure or what permissions are required beyond the read-only flag.

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

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

Front-loaded with the purpose, then parameter docs, then return shape — everything earns its place. The Returns sentence is mildly redundant given an output schema exists, but it is short.

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?

Covers params, pacing behavior, failure semantics and env-var gating for a multi-write tool, and the return structure is at least summarised. Missing only transactional/atomicity guarantees and permission requirements, which an agent would need before a large batch write.

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 fully compensates: it defines all three params including types, the 50ms default and the 0-disables sentinel for pacing_seconds, plus the ``hours`` required field. The nested dict schema is delegated to redmine_create_time_entry rather than spelled out, which leaves a small 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 with scope: "Create several time entries in one call (≤ 100)." The batch framing plus the 100-item cap separates it from the singular redmine_create_time_entry without requiring a schema read.

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

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

Gives clear qualifying context: batch creation, hard cap of 100, and the fields mirror redmine_create_time_entry. It does not explicitly say to prefer redmine_create_time_entry for a single entry or what to do past the 100 cap, so it falls short of naming alternatives and 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 provided, the description carries the full burden and does so thoroughly: stop_on_error vs. best-effort with unstarted ids landing in 'skipped', concurrency fan-out via a bounded semaphore, a 5xx aborting the batch, empty-vs-unchanged semantics for 'held' and done_ratio=-1, the reason-string requirement that rejects booleans with held_reason_required, the clear_held/held mutual exclusion, and honoring REDMINE_MCP_READ_ONLY. These are exactly the mutation, partial-failure, and auth behaviors an agent needs and cannot derive from the schema.

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

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

Front-loaded with a one-line summary followed by an Args block, and given 17 parameters the length is largely justified. A few lines are verbose (the held rationale spans multiple clauses) but each sentence carries operational information rather than filler.

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

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

For a complex bulk mutation with no annotations and a 0%-coverage schema, this is complete: partial-failure handling, concurrency semantics, error/abort behavior, read-only env gating, and the note that Redmine has no batch endpoint are all present. The return shape is restated and an output schema exists, so nothing an agent needs to call it correctly is missing.

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

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

Schema description coverage is 0% across 17 parameters, so the description must compensate and does: it caps issue_ids at 100, gives custom_fields the {'id': N, 'value': '...'} shape, enumerates difficulty values, documents default-equivalents (held empty = unchanged, done_ratio -1 = unchanged), and explains the date params. Nearly every parameter receives meaning beyond its bare type.

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 sentence states a specific verb and resource with scope: 'Apply the same field updates to many issues in one call.' This cleanly distinguishes it from the single-issue sibling redmine_update_issue and from redmine_bulk_create_issues without the agent needing to open 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?

The bulk framing implies when to reach for it over redmine_update_issue, and it anchors semantics by referencing that sibling ('same semantics as redmine_update_issue'). It also states the precondition that at least one updatable field must be supplied. It stops short of an explicit 'use X for one issue, Y for many' routing sentence, so it is clear context rather than explicit alternatives.

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 does so well: it discloses the default status id, that the note becomes a journal entry rendered as Markdown, that workflow-disallowed closures return a repackaged response with allowed next states, that REDMINE_MCP_READ_ONLY is honored, and exactly how quiet=True changes the result (ids+status, compact bulk rows; errors never reduced). These are behaviors an agent cannot get from the schema.

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

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

Front-loads the core action, then args, then edge-case behavior; every block is scannable and earns its place, including the newline-escape warning. Mild redundancy between the Args block and the later quiet paragraph keeps it from being maximally tight.

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-shape explanation is not required, yet the description still explains the quiet-mode reduction and the error path. Combined with the workflow-disallowed and read-only disclosures, an agent has everything needed to invoke this correctly without opening other tools.

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 titles are bare, so the description must compensate and largely does: it defines issue_id as a numeric Redmine issue id, note as an optional journal comment with a concrete newline-escape warning and formatting semantics, and quiet as an output-shaping switch. Only quiet's 'bulk' phrasing is slightly ambiguous for a single-issue tool, but coverage is far beyond baseline.

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

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

States a specific verb and resource ('Move an issue to its first is_closed status') and even pins the default target status id 5, which is more precise than a generic 'close issue'. It does not differentiate itself from sibling mutation tools like redmine_update_issue or redmine_bulk_close, so an agent must infer the boundary from the 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?

Usage context is implied: close a single issue, optionally with a journal comment. There is no explicit guidance on when to prefer this over redmine_update_issue (status change) or redmine_bulk_close (multiple issues), and no prerequisite/ordering advice. Adequate but leaves the routing decision 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?

With no annotations, the description carries the full behavioral burden and does so well: it discloses the read-and-create reconstruction strategy, replay of links afterward, depth-capped subtask copying, and that REDMINE_MCP_READ_ONLY is honored. This is unusually transparent for a mutation 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?

Front-loads the purpose in one line, then uses structured Args and Returns sections. Given 14 undocumented parameters, the length is justified and every sentence conveys operational or argument semantics.

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?

Despite having no annotations and 0% schema descriptions, the description covers purpose, implementation approach, parameter defaults, side effects, and read-only behavior. The return summary is technically redundant with the output schema but remains useful and does not detract.

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% across 14 parameters, so the description must supply all semantics. It documents every parameter and default behavior, including empty project/tracker meaning inherit, omitted overrides inheriting from source, and empty subject becoming 'Copy of <source>'.

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 ('Duplicate an issue') and scopes the operation to optional field overrides and link copies. This clearly distinguishes it from sibling tools like redmine_create_issue, which create new issues rather than reconstructing an existing one.

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?

Implies usage when an issue needs duplicating and explains the implementation constraint (no REST copy endpoint). However, it does not explicitly compare this tool to alternatives such as redmine_create_issue or state when not to use it, leaving the choice of tool 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?

Description adds 'Honors REDMINE_MCP_READ_ONLY' and 'admin only', which are behavioral traits. However, it does not disclose error handling, idempotency, or return behavior. No annotations exist to supplement.

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 concise: one sentence description plus bullet list of arguments. No unnecessary 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?

Given low complexity and existence of output schema, description covers permissions, parameters, and a behavioral flag. Missing error handling but sufficient for a simple create tool.

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 has 0% description coverage. Description clarifies that 'name' is required and 'user_ids' is an optional list of initial members, adding meaning beyond the schema types.

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

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

Description clearly states 'Create a group' with verb and resource, and 'admin only' adds scope. Distinguishes from sibling tools like redmine_update_group or redmine_delete_group.

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?

Implies usage when creating a new group (admin only), but lacks explicit alternatives or when-not-to-use instructions. No mention of when to use redmine_update_group instead.

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 behavioral burden and mostly delivers: it discloses REDMINE_MCP_READ_ONLY honoring, that held issues cannot be closed, that difficulty silently no-ops on fleets lacking the field, and that quiet reduces success output while errors are never reduced. It omits auth/permission requirements, which would complete the picture for a write 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 long but front-loaded and organized as an Args block, with each entry earning its place given the 15 undocumented parameters. The one structural flaw is that quiet is explained in a trailing paragraph rather than in the Args list, breaking the established pattern.

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 15-parameter mutation tool at 0% schema coverage, the description is unusually complete: every parameter is addressed, mutation side effects (read-only mode, held-cannot-close) are disclosed, and failure behavior ('structured validation error', errors never reduced) is stated. Since an output schema exists, return values need not be re-described.

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

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

Schema description coverage is 0%, so the description must carry all parameter meaning, and it does: sentinel semantics (done_ratio -1 vs 0, assigned_to_id 0 = unassigned), format examples (ISO-8601 dates, id-or-slug for project/tracker), the constraint that held must be a reason string not a bare flag, the independence of held vs held_until, and custom_fields' dual list-or-JSON-string acceptance.

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 ('Create an issue') plus the distinguishing mechanism ('cache-aware id resolution'), which cleanly separates it from redmine_update_issue, redmine_get_issue, and redmine_bulk_create_issues. It does not, however, explicitly name the bulk sibling or spell out the boundary, so sibling routing 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?

There are scattered usage hints ('status... is rarely needed', 'difficulty... so auto-callers don't trip the required-field validation'), which help an agent decide which optional params to populate. But there is no explicit when-to-use-this-vs-alternatives guidance (e.g., versus redmine_bulk_create_issues) and no stated prerequisites other than the read-only env var.

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 provided. The description mentions 'Honors REDMINE_MCP_READ_ONLY' which gives a behavioral insight, but does not disclose other aspects like required permissions, error handling, or side effects.

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

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

The description is extremely concise with two sentences and an Arg list. It front-loads the purpose and efficiently covers parameters without unnecessary 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 description covers all parameters and the read-only behavior. An output schema exists to handle return values, so the description is adequate for a simple creation tool. Could mention success output briefly.

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%, but the description adds meaning: project_id as numeric id or slug, name as required, assigned_to_id as optional with 0 meaning none. This compensates well for the lack of schema descriptions.

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

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

The description clearly states 'Create an issue category on a project,' which is a specific verb+resource. This distinguishes it from sibling tools like 'redmine_create_issue' or 'redmine_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?

The description explains the tool's purpose but lacks explicit guidance on when to use it versus alternatives (e.g., redmine_update_issue_category). No when-not-to or contrast with siblings is provided.

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

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

No annotations are provided, so the description carries the full burden. It clearly states that the tool creates a new forum topic and mentions it honors the REDMINE_MCP_READ_ONLY environment variable, which is a behavioral trait. However, it does not disclose other behaviors like authentication requirements or error handling.

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 very concise: a single sentence followed by a clear list of parameters. No unnecessary words, and the key action is front-loaded.

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 tool has an output schema, so return values need not be described. The description covers the tool's purpose, parameters, and a behavioral constraint (read-only honor). It is sufficient for a simple creation tool, though it lacks details on success/failure responses that might be in the schema.

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

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

The input schema has no descriptions for parameters (0% coverage), but the description lists all three parameters with functional explanations: board_id as numeric, subject as required, content as optional. This adds significant meaning beyond the schema's type and title alone.

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 'Create a new forum topic on a board' uses a specific verb and resource, clearly indicating the tool's function. This distinguishes it from siblings like redmine_reply_message (for replies) and redmine_create_news (news items).

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 states what the tool does but does not provide guidance on when to use it over alternatives, nor does it specify prerequisites or exclusions. Usage is implied by the name and sibling 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?

No annotations provided. The description does not disclose permissions, immediate effect, or whether notifications are sent. It only mentions a read-only flag, which is minimal for a creation 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?

Extremely concise: six lines, front-loaded purpose, clear bullet-like listing of parameters. No unnecessary 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?

Given the output schema exists (though not shown), the description is adequate but misses potential constraints or validation details. Suitable for a simple creation tool but could be more 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?

With 0% schema description coverage, the description adds value by clarifying that 'project' accepts numeric id or slug, and explains optional vs required fields. Covers all 4 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?

Description clearly states 'Create a news entry on a project.' This is a specific verb and resource, distinguishing it from sibling tools like redmine_create_issue and redmine_create_message.

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?

Mentions that it honors REDMINE_MCP_READ_ONLY, implying it won't work in read-only mode, but does not provide explicit when-to-use or alternative comparisons like redmine_update_news.

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

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

Annotations are absent, so the description carries the full behavioral burden. It usefully discloses that the tool honors REDMINE_MCP_READ_ONLY and clarifies the default-resolution semantics of None for is_public and inherit_members, which is real added context. However, it says nothing about required permissions, what happens on identifier collision, validation failure behavior, or side effects such as default modules/trackers being enabled.

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

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

Front-loaded with the purpose in one line, then a compact per-parameter list with no filler sentences. The list is long but justified given nine undocumented parameters; only minor tightening is possible.

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 all nine inputs are annotated. What remains missing is operational context appropriate to a mutation tool: permission requirements and error/failure behavior. Given the output schema and full parameter coverage, the definition is nearly 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% and there are 9 parameters, so the description must compensate and it does: it marks which two are required, gives the identifier format (lowercase, hyphens, no spaces), explains the None-means-Redmine-default convention for two nullable params, notes parent_id 0 means top-level, and supplies an example value for enabled_module_names. This is meaningfully more than the schema alone conveys.

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

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

The opening line states a specific verb and resource ("Create a new project"), which unambiguously distinguishes it from siblings like redmine_update_project, redmine_delete_project, and redmine_archive_project. It does not explicitly name an alternative, but the create/update/delete/archive split among siblings is self-evident from the names.

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, no prerequisites (e.g. permission level needed to create projects), and no mention of the sibling tools an agent might confuse this with. The only routing-relevant signal is the REDMINE_MCP_READ_ONLY note, which constrains execution but does not help select this tool over alternatives.

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 does so well: it discloses that the tool honors REDMINE_MCP_READ_ONLY, that hours are pre-validated client-side, that activity resolves against a cached enumeration, that spent_on defaults server-side to today, and that comments cap at 1024 chars. It omits error/failure behavior and whether the entry is reversible, so it is not exhaustive.

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 summary sentence is front-loaded and each Args line earns its place by adding a distinct constraint or format. It is slightly long relative to a single-sentence ideal, but the density is justified for a seven-parameter tool.

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

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

All parameters are documented, environment-variable fallbacks and read-only mode are explained, and an output schema exists so return values need not be described. Nothing an agent needs to invoke this tool correctly is missing.

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

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

Schema description coverage is 0%, so the description must compensate and it does: all seven parameters are explained with accepted formats ("2.5" or "H:MM"), defaults, mutual-exclusion rules, and permission constraints. This is meaning well beyond anything the bare schema conveys.

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

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

The opening line names a specific verb and resource ("Log a time entry") and scopes the target to an issue or project, so the agent knows exactly what operation this is. It does not explicitly differentiate itself from the close siblings redmine_bulk_create_time_entries or redmine_update_time_entry, which keeps it from a 5.

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

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

The description gives concrete selection conditions: either issue_id or project_id is required unless REDMINE_MCP_DEFAULT_TIME_ISSUE is set, project_id is ignored when issue_id is non-zero, and user_id is admin-only. It stops short of routing the agent away from sibling tools such as bulk_create_time_entries when logging many entries.

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 indicates that the tool creates a version (mutation) and mentions 'Honors REDMINE_MCP_READ_ONLY,' which hints at a read-only gate. However, it does not detail authentication requirements, success/failure responses, or other behavioral traits like rate limiting.

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 concise and well-structured with an 'Args' header and a clear bullet-like list. Every line adds value, and there is no redundant or extraneous 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?

Given the tool has 7 parameters, no annotations, and an output schema, the description covers the parameters well and mentions the read-only flag. The return value is not explained, but the output schema handles that. It could be more complete by describing error states, but it is sufficiently informative overall.

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

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

The input schema has 0% description coverage, so the description must compensate. It thoroughly explains each parameter: project id/slug, name required uniqueness, optional description, status enum, due_date format, sharing enum, and optional wiki_page_title. This adds substantial meaning beyond the schema's basic type and title fields.

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

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

The description clearly states 'Create a version on a project.' It is a specific verb-resource pair. Among siblings like redmine_get_version, redmine_update_version, redmine_delete_version, and redmine_list_versions, this tool is uniquely identified as creation, making differentiation straightforward.

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 does not explicitly state when to use this tool versus alternatives; however, the context of sibling tools implies that this is for creating versions while others handle update, delete, or retrieval. No prerequisites or usage conditions are mentioned beyond honoring REDMINE_MCP_READ_ONLY, which is a behavioral flag.

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 fully discloses behavior: pre-flight GET, rejection of empty text, existence check, error handling, and read-only flag honoring. No contradictions.

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?

Well-structured with a leading sentence and bullet-pointed args. Every sentence adds value; no redundancy or 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?

Comprehensive for a creation tool with 5 parameters; covers all relevant aspects including pre-flight, error cases, and optional fields. Output schema exists, so return details are not needed.

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?

Despite 0% schema coverage, the description compensates by explaining each parameter's purpose, type (e.g., numeric id or slug), and special behaviors (URL encoding, markdown, optional hierarchy).

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?

Clearly states the tool creates a new wiki page and explicitly mentions it refuses to overwrite existing ones, distinguishing it from siblings like redmine_update_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?

Provides explicit guidance on when to use (creating new pages) and when not (page already exists), including the pre-flight check and error return. Also notes the REDMINE_MCP_READ_ONLY constraint.

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

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

The description discloses critical behavioral traits: permanent deletion and the need for admin privileges. It also notes compliance with the REDMINE_MCP_READ_ONLY flag, which is important for agents respecting read-only modes. No annotations were provided, so the description carries the full burden and meets it well.

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 extremely concise: two sentences that pack essential information. The first sentence covers the action and constraints, and the second provides a behavioral flag. 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?

The description covers all necessary aspects for a deletion tool: what it does, who can use it (admin), its effect (permanent), and a behavioral flag. An output schema exists, so return values are not needed. It is fully complete for this tool's complexity.

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 (group_id), and the description does not explicitly mention it, but the tool name and action make it obvious that the parameter identifies the group to delete. The schema provides the type and title, so the description adds little value beyond that, but the context compensates. Given low schema coverage (0%), a 4 is justified because the intent is clear.

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

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

The description clearly states 'Delete a group', providing a specific verb and resource. It distinguishes from sibling tools like redmine_create_group and redmine_update_group by its focus on deletion. The additional constraints 'admin only' and 'Permanent' add clarity.

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 includes a clear prerequisite ('admin only'), indicating when the tool is appropriate. It also notes 'Permanent' to warn about irreversibility. However, it does not explicitly mention when not to use it or suggest alternative tools for related operations (e.g., removing users from groups).

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 fully discloses the destructive, irreversible nature, the safety gate parameter, the return confirmation, and the respect for a read-only mode. This covers behavioral traits beyond what annotations could specify.

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 very concise with two introductory sentences and a clear argument list. Every sentence adds value and the main purpose is front-loaded.

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, parameter semantics, behavioral traits, and safety. It lacks explicit guidance on when to use this tool versus alternatives, but given the simple destructive operation and existence of an output schema, it is largely complete for an agent to invoke correctly.

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

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

The description adds meaning to both parameters: issue_id is clearly explained as a numeric Redmine issue id, and confirm_destructive is described as a safety gate that must be True to proceed. Since the input schema had no descriptions (0% coverage), this compensation is valuable, though it could provide more detail on issue_id format.

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

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

The description clearly states 'Permanently delete an issue' with a specific verb and resource. It distinguishes from sibling tools like redmine_delete_project or redmine_delete_group by focusing on issues.

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 mentions a safety gate (confirm_destructive) and that it honors REDMINE_MCP_READ_ONLY, providing some context. However, it does not explicitly state when to use this tool versus alternatives (e.g., close_issue) or when not to use it.

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

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

The description discloses that deletion is permanent and honors a read-only mode. It also explains the reassign_to_id parameter behavior. This adds value beyond the schema and no annotations are present to contradict.

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 extremely concise with no wasted words. The purpose is front-loaded, and the parameter details are clearly structured in a 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?

Given the tool's simplicity (2 params, output schema exists), the description covers the action and key parameter behavior. It lacks prerequisites or error handling, but is sufficient for a delete operation.

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

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

With 0% schema coverage, the description provides essential meaning: category_id is numeric, reassign_to_id is optional with a special value '0' for no reassignment. This clarifies usage beyond the schema types.

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

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

The description clearly states 'Delete an issue category. Permanent.' which is a specific verb+resource combination. The name itself is also clear, and it distinguishes from siblings like update or create issue category.

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 does not provide explicit guidance on when to use this tool over alternatives (e.g., update_issue_category). It mentions 'Honors REDMINE_MCP_READ_ONLY' but that is a constraint, not usage context.

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

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

The description adds two behavioral traits: deletion is permanent, and the tool honors the REDMINE_MCP_READ_ONLY flag. However, it does not disclose side effects (e.g., cascade deletion of replies), permission requirements, or error states. Since no annotations are provided, the description carries the full burden, and it partially fulfills it.

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 concise with two sentences and a line, no fluff. It could benefit from a slightly more structured format (e.g., bullet points for key facts), but overall it is efficiently written and front-loaded with the primary action.

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

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

Given the simple operation (one required param, output schema present), the description is minimally complete. It covers permanence and read-only mode, but omits details like error handling, permission requirements, or the impact on related entities. For such a straightforward tool, it is adequate but not thorough.

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 only parameter is message_id (integer). Schema coverage is 0%, and the description does not elaborate on its meaning, format, or constraints. The parameter name is self-explanatory, but the description should at least confirm that it refers to the ID of the forum message to delete.

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 explicitly states 'Delete a forum message' with the qualifier 'Permanent,' clearly indicating the action and resource. It distinguishes from sibling tools like redmine_create_message or redmine_reply_message, which serve different purposes.

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

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

No explicit guidance on when to use this tool versus alternatives. While the tool name implies deletion, the description lacks context such as prerequisites, alternative approaches (e.g., using redmine_delete_issue for issues), or conditions under which deletion is appropriate.

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 disclose behavioral traits. It only says 'Permanent' and mentions the read-only flag. It lacks details like required permissions, side effects on related data, or error conditions.

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 extremely concise at two sentences, front-loading the core action and permanence. 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?

For a delete operation, the description is incomplete. It does not explain the return value (though an output schema exists), confirm deletion is irreversible beyond a single word, or cover edge cases like non-existent IDs. Given the simplicity, more context is expected.

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

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

The input schema has one required parameter (news_id) with 0% coverage. The description does not add any meaning, format, or context for this parameter beyond what the schema provides.

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

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

The description clearly states the verb 'Delete' and the resource 'news entry', and adds 'Permanent' to indicate irreversibility. Among sibling tools like redmine_update_news and other delete tools, it is distinct.

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 mentions 'Honors REDMINE_MCP_READ_ONLY', which gives a condition for when the tool might be disabled. However, it does not explicitly state when to use it versus alternatives or any prerequisites.

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?

Explicitly states permanent deletion and honors read-only flag, which is critical behavioral info. No annotations present, so description carries this burden effectively.

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 sentences with clear front-loading and no waste; parameter noted concisely.

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?

Covers purpose, parameter, and behavioral traits adequately; output schema likely covers return values, so no further detail needed for this simple tool.

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?

Adds format details (numeric id or slug) to the project_id parameter, compensating for 0% schema description 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 clearly states the tool deletes a project permanently with all its data, distinguishing it from sibling tools like redmine_archive_project or redmine_delete_issue.

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 about destructiveness and mentions the read-only flag, but does not provide guidance on when to use this vs alternatives like redmine_archive_project.

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 discloses permanent deletion and respect for read-only configuration, which are critical behavioral traits. Additional details like permission requirements could further improve transparency.

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

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

Two sentences with no redundancy. The first sentence states the core action, the second adds an important constraint. Every word is meaningful and front-loaded.

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 permanence and configuration awareness. However, it omits error conditions, return value (output schema exists but not described), and prerequisites like authentication or permissions. Still, it is sufficient for a simple deletion tool.

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%, yet the tool description adds no meaning to the 'time_entry_id' parameter beyond its name. The parameter is obvious, but for a 0% coverage tool, more detail (e.g., format, source) would be expected.

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

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

The description clearly states the action (Delete) and resource (time entry), and uses 'Permanent' to emphasize irreversibility. It distinguishes well from siblings like create/update time entries.

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 mentions permanence and read-only flag, giving usage context. It implies this tool is for irreversible deletion, but does not explicitly state when not to use or alternative 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?

Without annotations, the description discloses permanence, no soft-delete, the 422 error condition, and respect for read-only mode. These are key behavioral traits. It could also mention required permissions or cascade effects, but currently provides solid transparency.

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 sentences: the first states core purpose, second gives error guidance, third notes read-only handling. Each sentence is essential and front-loaded. No unnecessary 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?

Given the simple tool with one parameter and an output schema, the description covers purpose, permanence, error handling, and a constraint. It lacks mention of prerequisites like version existence or permissions, but is otherwise 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 sole parameter 'version_id' is described as 'by id' in the description, but this adds minimal value beyond the schema. With 0% schema coverage, the description could elaborate more on how to obtain the id or its format.

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 first sentence clearly states the action: 'Delete a version by id.' It also specifies it's permanent with no soft-delete, distinguishing it from other version operations like create or update.

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 guidance on handling a common error (422) and suggests a workaround using redmine_assign_issue_to_version. It also notes that it honors REDMINE_MCP_READ_ONLY. However, it does not explicitly contrast with other deletion tools or state prerequisites.

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

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

The description discloses key behavioral traits: the deletion is permanent ('Permanently delete'), there is no soft-delete in Redmine, it honors the REDMINE_MCP_READ_ONLY environment variable, and it specifies the return format on success and failure. Since no annotations are provided, the description fully covers the behavioral 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 concise and front-loaded with the main action. It uses only three short sentences plus a parameter list, with no extraneous information. Every sentence serves a purpose.

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 that the output schema exists (per context signals) and the tool is a straightforward delete operation, the description covers all necessary aspects: action, parameters, return values, and safety behavior. No additional information is needed.

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 adds meaningful context: 'numeric id or identifier slug' for project and 'wiki page title' for title. While brief, it provides enough information beyond the bare schema types to guide the agent.

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

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

The description clearly states 'Permanently delete a wiki page (and all its historical versions)', specifying the verb (delete), resource (wiki page), and scope (including history), which distinguishes it from sibling tools like redmine_create_wiki_page or redmine_get_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?

The description does not provide any guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or comparisons with other delete tools among siblings.

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?

Adds caching behavior detail ('Cache-backed. First call populates the cache.') but does not explicitly state it is read-only or non-destructive, which would be helpful given no annotations.

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

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

Three concise sentences front-loaded with purpose, no superfluous 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?

Covers purpose, parameter format, return content, and caching; output schema provides structured details, so description is fully adequate.

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%, but description fully explains the 'project' parameter with format examples (numeric id or identifier slug), adding significant meaning beyond the schema.

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

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

Clearly states it returns a project description and lists specific contents (trackers, modules, issue categories), distinguishing it from sibling CRUD and list tools.

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

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

Implies usage for retrieving a single project's details, but does not explicitly state when not to use or mention alternatives among siblings.

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 provided, so description carries full burden. It explains the reactive learning of workflow graph from prior API calls, a key behavioral trait. No side effects or idempotency mentioned, but adequate for a read-like 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?

Description is reasonably concise with front-loaded purpose. The explanation of reactive learning adds value but could be slightly trimmed. Overall 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?

Given output schema exists, description doesn't need to detail return format. It covers tracked info components and learning mechanism. Some aspects like availability of statuses/priorities being static vs learned are implied but not explicit.

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%, but description fully explains both parameters: tracker with example format and include_observations with default and effect. Adds meaning beyond schema by describing the learned workflow graph context.

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

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

The description clearly states the tool returns an 'enriched schema' for one specific tracker, distinguishing it from sibling tools like redmine_list_trackers. It specifies the content: available statuses, priorities, and optional workflow graph.

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 implies use for detailed tracker info but does not explicitly contrast with siblings or provide when-not-to-use guidance. No mention of alternatives like redmine_list_trackers for summary.

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 full burden. It discloses important behavioral traits: validation of downloaded byte count, surfacing short reads as 'attachment_size_mismatch', path restrictions with symlink resolution, and read-only safety. It could mention authentication or rate limits, but overall it's transparent.

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 well-structured with an Args section and paragraphs. It is informative but slightly verbose; every sentence adds value. A more concise version could omit the docstring formatting, but it remains clear and organized.

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

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

Given the tool's complexity (3 parameters, output schema present but not described), the description covers primary behaviors: parameter details, validation, and safety. It lacks explicit description of return values or output format, but the mention of error surfacing partially compensates.

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%, but the description thoroughly explains each parameter: attachment_id (numeric, visible in issue payloads), save_to (path with parent directory must exist and be under allowed directories), overwrite (default false, refuses overwrite). This adds significant meaning beyond 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?

The description clearly states the tool downloads an attachment by ID to a path-restricted location. It specifies the action (download), resource (attachment by id), and target (path-restricted). This distinguishes it from sibling tools like redmine_upload_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?

The description provides context like path restrictions and overwrite behavior but does not explicitly state when to use this tool versus alternatives. It lacks guidance on when not to use it or which sibling tools are better suited for different tasks.

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?

Explicitly states 'Read-only', which is a key behavioral trait. However, with no annotations, more detail on auth or error outcomes would be beneficial. Minimal but sufficient.

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 argument list. No fluff, front-loaded purpose. Highly concise and well-structured.

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

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

For a simple fetch with two params and an output schema, the description covers key aspects. Could mention return type or error handling, but output schema likely handles that.

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%, but description fully explains both parameters: group_id as numeric integer, include with specific valid values (users, memberships). Adds significant value.

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?

Clear verb 'Fetch' and resource 'group by id', distinct from siblings like redmine_get_user or redmine_list_groups.

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

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

Usage context is clear (fetch single group), but no explicit exclusions or alternative tool mentions. The name itself conveys purpose, so it's adequate.

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 present, the description carries the full burden and does so well: it declares the operation read-only, notes there is no workflow validation, and explains that project.identifier is enriched from the project cache when available. That is genuine behavioral context beyond the schema, though it says nothing about permissions or error behavior.

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

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

The core purpose is front-loaded in one clause, followed by a compact args block. Every sentence adds information, though the blank-line-separated sections are slightly airier than needed for a two-parameter tool.

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

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

An output schema exists so return values need no explanation, and the description covers both parameters, the read-only safety profile, and the cache-enrichment caveat. Nothing an agent needs to call this correctly is missing.

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

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

Schema description coverage is 0%, so the description must compensate entirely — and it does: issue_id is described as a numeric Redmine issue id, and include is documented with its default value plus the non-obvious rule that an empty string falls back to the default. Both parameters gain meaning the schema does not supply.

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 ("Fetch a single issue") and the singular scope distinguishes it from list/search siblings like redmine_search_issues and redmine_list_child_issues. It does not explicitly name those alternatives, 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 guidance on when to reach for this tool versus redmine_search_issues, redmine_get_journals, or redmine_my_issues; usage is only implied by the word "single". The include-default note is a parameter detail, not a usage rule.

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?

Declares 'Read-only' which is a behavioral trait, but no mention of auth, rate limits, or side effects. With no annotations, more context would be beneficial.

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 concise, front-loaded with purpose, then parameter details. Every sentence adds value with no redundancy.

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

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

Given output schema exists, return values are fine, but lacks details on error handling, pagination, or ordering. Adequate but not fully comprehensive.

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

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

The description explains the 'issue_id' parameter as a numeric Redmine issue ID, adding semantics beyond the schema type (integer). Although schema coverage is 0%, this compensates well.

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

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

The description clearly states the tool returns structured journal entries for an issue, with a specific verb and resource. It is distinct from siblings like 'redmine_get_issue' (issue details) and writing tools.

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

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

No guidance on when to use this tool vs alternatives like 'redmine_update_journal' or searching. Lacks explicit context or exclusions.

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

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

No annotations are provided, so the description carries the full burden. It states the tool is read-only and returns role with permissions, but it does not disclose error behavior, authentication requirements, or rate limits. For a simple fetch, it is adequate but not comprehensive.

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

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

Two concise sentences: the first defines the action and output, the second declares read-only. No unnecessary words, information is front-loaded. Every sentence adds value.

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

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

For a simple fetch tool with an output schema (not shown), the description adequately covers the main purpose and output. It does not cover error scenarios or prerequisites, but given the low complexity, it is nearly 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 schema has one parameter (role_id) with 0% description coverage. The description mentions 'by id' but does not explicitly describe the parameter or add constraints beyond the schema. Since the parameter is simple and self-evident from the tool name and description, the added value is marginal.

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

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

The description clearly states 'Fetch a role by id, including its permissions list.' It specifies the action (fetch), the resource (role), and the output (permissions list). It is distinct from sibling tools like redmine_list_roles by focusing on a single role by ID.

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?

While the description indicates it is read-only and fetches a single role, it does not provide explicit guidance on when to use this tool versus alternatives like redmine_list_roles to list all roles. No exclusions or prerequisites are mentioned.

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 provided; the description declares the tool is read-only and describes parameter behavior, but lacks details on auth, rate limits, or error handling.

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?

Concise and well-structured with a clear purpose line, Args block, and final read-only note. Every sentence adds value.

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

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

Covers essential aspects for a get tool (parameters, read-only nature) and output schema exists, but the user_id type mismatch (string in schema, numeric in description) may cause minor confusion.

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?

Adds significant meaning beyond the bare schema: explains user_id accepts numeric values or 'current', and include accepts comma-separated options like memberships and groups.

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

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

The description clearly states 'Fetch a user by id, or the current API user,' using a specific verb and resource, and distinguishes from sibling tools like redmine_list_users.

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 context for when to use (get specific user or current user) and explains default values, but does not explicitly state when not to use or name alternatives.

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

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

The description declares 'Read-only' and mentions the possible return value 'version_not_found', which is good for a read operation. With no annotations, it provides sufficient behavioral context for a simple fetch.

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

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

Two concise sentences front-load the key action and output, with 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?

For a simple fetch tool with an output schema present, the description covers the return fields and error case adequately. Could mention that the output schema contains the listed fields, but not necessary.

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

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

The description adds 'by id' but the parameter name 'version_id' is already clear. Schema coverage is 0%, so the description could provide more detail about the parameter, but the parameter self-explains.

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

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

The description clearly states that the tool fetches one version by ID, distinguishing it from siblings like redmine_list_versions (multiple) and redmine_create_version (create).

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 implies use when you need a specific version by ID, but does not explicitly state when not to use it or suggest alternatives like redmine_list_versions for searching.

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

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

The description explicitly states 'Read-only', which is a key behavioral trait. It also describes the return value (page details or wiki_page_not_found). No annotations provided, so the description carries the full burden, but it covers safety and non-destructive nature adequately.

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 appropriately sized and well-structured with a brief introductory line and bullet-pointed parameter explanations. It is clear without being verbose, though could be slightly more concise.

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

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

Given the tool's complexity (3 parameters, no enums, output schema exists), the description covers the core functionality, parameter details, and return information. It is sufficient for an agent to invoke the tool correctly.

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

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

The description adds significant meaning beyond the input schema names: project is explained as numeric id or slug, title as URL-encoded automatically, version as historical version. This compensates for the 0% schema description 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 clearly states 'Fetch a wiki page' which is a specific verb+resource. It also mentions an optional historical version, distinguishing it from sibling tools like create_wiki_page, update_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?

No explicit guidance on when to use this tool versus alternatives. While it implies use for fetching specific wiki pages, there is no mention of when not to use or reference to sibling tools for different operations.

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 does well: it explains that the tool fetches the current account, that status ok means the URL is reachable and credentials were accepted, and that it returns a structured error otherwise. It does not mention side effects or rate limits, but none are expected for a read-only health check.

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 short sentences, front-loaded with the action and immediately followed by the result semantics. Every sentence earns its place with no filler.

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

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

For a zero-parameter diagnostic tool with an output schema, the description is complete. It explains what is validated and how to interpret the success and error responses, leaving return-value details to the output schema.

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 parameter semantics are not applicable. Per the baseline rule for zero-parameter tools, a 4 is appropriate.

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

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

The description states a specific verb and resource: validate Redmine connectivity and credentials. It clearly distinguishes the tool's diagnostic purpose from the CRUD-oriented siblings, but it does not explicitly name or differentiate against any alternative 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?

The description makes the intended context clear: use it to validate connectivity and credentials. It does not provide explicit when-not guidance, but no sibling alternative exists for this diagnostic purpose, so the usage context is 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?

With no annotations, the description carries full burden. It reveals that no HTTP request is made, auth fingerprint is preserved, and details the effects of each scope option. While safety or reversibility is not discussed, the provided behavioral traits are sufficient.

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 exceptionally concise—four sentences structured with a clear purpose, parameter details, and usage context. Every sentence adds value without redundancy or filler.

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

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

Given the tool's simplicity (one parameter) and the presence of an output schema, the description fully covers behavior, parameter options, and usage context. It needs no additional information for correct invocation.

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

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

The input schema has 0% description coverage, but the description fully compensates by explaining each allowed value ('all', 'tracker:<id-or-name>', 'project:<id-or-slug>') and their specific effects, adding crucial meaning beyond the schema.

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

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

The description clearly states 'Drop cached entries for a scope,' using a specific verb and resource. It distinguishes itself from sibling CRUD tools by focusing on cache invalidation, making its purpose unambiguous.

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

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

Explicitly states 'Use after Redmine config changes (new trackers, edited workflow, moved roles),' providing clear context. Although no direct alternatives are listed, the tool is unique among siblings, and the description effectively guides when to invoke it.

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

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

With no annotations, the description carries the burden of disclosing behavior. It correctly marks the tool as 'Read-only' and specifies the return structure. However, it omits details like pagination, error handling, or rate limits, which would enhance transparency.

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 extremely concise, using two sentences plus a structured args/return block. Every sentence is meaningful and front-loaded with the core purpose.

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

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

Given the tool's simplicity and the existence of an output schema, the description covers the essential behavior: listing boards with a specified project ID and returning a defined structure. It could mention pagination or ordering, but these are implicit for a list tool.

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

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

The input schema has 0% coverage, so the description must clarify parameter meaning. It describes project_id as 'numeric id or identifier slug', adding valuable context beyond the schema's string type. This is sufficient for one parameter.

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

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

The description clearly states the verb 'List' and the resource 'forum boards for a project', making the tool's purpose unambiguous. It is distinct from sibling list tools like redmine_list_projects or redmine_list_messages.

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 is provided on when to use this tool versus alternatives, nor are there any exclusions or prerequisites mentioned. The description only specifies that it lists boards for a project, without contextual flags.

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 establishes a read-only list operation and discloses useful operational traits: the limit is capped at 100, offset skips results, and empty assignee means all users. It does not mention authentication or rate limits, but those are less critical for a simple list.

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

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

The description is front-loaded with the purpose, then efficiently lists argument semantics. Every sentence and argument entry earns its place with no redundant boilerplate.

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

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

Given the moderate five-parameter list operation and the existence of an output schema, the description is nearly complete. It covers all parameters and pagination constraints, though it could add a brief note about ordering or the relationship to search_issues for filtering beyond children.

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 documents all five parameters with added meaning: issue_id as the parent issue, assignee as numeric id or 'me' with empty meaning all, status values referencing search_issues, limit as page size capped at 100, and offset as result skipping.

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: 'List an issue's child tickets.' It adds the optional assignee filter, making the scope clear enough to distinguish it from siblings like search_issues or get_issue.

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

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

Usage is implied by the purpose and the optional assignee filter, but there is no explicit when-to-use or when-not-to-use guidance and no named alternative for broader issue searches. The reference to search_issues is for parameter value reuse, not tool selection.

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 two key behaviors: read-only and admin-only access. It does not cover other aspects like rate limits or data freshness, but the provided info is sufficient for a simple list 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 two sentences long, front-loaded with the purpose, and lists key return fields. Every sentence adds value; 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?

Given the tool has no parameters and an output schema exists, the description adequately covers the main points: admin restriction, read-only nature, and sample return fields. It could mention pagination or ordering, but for a simple read-only list, it is sufficient.

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

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

The input schema has zero parameters, so schema coverage is 100%. The description need not add parameter info. The baseline is 4, and the description meets it without adding redundant detail.

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

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

The description clearly states it lists custom field definitions and names the resource. It specifies 'admin only', which adds context. However, it does not differentiate from sibling list_* tools, which all follow a similar pattern.

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 'admin only', indicating a prerequisite. There is no mention of when to use this tool versus alternatives (e.g., other list tools), nor any exclusions or alternative 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 behavioral burden and does so well: 'Read-only; makes no API request' discloses the safety profile and an important side-effect guarantee for an introspection tool. It does not mention rate limits or caching, but for a static endpoint catalog that is minor.

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 body sentences plus an Args line, with the core purpose front-loaded before the usage hint and the read-only guarantee. Nothing is wasted and it reads cleanly.

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

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

For a read-only endpoint lister with an output schema (which handles return-value documentation), the description covers purpose, usage routing, side-effect behavior, and the parameter. An agent has everything needed to select and invoke it 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 description coverage is 0%, so the description must compensate for the single parameter, and it does: 'optional case-insensitive substring over method/path/purpose' explains both optionality and the fields searched. This fully documents the lone param.

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