Server Quality Checklist

Tool Scores

• paymo_add_commentB
  3.1/5.0
  Behavior1/5

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

  With no annotations, the description carries the full burden of behavioral disclosure, but it only states the action. It does not mention side effects, authentication requirements, or behavior like HTML rendering, which is only disclosed in the schema parameter description.

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

  Conciseness5/5

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

  The description is a single, concise sentence that is front-loaded and free of unnecessary words. It earns its place by clearly stating the tool's purpose.

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

  Completeness3/5

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

  The tool is relatively simple with only two well-documented parameters. However, as a write operation with no annotations or output schema, the description omits important context such as error conditions and response behavior, making it minimally complete but with clear gaps.

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

  Parameters3/5

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

  The input schema provides complete descriptions for both parameters, including the acceptable formats for task id and the HTML rendering behavior for content. The description adds no additional parameter semantics, but the baseline for high schema coverage is 3.

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

  Purpose5/5

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

  The description uses a specific verb ('Add') and object ('comment') with a clear target ('Paymo task'). This distinguishes it clearly from sibling tools like create_task and update_task, which operate on tasks rather than comments.

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

  Usage Guidelines2/5

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

  The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention that this is for adding comments as opposed to creating or updating tasks, nor any prerequisites or exclusions.

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

• paymo_list_tasksB
  3.1/5.0
  Behavior2/5

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

  With no annotations, the description carries the burden of disclosing behavioral traits. It only mentions the default incomplete/project scope, which is already conveyed by the schema, and does not state that the operation is read-only, how pagination behaves, or the context cost of large listings. Minimal behavioral context is provided.

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

  Conciseness4/5

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

  The description is a single brief sentence, front-loaded with the verb and resource, containing no filler. It is efficient and readable, though it omits behavioral detail that could have been included without much extra length.

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

  Completeness2/5

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

  With no output schema and no annotations, the description does not explain what fields a returned task includes, how paging works, or the effect of verbose mode. The rich parameter schema helps for parameters, but the overall tool context remains thin, leaving the agent to infer important runtime behavior.

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

  Parameters3/5

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

  The input schema has 100% description coverage for all five parameters, so the tool description does not need to repeat them. The phrase 'configured project' and 'incomplete tasks' aligns with project_id and include_completed defaults but adds no new meaning beyond the schema. Baseline 3 is appropriate.

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

  Purpose4/5

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

  The description clearly states the action (List) and resource (tasks), and notes the default scope (incomplete tasks, configured project). It is specific, but it does not explicitly differentiate from sibling tools like paymo_get_task or paymo_list_tasklists.

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

  Usage Guidelines3/5

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

  The description implies usage for listing tasks and highlights the default behavior, but it provides no explicit guidance on when to prefer this tool over alternatives such as get_task or list_tasklists, nor any exclusions. This is implied usage rather than clear directives.

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

• paymo_list_projectsA
  3.5/5.0
  Behavior3/5

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

  With no annotations, the description is the only source of behavioral context. It mentions 'documented field subset' and access filtering, but does not disclose side effects, permissions, or data volume. The note about the field subset is helpful but minimal.

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

  Conciseness5/5

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

  The description is a single sentence with no redundant wording. It is front-loaded with the main action and resource, and every word contributes to meaning.

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

  Completeness3/5

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

  With no output schema, the description is relatively thin. It does not specify the return format, the contents of the documented field subset, or pagination behavior, though pagination is partially covered by the schema. It is adequate but not complete.

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

  Parameters3/5

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

  The input schema has 100% coverage with detailed descriptions for all four parameters, so the schema does the heavy lifting. The description adds no additional parameter semantics beyond what is already in the schema.

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

  Purpose5/5

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

  The description clearly states the action (List), the resource (Paymo projects), and the scope (user has access to). It distinguishes itself from sibling tools like paymo_list_tasks and paymo_list_tasklists by focusing specifically on projects.

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

  Usage Guidelines2/5

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

  No guidance is provided on when to use this tool versus alternatives. The description does not mention any exclusions, prerequisites, or situations where another tool would be preferred.

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

• paymo_list_tasklistsA
  3.5/5.0
  Behavior2/5

  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 implies a read-only operation with 'List', but does not explicitly state that it is non-destructive, nor does it mention potential performance costs when querying across all projects. The schema's warning about expensive large listings is not echoed in the description.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence with no unnecessary words. It immediately conveys the action and resource, and the parenthetical clarification efficiently disambiguates the term 'tasklists'.

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

  Completeness3/5

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

  For a simple list tool, the purpose and scoping are clear, but with no output schema or annotations, the description leaves gaps around return values and operational risks (e.g., large result sets when project_id is unset). The rich schema descriptions partially compensate, but the description itself is minimal.

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

  Parameters3/5

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

  The schema covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds context for project_id by noting 'across all tasks when unset', but the schema already states 'Restrict to a single project', so the added value is minimal.

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

  Purpose5/5

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

  The description clearly states the verb 'List' and the resource 'tasklists (columns)', and adds scoping detail ('for a project, or across all tasks when unset'). This distinguishes it from siblings like paymo_list_tasks and paymo_list_projects, which target different resources.

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

  Usage Guidelines3/5

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

  The description implies usage context by explaining the project scoping option, but it does not explicitly mention alternatives or when not to use this tool. Sibling tools are visible but not referenced, leaving the agent without explicit selection criteria.

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

• paymo_get_taskA
  3.7/5.0
  Behavior2/5

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

  No annotations are provided, so the description must disclose behavioral traits. It only states the action and identification method, omitting details on read-only behavior, error handling, or return format, leaving the agent uninformed about what happens on not-found or what fields are returned.

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

  Conciseness5/5

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

  A single sentence, no wasted words. It delivers the essential purpose quickly and is appropriately sized for a simple fetch operation.

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

  Completeness3/5

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

  Given a simple read tool with complete schema, the description covers the core purpose. However, without an output schema, the absence of return-value or error information leaves some gap, but overall sufficient for a basic fetch.

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

  Parameters3/5

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

  The input schema fully describes both parameters (task and verbose) with clear descriptions, so the baseline is 3. The description does not add additional meaning beyond restating that the task can be numeric or human code, already covered in the schema.

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

  Purpose5/5

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

  The description clearly states a specific verb ('Fetch') and resource ('Paymo task') with identification method (numeric id or human code), distinguishing it from sibling tools like paymo_list_tasks which list multiple tasks.

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

  Usage Guidelines4/5

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

  It implies usage when you have a specific task identifier, but does not explicitly contrast with alternatives like list_tasks for retrieval of multiple tasks. The context is clear enough for selection.

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

• paymo_create_taskA
  3.8/5.0
  Behavior2/5

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

  No annotations are provided, so the description must disclose behavioral traits. It indicates the operation is a 'Create' (implying mutation) and lists required prerequisites, but it does not describe side effects, response behavior, error conditions, or any constraints beyond parameter requirements. It leaves the agent unaware of what happens on success or failure, which is a significant gap for a write operation.

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

  Conciseness5/5

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

  The description is three sentences with no redundant information. It front-loads the primary purpose, states the essential requirements, and lists optional fields efficiently. Every sentence earns its place, and the structure is easy to parse.

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

  Completeness4/5

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

  For a create tool with 7 parameters and no output schema, the description gives a solid high-level overview. It covers the required fields and optional parameters, and the schema fills in detailed constraints. It does not explain return values, but the absence of an output schema reduces the expectation. Minor gaps remain around behavioral details, but overall it is adequately complete.

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

  Parameters3/5

  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 description adds a concise summary of required vs. optional parameters but does not provide meaning beyond the schema. It repeats priority values and due-date format already present in the schema, adding no new semantic detail.

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

  Purpose5/5

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

  The description clearly states the tool's function: 'Create a new Paymo task.' It specifies the resource (task) and the action (create), distinguishing it from sibling tools like paymo_update_task and paymo_get_task. The explicit mention of required fields (name, project_id/tasklist_id) further clarifies the tool's scope.

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

  Usage Guidelines4/5

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

  The description provides clear usage context by stating the mandatory parameters (name and one of project_id/tasklist_id) and listing optional fields. However, it does not explicitly contrast with alternatives (e.g., when to use paymo_update_task instead) or state exclusions. Since it's a create operation, the prerequisites are clear enough for basic guidance.

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

• paymo_list_workflow_statusesA
  3.8/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries the full burden for behavioral disclosure. It only lists the returned fields and does not mention any behavioral traits such as cost, pagination behavior, or side effects. The input schema contains some behavioral notes, but the description itself lacks this context.

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

  Conciseness5/5

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

  The description is a single, front-loaded sentence that efficiently communicates the tool's purpose and a key use case. There is no redundant information, and every part earns its place.

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

  Completeness4/5

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

  The tool is simple, with clear purpose and well-documented parameters. The description also lists the output fields and use case, making it reasonably complete despite the lack of annotations. It could mention pagination or side effects, but these are not critical for understanding this tool.

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

  Parameters3/5

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

  Schema coverage is 100%, with detailed descriptions for limit, offset, and verbose. The description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool lists workflow statuses in Paymo, with a specific verb 'List' and resource 'workflow statuses'. It also notes the returned fields and a concrete use case, making its purpose unambiguous and distinct from sibling tools which deal with tasks, projects, or timers.

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

  Usage Guidelines4/5

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

  The description gives a specific use case ('map status_id to a human name') which implies when to use it. It does not explicitly state exclusions or alternative tools, but the sibling context makes it clear this is the only status-listing tool, so the guidance is adequate.

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

• paymo_meA
  4/5.0
  Behavior4/5

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

  With no annotations, the description carries the full burden. It clearly discloses read-only behavior via 'Returns' and lists specific fields. It does not mention authentication or potential side effects, but for a simple read-only endpoint this is adequate transparency.

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

  Conciseness5/5

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

  The description is a single, focused sentence that front-loads the verb and resource, with no wasted words or redundant information.

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

  Completeness4/5

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

  The tool is simple, with one optional parameter and no output schema. The description lists the return fields, which is sufficient for the agent to understand the result. It does not explain the field-subset behavior controlled by 'verbose', but that is already in the schema, so the description is complete enough.

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

  Parameters3/5

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

  Schema coverage is 100% for the single 'verbose' parameter, which has its own description. The tool description adds no additional parameter context, but the schema fully documents the parameter, so the baseline score of 3 is appropriate.

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

  Purpose5/5

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

  Description uses a specific verb ('Returns') and resource ('authenticated Paymo user') and lists the exact fields returned, making it clear and distinct from sibling tools that operate on tasks, projects, timers, etc.

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

  Usage Guidelines3/5

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

  The description does not explicitly state when to use this tool or provide alternatives, but the purpose is strongly implied by the name and description. No exclusion or selection guidance is given, so it stops at implied usage.

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

• paymo_timer_statusA
  4.1/5.0
  Behavior4/5

  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 clearly explains the return behavior, including the null case when no timer is active. Although it does not explicitly state that the operation is read-only or has no side effects, the 'Returns' language makes it evident for a status query.

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

  Conciseness5/5

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

  The description is a single, well-structured sentence that front-loads the primary purpose and includes the critical null behavior. There is no redundant or unnecessary text.

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

  Completeness5/5

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

  For a simple status-check tool with one optional parameter, the description is complete. It specifies the scope (authenticated user), the output (running time entry or null), and the schema covers the verbose parameter. No additional context is needed.

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

  Parameters3/5

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

  The input schema fully documents the only parameter 'verbose' with a clear description of its effect. The tool description adds no additional meaning about the parameter, so the baseline of 3 is appropriate given 100% schema coverage.

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

  Purpose5/5

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

  The description clearly states the tool's function: it returns the currently running Paymo time entry for the authenticated user, or null if no timer is active. This is a specific verb+resource combination and is distinct from sibling tools like start_timer and stop_timer, which perform actions rather than queries.

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

  Usage Guidelines3/5

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

  The description implies the tool is used to check the current timer status, especially in contrast to starting or stopping a timer. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusion criteria.

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

• paymo_update_taskA
  4.1/5.0
  Behavior3/5

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

  The description reveals a critical behavior—that Paymo forces status to Complete/Backlog and will overwrite the status argument. However, the schema for the complete parameter already notes that it resets status, so this is partially redundant. It adds explanatory detail but lacks other behavioral disclosures like permissions or partial update semantics.

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

  Conciseness5/5

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

  The description is two sentences, front-loaded with the primary purpose. Every sentence earned its place, with no wasted words.

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

  Completeness3/5

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

  The schema covers all parameter descriptions, but the tool description does not explain whether omitted fields are left unchanged, nor does it describe the return value. These are important for an update tool, especially without an output schema. The description covers the main pitfall but leaves these gaps.

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

  Parameters4/5

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

  The description clarifies the status parameter by specifying 'numeric id or a slug alias' with an example (in_progress), which is more concrete than the schema's 'Workflow status id or alias.' It also highlights the cross-parameter conflict with complete. With 100% schema coverage, the baseline is 3, but the added example and interaction guidance elevate it.

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

  Purpose5/5

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

  The description opens with 'Update a Paymo task,' clearly stating the action and resource. This distinguishes it from sibling tools such as paymo_create_task and paymo_get_task.

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

  Usage Guidelines4/5

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

  The description provides an explicit instruction not to send complete and status together, explaining the forced status behavior. It does not mention alternative tools for other scenarios, but the primary usage context is clear.

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

• paymo_start_timerA
  4.2/5.0
  Behavior4/5

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

  No annotations are provided, so the description carries the burden. It discloses the key behavior that any running timer is closed first to avoid concurrency, which goes beyond a simple 'start' and adds real value. It does not detail response format or error cases, but these are not essential for a tool this simple.

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

  Conciseness5/5

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

  Two sentences, front-loaded with the action, and every word adds value. Extremely concise and easy to scan.

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

  Completeness4/5

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

  Given the tool has only one parameter, no output schema, and a clear behavioral note, the description is adequately complete. It covers purpose, parameter (via schema), and an important side effect. Missing return-value details are minor.

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

  Parameters3/5

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

  Schema coverage is 100%, with the 'task' parameter clearly described as a numeric id or human task code. The description does not add additional parameter context, but the schema already covers it, so the baseline score of 3 is appropriate.

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

  Purpose5/5

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

  The description clearly states the tool starts a Paymo time entry on a task, using a specific verb and resource. It distinguishes itself from siblings like paymo_stop_timer and paymo_timer_status by focusing on the start action.

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

  Usage Guidelines4/5

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

  The purpose is self-evident from the name and description, and it implies a direct alternative to stopping/timing. It mentions the concurrency behavior but does not explicitly say when to use it over other timer-related tools, though the context makes it obvious.

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

• paymo_stop_timerA
  4.7/5.0
  Behavior4/5

  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 important behaviors: it is a no-op if no entry is active, and it may refuse to stop entries under a minute old. This goes beyond the basic action and helps the agent anticipate outcomes.

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

  Conciseness5/5

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

  The description is compact: two sentences, front-loaded with the primary action, followed by essential edge cases. Every sentence earns its place; no redundant or peripheral information.

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

  Completeness5/5

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

  For a simple tool with no parameters and no output schema, the description covers all necessary context: the operation, the no-op case, a potential failure mode, and an alternative tool. It is complete for an agent to decide when and how to invoke it.

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

  Parameters4/5

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

  The input schema shows zero parameters (100% schema coverage). With no parameters to explain, the baseline is 4. The description correctly makes no parameter-related claims, and no additional parameter semantics are needed.

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

  Purpose5/5

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

  The description clearly states the action: stop the running Paymo time entry of the authenticated user. It is specific (verb+resource) and distinguishes itself from siblings like paymo_start_timer and paymo_timer_status by focusing on stopping the time entry.

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

  Usage Guidelines5/5

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

  Explicit when-to-use instructions are present: stopping the running time entry. It also provides a clear when-not-to-use and alternative: if the entry is under a minute old, Paymo may refuse the stop, so delete it with paymo_delete_entry instead.

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