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

With no annotations, the description carries the full burden and does disclose the critical side effect: elapsed time is discarded and nothing is written to Redmine. It does not cover what happens if no timer is running, whether the cancel is reversible, or permission requirements, leaving some gaps for a 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?

Two short sentences, with the no-logging consequence front-loaded in the first. Zero filler; every clause carries information an agent needs before invoking.

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

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

For a one-parameter mutation with no output schema, the definition covers purpose, the parameter, and the key destructive effect (time discarded). Edge cases like canceling when no timer is active are unaddressed, which keeps it just short of complete.

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

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

Schema coverage is 100% and the single issue_id parameter is fully documented in the schema, so the description adds no parameter detail. Baseline 3 applies since the schema does the work.

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 ('Cancel the running timer for an issue') with the crucial qualifier that no time is logged. This functionally separates it from stop_timer, though the sibling is never named, so an agent must infer the pairing rather than be told it.

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 'WITHOUT logging any time ... elapsed time is discarded' framing strongly implies when to choose this over a stop-and-log path, but it never explicitly says 'use stop_timer instead if you want to record the time.' Usage is inferable rather than stated.

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

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

With no annotations, the description does disclose real side effects: auto-assignment to the detected local user and automatic start/due date population keyed to status. However, much of this is duplicated from the schema's parameter descriptions, and it omits permission requirements, failure modes, and what the call returns (issue ID) for a mutation tool.

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

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

Three short sentences, front-loaded with the core action, then the two automatic behaviors. No filler, though the auto-behavior sentence could be folded into the schema-covered content it repeats.

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 13-parameter mutation tool with no annotations and no output schema, the description covers the notable automatic behaviors but leaves gaps: it never says project_id is effectively required (the schema's required array lists only subject), does not describe the response, and does not clarify its boundary with create_or_update_issue.

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

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

Schema coverage is 100%, so every one of the 13 parameters is already documented in the schema, including the auto-assign default and date formats. The description adds no parameter-level meaning beyond what the schema provides, so the baseline of 3 applies.

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

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

States a specific verb+resource ("Create a new issue in Redmine"), which clearly separates it from read/mutation siblings like get_issue or update_issue. It does not explicitly distinguish itself from the close sibling create_or_update_issue, leaving that ambiguity for the agent to resolve.

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 only implied by the verb and the auto-behavior notes; there is no explicit when-to-use guidance, no mention of when to prefer create_or_update_issue, and no stated prerequisites (project must exist, tracker/status IDs must be valid).

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

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

No annotations are provided, so the description carries the full burden. It does disclose real behavioral traits beyond the schema: auto-assignment of the user and auto-setting of dates. However, it omits important behavior such as how ambiguous partial matches are resolved, whether unmentioned fields are overwritten on update, and any permission requirements for a tool that can mutate existing records.

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

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

Four short sentences with the find/update/create logic front-loaded and no filler. The trailing 'auto-assigns user, auto-sets dates, and can log time' is slightly compressed but still earns its place.

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

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

For a 12-parameter mutation tool with no annotations and no output schema, the description covers the core upsert flow and key side effects. It leaves notable gaps on match ambiguity, overwrite semantics, and return behavior that an agent would need before calling it safely.

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

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

Schema coverage is 100%, so all 12 parameters are already documented. The description adds marginal value by noting auto-assignment when assigned_to_id is absent and automatic date handling, but it doesn't clarify ambiguous inputs like partial-match subjects. Baseline 3 is appropriate.

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

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

The description states a specific compound verb (find/update/create) on a specific resource (issue), and the upsert semantics inherently distinguish it from the sibling create_issue and update_issue tools. It doesn't explicitly name those siblings, so it stops short of a 5.

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

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

It explains the internal logic (exists → update, not exists → create) but gives no guidance on when an agent should pick this over create_issue, update_issue, or search_issues. Usage is implied by the upsert flow rather than stated as a selection 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?

With no annotations provided, the description carries the full behavioral burden. The word 'Permanently' is valuable — it discloses irreversibility, the single most important trait of a delete — but it omits permissions required, whether deletion is confirmed or can be undone, and any side effects on reported totals.

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

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

A single front-loaded sentence with zero waste; the most consequential word, 'Permanently', appears first.

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

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

For a one-parameter destructive tool with no annotations and no output schema, irreversibility is covered but confirmation behavior, error cases, and effects on aggregates are not. It is minimally sufficient to call correctly but thin for a permanent deletion.

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

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

Schema description coverage is 100%, with `id` documented as 'The time entry ID to delete', so the baseline of 3 applies. The description adds no format or sourcing detail (e.g., where to obtain the ID) beyond the schema.

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

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

States a specific verb and resource ('Permanently delete a time entry') that maps directly to the single `id` parameter. It is clearly distinct from siblings like update_time_entry or cancel_timer, though it never names an alternative explicitly.

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

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

There is no guidance on when to delete versus cancel a timer or update an entry, and no mention of preconditions. The agent must infer usage entirely from the verb.

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 exist, so the description carries the full burden. It helpfully discloses the detection mechanism (git config, system username, environment variables), which implies a read-only local lookup with no server mutation. However, it does not say what happens when detection fails or when no matching Redmine account is found, nor whether anything is cached or written.

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

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

Two sentences, front-loaded with the action and resource, followed by the mechanism. Every clause earns its place and there is 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?

With no parameters, no annotations, and no output schema, the description is the only source of truth. It explains the inputs to detection but not the outcome shape — whether it returns a user object, a name string, or an error when no match exists — which is the main thing an agent needs before relying on it.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; the description correctly conveys that detection is fully automatic with no caller-supplied input.

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

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

The description gives a specific verb and resource: 'Detect the current local user and find their matching Redmine account.' That is far more informative than the bare name, and none of the siblings (issue, timer, project, attachment tools) overlap with this capability. It stops short of an explicit contrast with siblings, but the purpose is unambiguous.

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

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

Usage is only implied: an agent can infer this is the tool to call when it needs to know which Redmine account the local machine belongs to. There is no explicit 'call this before X' guidance, no statement about when not to use it, and no alternative tool named.

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 burden. 'Get' implies a non-mutating read and 'full details' hints at response completeness, but there is no mention of permission requirements, default included associations, or not-found behavior. Adequate but thin for an unannotated tool.

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

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

A single front-loaded sentence with zero filler. The verb, resource, scope, and identifier requirement all appear immediately.

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 two-parameter read-by-ID tool with fully documented schema and no output schema, the description is nearly sufficient. It lacks only minor behavioral notes such as default includes or error conditions, which keeps it short of a 5.

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

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

Schema description coverage is 100%, so both issue_id and the include association list are fully documented in the schema. The description adds no parameter meaning beyond that, which is the expected baseline when the schema does the work.

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 (Get) and resource (Redmine issue) with scope (full details, by ID). The 'by ID' qualifier implicitly separates it from search_issues, but it never names that sibling explicitly, so differentiation is inferred rather than stated.

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

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

The phrase 'by ID' implies this is the lookup path when an identifier is known, contrasting with search_issues, but the description never says when to prefer one over the other or what happens with invalid IDs. Usage is implied, not guided.

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

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

With no annotations, the description carries the full burden, but "accessible with your API key" does disclose a real behavioral trait: results are permission-scoped, not a global listing. It stops short of covering pagination, result size, or failure behavior for an invalid key.

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

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

A single front-loaded sentence with no filler, and the scoping qualifier sits where it matters. It is efficient, though at this length it leaves room to add one clause of usage context without becoming bloated.

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 read tool this is close to sufficient, but there is no output schema, so the description could have named the returned fields (id, name, identifier) that other tools require. That omission is the main gap for an agent trying to chain calls.

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

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

The tool takes zero parameters, so there is nothing for the description to document; baseline 4 applies. The only semantic note (API-key scoping) is already present and correctly framed as a filter rather than a 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?

States a specific verb and resource ("List all Redmine projects") and adds a scope qualifier ("accessible with your API key"), so the agent knows exactly what comes back. It does not, however, differentiate itself from the other listing siblings (list_trackers, list_statuses, list_time_entry_activities), which follow the same 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?

There is no guidance on when to call this versus the sibling list tools, and no statement of prerequisites or follow-up use (e.g. that the returned project identifiers feed into search_issues or create_issue). The agent must infer the call context entirely.

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 burden. 'List all available' does communicate that the enumeration is complete (no filtering or pagination concerns), which is useful behavioral context. However, it says nothing about permissions, auth, or whether the list is project-scoped, leaving gaps for a no-annotation tool.

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

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

A single tight sentence with the resource front-loaded and the practical hint appended. No filler or redundancy.

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

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

For a trivial zero-parameter read tool with no output schema, the description covers what it does and why it matters (obtaining status IDs). Only minor gap is that it doesn't characterize the returned shape (e.g., id/name fields).

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly implies no input is required, consistent with the empty 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 ('List all available issue statuses in Redmine'), which is unambiguous and distinguishable from siblings like list_trackers or list_projects. It doesn't explicitly name an alternative, but the resource is distinct enough that confusion is unlikely.

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

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

The parenthetical '(useful to get status IDs)' implies the intended use case – resolving status IDs before calling create_issue or update_issue – but never states when to use this versus siblings or any prerequisites. Usage is implied rather than instructed.

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 at all, the description carries the full behavioral burden, yet it only signals implicitly that this is a read operation. It says nothing about pagination defaults, result ordering, permissions needed, or what happens when limit is exceeded — all relevant for a list tool with 6 optional params.

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

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

A single front-loaded sentence with no filler; every word earns its place. It is arguably too terse given the missing behavioral detail, but it is not padded or disorganized.

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 list tool with no annotations and no output schema, the description should explain default result scope, pagination behavior, and rough return shape. None of that is present, leaving significant gaps for an agent to infer.

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

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

Schema description coverage is 100%, so every parameter (from/to, limit, user_id, issue_id, project_id) is already documented in the schema including formats and defaults. The description only restates the filter dimensions without adding format, default, or interaction details beyond the schema.

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

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

States a clear verb and resource (list time entries) and names the filterable dimensions. It implicitly distinguishes the read operation from siblings like log_time, update_time_entry, and delete_time_entry, though it doesn't call out the contrast explicitly.

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

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

The word 'optionally' implies all entries are returned when no filters are given, which is useful usage context. However, there is no explicit when-to-use guidance, no mention of alternatives (e.g., for a single entry or for aggregations), and no stated 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 carries the burden; 'List' implies a safe read, but it doesn't state that results are unfiltered, whether the list is workspace-wide, or whether pagination applies. For a zero-parameter read-only lookup the risk is low, so a 3 is fair but there is room to say more.

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

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

A single short sentence, front-loaded with the verb and resource, with the examples earning their place by clarifying the item type. 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?

There is no output schema and no annotations, so the description should ideally say roughly what comes back (names? IDs? counts?) and whether the list is exhaustive. For a trivial zero-param lookup the gap is small, but it isn't fully closed.

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 zero parameters, so there is nothing to document; the baseline of 4 applies. The description's examples add a bit of meaning about what the returned values look like.

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 (List) and resource (time entry activities), and the parenthetical examples ('Development, Design, etc.') clarify what an activity actually is. It doesn't explicitly differentiate from siblings like list_trackers or list_projects, but the resource is unambiguous.

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

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

Usage is only implied: an agent can infer this is the lookup to call before logging time with an activity, but the description never says when to use it, that it takes no filters, or that it is a prerequisite-ish lookup for log_time/start_timer.

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. 'List all available' implies a complete, non-mutating read, but nothing states read-only safety, whether results are global vs project-scoped, or whether an authenticated Redmine session is required. The parenthetical examples are the only added context.

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

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

A single, front-loaded sentence with no filler. The resource and scope lead, and the examples add value rather than padding.

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

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

For a trivial zero-parameter, read-only enumeration tool with no output schema, the description covers what it is and roughly what it returns (tracker names/types). Only scoping (global vs project-specific) is left unstated, a minor gap at this complexity level.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate, and it correctly signals that no filtering input is 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?

Specific verb ('List') plus resource ('trackers in Redmine') with example values (Bug, Feature, Task), so the agent knows exactly what comes back. It is distinguishable from siblings like list_statuses and list_projects only by the resource noun; there is no explicit differentiation statement.

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 when-to-use, prerequisites, or alternatives are stated. Usage is implied by the nature of the tool (fetching tracker IDs/labels before creating or filtering issues), which an agent can infer, but the description does none of that work.

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 disclosure burden. It does add one genuinely useful behavioral fact beyond the schema — that the entry is automatically assigned to the detected user — but says nothing about permissions, whether the entry is created immediately, or what the response contains.

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, the key differentiator (manual vs. timer) front-loaded, and the auto-assignment side effect stated up front. 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?

Covers what it does and one side effect, but with no annotations and no output schema the description should say what a successful call returns (e.g., the created entry) and whether the issue must exist. It is adequate but leaves real 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 coverage is 100%, so hours format, date defaults, and the activity_id lookup route are already documented in the schema. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb ('log') and resource ('time entry for an issue') and explicitly contrasts with the timer-based path, which separates it from start_timer/stop_timer siblings. It does not distinguish itself from update_time_entry, but the create-vs-modify split is reasonably inferable from 'log'.

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

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

The parenthetical 'without using start/stop timer' implies the condition for choosing this over the timer tools, but it never names them or states when-not to use it (e.g., correcting an existing entry should go to update_time_entry). 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?

With no annotations, the description carries the full behavioral burden but discloses almost nothing: no note that all parameters are optional (so an unfiltered call returns a broad result set), no pagination/limit behavior, no permission or scope requirements. "Returns matching issues" is the only behavioral claim and it is essentially tautological.

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

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

Two short sentences with the capability front-loaded. The second sentence adds little value over the first, but there is no filler or padding overall.

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

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

For a 6-parameter search with no annotations and no output schema, the parameter layer is fully covered by the schema, but the description should say more about result shape, ordering, and default behavior when no filters are supplied. It is adequate but 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 100%, so the schema already documents defaults, limits, status values, and the 'me' assignee token. The description names four of the six fields (subject, project, status, assignee) but adds no syntax or semantics beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb ("Search") and resource ("Redmine issues") plus the searchable dimensions, so the agent can tell it apart from get_issue or create_issue. It doesn't explicitly name a sibling or contrast with get_issue for a known ID, so it falls short of a 5.

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

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

There is no guidance on when to use this versus get_issue (fetch a known issue) or the list_* tools, and no mention of what happens when all filters are omitted. Usage is only implied by the verb.

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

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

With no annotations, the description carries the full burden, and it does disclose one important trait: the time is not logged on start but on stop_timer. It does not say whether starting a second timer stops or duplicates the first, whether the timer is per-user or per-issue, or what the call returns.

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

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

Three short sentences, front-loaded with the action, then the trigger, then the downstream effect. Every sentence carries distinct information and none restates the tool name or title.

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

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

For a two-parameter tool with no output schema and no annotations, this covers purpose, timing, and the side effect that matters. The remaining gap is edge-case behavior — repeated starts and error handling for an invalid issue_id — which a longer description could have covered.

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

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

Schema coverage is 100%, with issue_id and description both documented inline, so the baseline of 3 applies. The description adds no parameter-level meaning beyond the schema — it never mentions that issue_id refers to a Redmine issue or how the description text surfaces in the time entry.

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 ("Start a timer for an issue") and immediately frames it against the sibling stop_timer, which is what actually logs the time. An agent can tell what this does and how it pairs with the rest of the timer trio without opening the schema.

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

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

"Call this when you BEGIN working on a task" gives an explicit trigger condition, and naming stop_timer clarifies the expected lifecycle. It stops short of exclusions — nothing says what to do if a timer is already running or when cancel_timer should be used 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 full burden, and it does disclose two real behaviors: a Redmine time entry is created and the current user is auto-detected. It omits what happens when no timer is running, whether an activity defaults, and whether failure leaves the timer intact — significant for a 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?

Two tight sentences, zero filler, with the primary action and its side effect 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?

For a mutation with no annotations and no output schema, an agent still lacks the failure semantics (no active timer), permission requirements, and any sense of what is returned. The core happy path is covered, but the edge behavior an agent needs before calling is not.

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

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

Schema coverage is 100%, so all four parameters are already documented, including the hours override and the list_time_entry_activities pointer for activity_id. The description adds only the implicit fact that no user parameter is needed because the user is detected automatically.

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 ('Stop the timer for an issue') plus the consequential side effect ('log the elapsed time to Redmine as a time entry'). It does not distinguish itself from the sibling cancel_timer, which is the critical ambiguity for an agent choosing between stopping-and-logging versus discarding.

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

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

No when-to-use or when-not-to-use guidance is given. The description never says the timer must already be running, never mentions cancel_timer as the non-logging alternative, and never contrasts with log_time for manually entering time, leaving the agent to infer the selection 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?

With no annotations at all, the description carries the full behavioral burden. It does disclose a genuinely non-obvious side effect (auto-setting start_date and due_date on status transitions), which is valuable, but it says nothing about partial-update semantics (are omitted fields preserved?), permission requirements, or whether the update triggers notifications.

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

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

Two sentences, zero filler, with the side-effect warning placed second so the core action lands first. Nothing could be cut without losing information.

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

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

For an 11-parameter unannotated mutation tool, the description covers the core action and one important side effect, and the schema is fully documented. It is still thin on partial-update semantics and sibling disambiguation, which are the two things an agent most needs to call this correctly.

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

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

Schema coverage is 100%, so the baseline is 3. The auto-set behavior the description mentions is already spelled out in the start_date and due_date schema descriptions, so it adds no meaning beyond the schema; nothing is said about how notes, done_ratio, or status_id interact.

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 ('Update an existing Redmine issue'), which is clearer than a tautology. It does not differentiate from the overlapping siblings create_or_update_issue and update_time_entry, leaving the agent to infer that this tool is for partial edits of an existing 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 word 'existing' hints at create-vs-update, but there is no explicit when-to-use statement, no exclusion, and no guidance on the meaningful choice between update_issue and create_or_update_issue, both of which appear in the 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 are provided, so the description carries the full disclosure burden, yet it says nothing about required permissions, whether unlisted fields are preserved, what happens if the entry does not exist or is locked/approved, or whether the change is reversible. Only the bare fact of mutation is conveyed.

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

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

Two short sentences, zero waste, with the action stated first and the invocation constraint second. Nothing is padded or restated from the name.

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

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

For a six-parameter mutation tool with no annotations and no output schema, the description omits error behavior, permission requirements, and partial-update semantics. An agent can form a call, but not predict the consequences or failure modes.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds a genuine constraint not encoded in the schema: the schema requires only `id`, while the description tells the agent at least one optional field must also be supplied. That is meaningful semantic value beyond the structured 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?

States a specific verb and resource ("Update an existing time entry") that an agent can distinguish from log_time (create) and delete_time_entry (remove) without opening the schema. It does not explicitly name a sibling or a boundary condition, so it falls short of 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?

"Pass at least one field to change" gives a real precondition for invocation, but there is no guidance on when to use this versus log_time or delete_time_entry, nor on prerequisites such as ownership or entry state. Usage is implied rather than explained.

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?

Since no annotations are provided, the description must carry the full burden of behavioral context. It fails to disclose crucial behavioral traits such as file size limits, required authentication/permissions for mutation, or expected failure modes.

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

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

It is a single, concise sentence that is front-loaded with the core functionality. It avoids filler while providing sufficient operational context.

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?

While the description clearly states the goal, it lacks depth necessary for a mutation tool, especially without annotations. It does not address potential limitations or behavioral constraints (like upload limits) that a sophisticated agent would require before execution.

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 value by listing common examples of acceptable file types (screenshot, log, HAR, PDF), guiding the agent on what kind of input it expects for the 'file_path' 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 identifies the action (upload and attach) and the resource (a local file) tied to a specific entity (an issue). It distinguishes itself as an attachment action among several issue management siblings.

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

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

The usage is implied—when a file needs attaching to an issue. However, it does not explicitly state any necessary prerequisites, permissions, or scenarios where this tool should or should not be used compared to other tools.

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