mcptask.online

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates a mutation operation ('Upload'), but doesn't cover whether this requires specific permissions, file size limits, allowed file types, overwrite behavior, or what the response contains. For an upload tool with no annotations and no output schema, this is a significant gap.

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

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

The description is a single, efficient sentence with no wasted words. It is front-loaded with the primary action and resource. However, it could be slightly more structured by separating key constraints or usage notes if they were included.

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

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

For a tool with 5 parameters, no annotations, and no output schema, the description is inadequate. It does not explain the return behavior, error conditions, permission requirements, or file handling specifics. While the schema covers parameter details well, the description leaves many operational questions unanswered.

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 baseline is 3. The schema already fully documents all five parameters including their types, required status, and usage notes (e.g., 'required when using file_content'). The description adds no parameter information 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 states a specific verb and resource: 'Upload a file attachment directly to an existing task/story/piece.' This is clear and distinguishes it from sibling tools like GetAttachmentTool (retrieval) and AddMessageTool (messages). It stops short of 5 only because it doesn't explicitly name the alternative tool for attaching via other means or reference siblings by name.

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

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

There is no explicit guidance on when to use this tool versus alternatives. The description mentions 'directly' and 'existing' which implies usage context, but doesn't specify prerequisites such as whether the piece must already exist or which attachment method to choose. With multiple attachment-related methods in the schema (file_path, file_content), the description could clarify usage scenarios but doesn't.

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

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

No annotations are provided, so the description carries the full behavioral burden. It does not disclose visibility of the message, notification behavior, permission requirements, or whether the attachment is embedded in the message body — significant gaps for a mutation tool with zero annotation coverage.

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

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

A single front-loaded sentence with zero waste that states the resource, the action, and the attachment option. Nothing to trim.

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 schema is fully documented, so parameter details are covered, but for a mutation tool with no annotations and no output schema the description should say more about effects and the choice between this tool and AddAttachmentTool. It is minimally 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 description coverage is 100% and all six parameters are documented in the schema, including the file_path vs file_content distinction. The description only adds the phrase 'optional file attachment', so the baseline 3 is appropriate.

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

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

The description states a specific verb and resource ('Add a note/message to a task') plus the optional attachment capability, so the agent knows exactly what it does. However, it does not distinguish itself from the sibling AddAttachmentTool, which appears to overlap on the attachment dimension.

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, notably AddAttachmentTool, which sits right next to it in the sibling list and presumably handles files without a message. The overlap is left entirely for the agent to infer.

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

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

No annotations are provided, so the description carries the full disclosure burden for a state-mutating tool, and it falls short: it never says whether blocking affects scheduling/dependents, whether the change is reversible, who may perform it, or what happens to an already-blocked task. The only behavioral clue is 'temporarily', which is vague about duration or automatic unblocking.

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 waste, though it is arguably too terse given the tool's state-changing nature. Every word earns its place, which is the dimension's concern.

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 4-parameter mutation tool with no annotations and no output schema, the description is thin: it omits side effects, permissions, idempotency, and return behavior. The agent gets the gist but not enough to call this safely in edge cases.

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

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

Schema description coverage is 100% and the action enum is fully documented, so the schema already does the heavy lifting; baseline 3 applies. The description adds no extra nuance about the optional reason field or how account_code/task_relative_id scope the operation.

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 pair (block/unblock) and resource (task), plus the condition of temporary incompletability, so the agent knows exactly what changes state. It does not, however, distinguish itself from the sibling ManageBlockerLinksTool, which deals with a closely related 'blocker' concept and could plausibly be confused with this 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?

There is no statement of when to block versus unblock, no prerequisites (e.g., permissions or whether a reason is required), and no routing to any of the 21 siblings. The phrase 'cannot be completed temporarily' hints at the situation but is not actionable guidance.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose useful traits: blocked_by_relative_ids is additive (only adds links), already-linked ids are refused, and the call is all-or-nothing when an id fails to resolve. However, it says nothing about required permissions beyond the vague "full authorization controls," side effects (notifications, sprint quotas), or reversibility of creation.

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

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

Three sentences, front-loaded with the creation action and then the dependency semantics. Every sentence carries information, though the ManageBlockerLinksTool clause is dense and a short parenthetical or example would have been clearer than the run-on description of waiting/blocker roles.

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 creation tool with no annotations and no output schema, the description covers the main action, piece types, and the trickiest linkage parameter. Its main gap is that it never says what is returned (e.g., the new piece's relative_id), which matters for chaining follow-up calls, and it leaves authorization mechanics unspecified.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning beyond the schema for blocked_by_relative_ids — clarifying the direction of the dependency (this piece waits for the listed ids) and contrasting it with ManageBlockerLinksTool's piece_relative_id/blocker_relative_ids orientation. Other params (sprint_id, priority_code, etc.) are left entirely to 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 opens with a specific verb+resource: "Create new work items (Tasks, Stories, Epics, Recurents) in McpTask.online." It names the concrete piece types and distinguishes the tool from siblings like UpdatePieceTool and ManageBlockerLinksTool by scope (creation vs. link management).

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

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

It gives an explicit routing rule for dependencies: use blocked_by_relative_ids when declaring a new dependency on creation, and use ManageBlockerLinksTool to manage existing links. That is a clear alternative with a selecting condition, though it covers only the blocker-linking sub-case and offers no exclusions for the creation flow itself (e.g., when to prefer UpdatePieceTool).

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses role-based scoping of filters, which is useful authorization context, but omits whether the export is read-only/generating a file, how it is returned, or any rate/size limits.

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

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

Two tight sentences that front-load the action and output formats, then the scoping caveat. No wasted words, though it could be slightly more explicit about the format parameter's role.

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 7-parameter export tool with no output schema and no annotations, the description is minimal. It covers formats and scoping but leaves return behavior, file delivery, and read/mutation nature unaddressed.

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

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

Schema description coverage is 100% and every parameter is documented in the schema, including enums and formats. The description adds only the role-scoping caveat for filters, giving baseline 3 since the schema does the heavy lifting.

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

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

States a specific verb (Exports) and resource (timesheet report) plus the output formats, which is more than the name alone conveys. However, it does not differentiate from the sibling ListTimeSheetReportOptionsTool, which an agent might confuse with this 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?

The description implies usage (export a timesheet report) but gives no explicit when-to-use guidance or when to prefer this over ListTimeSheetReportOptionsTool. The role-scoping note is a conditional hint but 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?

No annotations are provided, so the description carries the full behavioral burden. It only enumerates what data is returned, omitting critical disclosure: whether the call is read-only (safe to retry), any required permissions, whether it can be expensive, or how missing accounts are handled. A read-only lookup should at least hint at safety, but that is absent.

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 that packs all necessary information without waste. It is appropriately sized for a one-parameter lookup tool and gets straight to the point.

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, no output schema, and a read-only operation, the description is insufficient. It does not cover error behavior, permissions, or any operational context. For a tool that fetches possibly sensitive account-level configuration, completeness is lacking.

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%; the single parameter account_code is fully documented in the schema with examples ('bcp', 'jchsoft'). The description repeats the parameter name but adds no syntax, format, or validation detail beyond what the schema already provides. 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?

States a clear verb+resource: retrieves account workspace details for a given account code. The description enumerates the specific sub-resources returned (attributes, users, projects, companies), which distinguishes it from unrelated siblings. But it doesn't explicitly contrast with siblings like GetProjectTool or GetCurrentUserTool, falling short of a 5.

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

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

The description implies usage by stating it takes an account code, but there is no explicit when-to-use/when-not guidance or named alternatives. Siblings like GetProjectTool exist, and an agent might confuse this tool with project-level lookups, but the description offers no routing help.

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

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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the return shape (metadata plus a direct download URL) and the deliberate avoidance of binary inlining, but says nothing about authentication, URL expiry, or error behavior for missing attachments.

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

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

A single, well-formed sentence that front-loads the primary output and appends the rationale in parentheses. 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?

With no annotations and no output schema, the description does a fair job of signaling the return payload (metadata + download URL). It is nonetheless thin for an unannotated read tool, omitting auth expectations and what happens on invalid IDs.

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 all three parameters (account_code, attachment_id, piece_relative_id) are already documented in the schema. The description adds no parameter-level detail beyond the generic phrase 'piece attachment', 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?

The description states a specific verb+resource: retrieving attachment metadata and a download URL for a piece attachment. This clearly differentiates it from the write-side sibling AddAttachmentTool, though it does not name any sibling explicitly.

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

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

The phrase 'avoids inlining binary content' implies why you'd call this rather than fetching the raw file, giving implied usage context. However, there is no explicit when-to-use/when-not guidance, no mention of alternatives, and no stated prerequisites for the three required parameters.

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 and no output schema, the description carries the full disclosure burden. It usefully enumerates what is returned and implicitly signals a read of the caller's own session, but never states that the call is read-only, side-effect free, or what happens if no user is authenticated.

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

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

One dense, front-loaded sentence that leads with the resource and then lists fields; nothing is wasted. The parenthetical cross-reference to task #11687 is slightly opaque but harmless.

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 no-argument read tool with no output schema, the enumeration of returned fields (including hour_goal, work_start, worked_out) is close to sufficient. Missing is any note on auth prerequisites or error behavior when no session exists.

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 per the baseline there is nothing for the description to compensate for. The field list it gives is about return values, not inputs, so it neither helps nor hurts input semantics.

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

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

Names a specific resource (the current authenticated user) and enumerates the payload: profile, accessible account codes, today's working hours, and the respect_working_hours flag. An agent can tell it apart from ListProjects/ListPieces, but it does not clarify how it differs from the sibling GetAccountTool despite both touching 'accounts'.

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

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

There is no explicit when-to-use, when-not-to-use, or alternative routing, even though GetAccountTool is an obvious nearby sibling. Usage is only inferable from the tool name being a zero-argument fetch of the caller's own identity.

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 and does add real behavioral detail: the deterministic ordering (priority, then errors, then age) and the fact that exclude_relative_ids is per-call and does not mutate piece state. It stops short of stating permissions, whether a null/empty result is possible, or what object is returned.

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

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

Two sentences, no filler, and the core behavior and ordering are front-loaded before the exclude_relative_ids advice. The second sentence is long but each clause carries load, so it stays 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?

No output schema exists, so the description should say what comes back (a piece object? null when nothing is available? blocked/deferred handling?), and it does not. Given a plain 3-parameter read tool with no annotations, this is an adequate but incomplete definition.

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 baseline is 3; the description goes beyond the schema by explaining the intent behind exclude_relative_ids (the 'stuck on the same piece' scenario) and by framing project_relative_id as an optional filter. This adds actionable meaning rather than repeating the field docs.

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 ('Get the next task or story to work on') and even encodes the selection algorithm (highest priority, errors first, oldest within priority). It is clearly distinguishable from ListPiecesTool/GetPieceTool by its 'next actionable item' semantics, though it never names those siblings to draw 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?

Gives a concrete usage context: optionally filter by project, and when you are waiting on something for a piece without formally blocking it, pass exclude_relative_ids to avoid looping. It does not, however, mention when to prefer BlockTaskTool instead of this skip-loop pattern, leaving one relevant 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?

No annotations, so the description carries the burden. It discloses the result cap (most recent 50 entries), which is useful behavioral context. It does not state whether it errors on missing pieces or is read-only, though the name implies a read.

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

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

One tight sentence, front-loaded with the resource and scope. Zero waste.

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-param read tool with a fully documented schema and no output schema, the description is minimally adequate. It lacks return shape and pagination/truncation beyond the 50-entry 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 100%, so both parameters are already documented in the schema. The description adds only what it already implies: that effort history is keyed by piece_relative_id. 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 (get/retrieve), resource (effort/time-tracking history), and scoping (by relative ID). Clearly a read retrieval tool. Not much sibling differentiation beyond the resource name, but the resource is distinctive enough.

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 versus alternatives. It implies retrieval by relative ID but does not name 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, so the description must carry the burden. It discloses the returned contents (subtasks, messages, attachments), which is useful behavioral context. However, it doesn't state auth needs, rate limits, or whether it fails for missing IDs.

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?

Single sentence that front-loads the action and key details with no waste.

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 read tool with a rich schema and no output schema, the description covers the essential purpose and return contents. Missing usage guidance and behavioral details, but adequate given the tool's simplicity.

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%: both account_code and piece_relative_id are fully described in the schema. The description doesn't add extra syntax or format details beyond what the schema provides, so 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?

States a specific verb (Read), resource (a single piece), and entity types (Task/Story/Epic/Recurent), with the keying mechanism (relative ID). Clearly distinguishes from siblings like ListPiecesTool by scoping to 'a single piece' and enumerating returned sub-resources (subtasks, messages, attachments).

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: read one piece by relative ID. But no explicit when-to-use vs alternatives (e.g., ListPiecesTool for multiple, GetAttachmentTool for attachments only). No prerequisites or exclusions 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 carries the burden, and it does disclose the content returned (options, users with roles, task summary), which implies a read operation. However, it says nothing about permissions/account scoping requirements, side effects or absence thereof, or response shape beyond the field 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?

One compact sentence with the lookup key and returned content front-loaded; nothing is wasted. The noun-phrase opening ('Extended project information') lacks an explicit verb, a minor clarity cost.

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 tool with no output schema and no annotations, the description should at least carry the return-value and safety burden. It lists returned fields, which helps, but omits permission/account context and any routing guidance to alternatives.

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 account_code and project_relative_id are already documented in the schema. The description only reinforces 'by relative ID'; it adds no format or constraint detail beyond the structured fields, 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?

The description identifies the resource (a project), the lookup key (relative ID), and the payload (options, users with roles, task summary), so an agent knows this returns an extended detail view. It does not explicitly distinguish itself from near-siblings like GetProjectTreeTool or ListProjectsTool, which weakens it slightly.

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

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

There is no statement of when to use this tool versus ListProjectsTool/GetProjectTreeTool, nor prerequisites such as needing a project relative ID already obtained elsewhere. Usage is only implied by the 'by relative ID' phrasing.

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 must carry the behavioral burden. It does disclose the return model (compact nodes with id, kind, type, children_count, shortened name) and the hierarchy levels, but says nothing about permissions, tree size/depth limits, ordering, or truncation behavior for a potentially large tree.

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

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

Two compact sentences, front-loaded with what the tool returns, then the node contract. Every clause carries information and none is redundant.

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

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

There is no output schema, so the description reasonably compensates by naming the node fields and the hierarchy levels. It falls slightly short on scale/limits and error behavior, but an agent can call the tool correctly from what is given.

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%: account_code and project_relative_id are both documented in the schema. The description adds no parameter-level detail (e.g., how the relative id is obtained or the account-code format), so the baseline of 3 applies.

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

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

The description states a specific verb+resource ('Hierarchical tree of a project') and pins down the domain model (Root -> Epic -> Story terminal) plus the node shape. This distinguishes it from GET-project or list-projects siblings by virtue of the hierarchy, though it never names those siblings explicitly.

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

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

There is no statement of when to use this tool versus GetProjectTool or ListProjectsTool. The hierarchical framing implies a use case (understanding structure) but no condition, prerequisite, or exclusion is given.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return format (markdown) which is helpful, but omits whether the content is static or dynamic, whether it requires auth, and any versioning. Adequate but sparse.

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

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

A single, tight sentence that front-loads the resource and clarifies it in a parenthetical. 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 no-arg meta tool the description is minimal but sufficient. It could say more about what the guide covers or when it is refreshed, but nothing an agent strictly needs 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?

Zero parameters, so the baseline is 4. The description correctly implies no arguments are needed, and the schema is trivially complete.

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 (usage guide) and clarifies the resource is 'how to use this MCP server' in markdown. It is distinguishable from all siblings, which are domain operations, but the phrasing 'McpTask.online usage guide' is slightly branded/opaque.

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 or when-not-to-use guidance, and no alternatives named. Usage is self-evident from the name and description for a meta/tutorial tool, but the definition offers no routing cues.

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

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

No annotations are provided, so the description carries the full burden. It discloses that results are paginated, but says nothing about permissions, rate limits, result ordering, or what a page contains and how to detect the end of the list. For a list tool with zero annotation coverage this is thin.

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

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

Two short sentences, front-loaded with the scope statement followed by the practical tip; nothing is padded. Minor misspelling ('Recurents') and the lack of any second sentence on return shape keep it from a 5.

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

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

With no annotation and no output schema, the description must at least imply the pagination contract, and it only states that results are paginated without explaining how to move through pages or what a page holds. Adequate for the basic call, incomplete for correct iteration.

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 page, size, and account_code are already fully documented with defaults and bounds. The description's size advice adds a small amount of practical meaning but largely restates the default value, fitting the baseline 3 when the schema does the heavy lifting.

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

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

Names a specific verb (list) and resource (pieces), and disambiguates the jargon by enumerating what a 'piece' is (Tasks, Stories, Recurents), scoped to an account. It does not explicitly contrast with siblings like ListProjectsTool or GetPieceTool, 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?

Offers operational advice ('Start with size 10; use size 5 for large pieces') but this is tuning guidance, not when-to-use guidance. Nothing says when to call this versus GetPieceTool for a single item or ListProjectsTool for projects, so usage is only implied.

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

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

No annotations exist, so the description carries the full burden, yet it discloses no behavioral traits beyond the user-scoping hint: no pagination, no permission requirements, no sort order, no result limits. The 'current user's' scoping is the only real signal.

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. It is appropriately sized for a simple list tool, though it is arguably too terse to be maximally useful.

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 list tool with full schema coverage and no output schema, the definition is minimally adequate. However, with no annotations and no output schema, it should at least describe the returned shape or whether results are paginated/empty-case behavior.

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

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

Only one parameter and schema description coverage is 100%, so the schema already explains account_code with examples. The description adds nothing about the parameter beyond implying it filters by account, which is the baseline for full schema coverage.

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

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

States a specific verb (List) and resource (projects) with an explicit scope qualifier ('current user's ... under an account'). It is distinguishable from GetProjectTool (single project) and GetProjectTreeTool (hierarchy), though it does not name those siblings to reinforce the distinction.

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

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

There is no when-to-use guidance, no conditions, and no mention of alternatives such as GetProjectTool or GetProjectTreeTool. The usage is only inferable from the tool name and the phrase 'under an account'.

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 the description carries the burden. It adds useful behavioral context: values are scoped to the authenticated user's role, which is a non-obvious access-control detail. However, it doesn't disclose that this is a read-only operation, whether it's cached, or what the return shape is (no output schema exists).

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-loaded with the action and resource, then the access-scoping caveat. No wasted words, no redundancy.

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

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

For a simple read-only discovery tool with no output schema and fully documented params, the description is adequate but leaves gaps: it doesn't clarify the relationship to ExportTimeSheetReportTool, nor does it describe the return format (an agent won't know if it gets enum lists, objects, or labels).

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 account_code, from, and to with formats and defaults. Baseline is 3 per the rubric when coverage is high and the description adds no parameter-level syntax or format details.

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 (Lists) and resource (available filters for the timesheet report), and enumerates the filter categories (date range, companies, projects, workers, report layout). It's clear what the tool does, though it doesn't name a sibling to differentiate from — the closest sibling is ExportTimeSheetReportTool, and the description doesn't explicitly contrast with 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?

Implied usage — an agent can infer this is a discovery/meta tool to call before ExportTimeSheetReportTool, but the description never states when to use it or that it's a prerequisite/companion to the export tool. No explicit when/when-not guidance.

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

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

No annotations are provided, so the description carries the full burden. It hints at 'automatic task state management' but does not explain what that means (state transitions, side effects, permission requirements, reversibility). For a mutation tool with zero annotation coverage, this is a significant gap.

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. Every word 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?

With no annotations, no output schema, and no usage guidance, the description is incomplete for a 5-parameter mutation tool. It should explain what 'automatic task state management' entails and when to use this tool instead of siblings.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters. The description adds no additional meaning about parameter formats, constraints, or optionality beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.

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

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

States a clear verb (Log) and resource (work progress) with an additional behavior (automatic task state management). Distinguishes from siblings like UpdatePieceTool or AddMessageTool, though it does not explicitly name an alternative.

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

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

No guidance on when to use this tool versus alternatives such as UpdatePieceTool or ManageBlockerLinksTool. The only contextual clue is 'performed by the agent', which is helpful but insufficient.

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 of behavioral disclosure. It mentions that one bad id rejects the whole call, which is useful transactional behavior, but omits critical details such as required permissions, side effects, reversibility, or return values.

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 front-load the core action and then immediately disclose the key transactional constraint. Every sentence earns its place with no waste.

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 tool with no annotations and no output schema, the description is incomplete. It should cover permissions, side effects, and return behavior to adequately guide an agent, but instead provides only minimal operational context.

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

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

Schema coverage is 100%, so the schema already documents all parameter semantics in detail. The description adds no additional meaning about parameters beyond repeating the batch rejection behavior. Baseline 3 is appropriate when schema does the heavy lifting.

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

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

The description states a specific verb (add or remove) and resource (blocked_by links on a piece). It clearly distinguishes the blocking concept from sibling tools like BlockTaskTool, though it does not name the sibling. Overall purpose is clear but sibling differentiation could be more explicit.

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

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

The description provides no guidance on when to use this tool versus alternatives like BlockTaskTool or UpdatePieceTool. It only describes what the tool does, not the context or prerequisites for its use.

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

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

No annotations exist, so the description carries the full burden, and it delivers substantive traits: a rate limit of 3/day, refusal of suppressed and duplicate (dedupe_key) recipients, and that no footer/logo/tracking is injected. It still omits what a successful or failed send returns and whether dedupe persists across accounts.

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 that front-load the primary action and then the operational constraints. Every clause earns its place with zero 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 mutation tool with no annotations and no output schema, the description covers the key behavioral surface (rate limit, suppression, dedupe, sender identity, no tracking). It is complete enough to invoke correctly, with only minor gaps around failure/return behavior.

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

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

Schema description coverage is 100%, so the schema already documents all 7 parameters clearly. The description reinforces plain-text preference and the dedupe_key mechanism but adds little semantics beyond the schema's own parameter descriptions. 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?

States a specific verb+resource ('Send a personalized outreach email') and clarifies the sending channel ('from your own address through the outreach pipeline'), which distinguishes it from generic message siblings like AddMessageTool. An agent can tell exactly what it does without opening the schema.

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

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

Gives clear context: it prefers plain text for personalization and sends through the outreach pipeline. It does not explicitly name an alternative tool or when-not-to-use, but the 'refuses suppressed and already-contacted' constraint effectively scopes valid usage.

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

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

With no annotations, the description carries the full burden and does so well: partial-update semantics (omitted attributes untouched), a stated return shape (before/after per attribute), additive link behavior, rejection of already-linked ids, and all-or-nothing resolution failure. These are non-obvious behaviors an agent would otherwise have to discover by trial.

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 purpose and behavior, and the final sentence usefully disambiguates the blocker-link direction. The dependency sentence is somewhat dense but each clause carries distinct information; 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 12-parameter mutation tool with no annotations and no output schema, the description supplies the missing behavioral and return-value context, plus the alternative-tool pointer. Nothing essential to correct invocation appears to be missing.

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

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

Schema description coverage is 100%, so every parameter already documents omit-to-leave-unchanged, ID-vs-relative_id, type restrictions, and unassign-by-zero. The description's parameter-level notes (blocked_by_relative_ids) largely restate what the schema already says, so it adds little beyond the structured field.

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 ("Update"), the resource (Task, Story, Epic, Recurent), the keying attribute (relative_id), and the scope of mutation (only mutable attributes). An agent can immediately distinguish it from CreatePieceTool, GetPieceTool, and ManageBlockerLinksTool.

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

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

Explicitly routes link removal to ManageBlockerLinksTool and clarifies the role semantics there (piece_relative_id is the WAITING piece). It also states that this tool is where dependencies are declared, so it covers both when-to-use and when-not-to-use.

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