Server Quality Checklist

Tool Scores

• teamline_tasks_createA
  3.6/5.0
  Behavior3/5

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

  Annotations already indicate readOnlyHint=false and destructiveHint=false, so the description doesn't need to repeat those. It adds the token source (TEAMLINE_API_KEY) and the constraint that channel is required when list is set, but does not disclose return values, error behavior, or side effects beyond creation. This is adequate but not rich.

  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 two sentences, front-loaded with the purpose and required field, then a compact list of optional parameters. It is efficiently structured and free of fluff, though some information duplicates the schema.

  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 create operation with 8 parameters and no output schema, the description covers required/optional fields and key constraints. However, it does not describe what the API returns (e.g., a task object with an id) or error cases, which are important for agents to confirm success. This is a notable gap for completeness.

  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 all parameters are already documented. The description restates parameter types and constraints but adds little beyond the schema, such as the token source and the channel-required-if-list rule. Since the schema carries the main semantic load, this is a baseline 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 explicitly states 'Create a Teamline task via tasks.create', clearly identifying the verb and resource. It distinguishes this tool from siblings like list and complete by focusing on creation, so an agent can select it appropriately.

  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 for creating tasks but does not explicitly contrast it with alternatives like teamline_tasks_list or teamline_tasks_complete. It provides no 'when not to use' guidance or references to sibling tools, so usage context is only implied.

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

• teamline_tasks_completeA
  3.7/5.0
  Behavior3/5

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

  Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the agent knows this is a mutating but non-destructive operation. The description adds the auth detail (token from TEAMLINE_API_KEY) and the API method name, but does not disclose any side effects, error behavior, or consequences of completion beyond the obvious state change. It neither contradicts annotations nor adds significant behavioral context.

  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 brief and front-loaded with the action ('Mark a Teamline task complete'). The subsequent sentences about the API method and token source are useful but could arguably be merged or trimmed without losing clarity. It is concise overall, with no redundant filler, though the token sentence is somewhat tangential.

  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 simple one-parameter tool with no output schema, the description covers the essential purpose, the required parameter, and an auth note. It does not specify the return value or any side effects, but given the annotations carry the safety profile and the tool's simplicity, this is mostly complete. The absence of output schema information is acceptable since the tool likely returns a standard success/failure response that an agent can infer.

  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% and the single parameter 'task' already has a clear description ('Id of the task to complete'). The description repeats this by saying 'Requires task (id string)', which adds no additional meaning. Per the rubric, with high schema coverage the baseline is 3, and the description does not enhance the parameter's semantics.

  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 states a specific verb and resource: 'Mark a Teamline task complete'. This unambiguously distinguishes it from siblings like teamline_tasks_list or teamline_tasks_create. The action is clear and the resource is named, so an agent knows exactly what this tool does without needing to inspect the schema.

  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 by stating the tool completes a task, but it does not explicitly say when to use it versus alternatives, nor does it mention any conditions for exclusion. There is no mention of prerequisites like an existing task or case where this should not be used. It is adequate for a tool whose purpose is inherently straightforward, but explicit guidance is missing.

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

• teamline_webhooks_removeA
  4/5.0
  Behavior4/5

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

  Annotations already mark this as destructive (destructiveHint: true) and not read-only, so the safety profile is covered. The description adds valuable context by stating that the token is read only from the TEAMLINE_API_KEY environment variable, which is not present in annotations. It also names the API method, providing a behavioral detail beyond the structured fields.

  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 extremely concise—two short sentences that immediately state the action and the critical auth requirement. Every word earns its place, with no extraneous information or filler.

  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 single-parameter deletion tool with destructive annotations, the description adequately covers the purpose, required input, and auth mechanism. It does not mention return values, but there is no output schema specified, and for a removal operation this is minor. The only slight gap is the lack of clarity on whether the removal is permanent, but the destructiveHint annotation implicitly covers this.

  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 'hook' parameter with a description ('Id of the hook to remove'), so schema coverage is 100%. The description repeats this by saying 'Requires hook (id string)' but adds no new semantic detail. Baseline 3 is appropriate as the schema already handles parameter meaning.

  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 'Remove' and the resource 'Teamline webhook', and specifies the underlying method 'webhooks.remove'. This distinguishes it from the sibling 'teamline_webhooks_create' and other task-related tools, leaving no ambiguity about what the tool does.

  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 indicates the action and the required parameter but lacks any explicit guidance on when to use this tool versus alternatives. There is no mention of scenarios like deleting obsolete webhooks or when not to use it, though the auth prerequisite (TEAMLINE_API_KEY) is noted. The usage context is implied by the name and action rather than stated.

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

• teamline_tasks_listA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare read-only and non-destructive. The description adds behavioral specifics: defaulting to the current user when channel/user omitted, the requirement that channel be present when list is set, and the token source (TEAMLINE_API_KEY). These go beyond the annotation hints and clarify default behavior not obvious from the schema.

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

  Conciseness4/5

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

  Single dense sentence front-loaded with the action ('List Teamline tasks via tasks.list') then packs filter definitions. It is efficient but slightly run-on; grouping could improve readability. Still, every word 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?

  With rich annotations (readOnly, non-destructive, idempotent) and a full parameter schema, the description covers the key default behavior (defaults to self), required dependencies, and token source. No output schema exists, so return format isn't expected. Minor gaps like pagination details are not critical for this operation.

  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?

  Schema coverage is 100%, but the description adds valuable format details (e.g., '#name' for channel, '~name' for list, '@name/email/slackId' for user) and the dependency that channel is required if list is used. This enriches the schema without redundancy, so above baseline.

  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 begins with a clear verb+object:

  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?

  No explicit guidance on when to use this tool versus siblings like teamline_tasks_create or teamline_tasks_complete. The purpose implies listing, but there is no direct comparison to alternatives or conditions that would favor this tool. However, the distinct names make inference easy.

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

• teamline_auth_testA
  4.3/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds value by specifying the return shape (user id, name, email) and that the token is read from the environment, providing context beyond the annotations without contradiction.

  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 concise sentences with no redundant wording. It front-loads the core action and return information immediately, then adds the environment token detail. Every word earns its place.

  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, this description is fully self-contained. It explains the purpose, return fields, and the environment dependency. Combined with annotations covering read-only and idempotent behavior, an agent has everything needed to call it correctly.

  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?

  There are zero parameters, so the baseline is 4. The description explicitly states 'Takes no arguments' and clarifies that the API token is read from the environment, effectively documenting the implicit input channel beyond the empty 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 verb 'Verify' against a specific resource 'Teamline auth.test' and explicitly lists the return fields (id, name, email). It is distinct from sibling tools that handle tasks and webhooks, making its purpose unambiguous.

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

  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 stating it verifies the API key and reads from environment, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. The context is clear enough but lacks explicit routing guidance.

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

• teamline_webhooks_createA
  4.3/5.0
  Behavior5/5

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

  Beyond the annotations, it discloses a key architectural caveat: the server registers the URL, but the MCP stdio process will not receive Teamline POSTs. It also states the API token is read only from TEAMLINE_API_KEY and that only tasks_completed is official, all useful behavioral context.

  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?

  Four short sentences, all substantive, with the core registration action and event constraint front-loaded. The required/optional note slightly repeats schema information, but the architecture and auth notes earn their 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?

  For a three-parameter creation tool with annotations and full schema coverage, the description supplies the necessary auth source, event restriction, and server-side behavior. It omits return/error details, but no output schema exists and the missing info is not essential for invoking the tool.

  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?

  Schema coverage is 100%, so the schema already documents all three parameters. The description adds value beyond it by explicitly marking url required and name optional and by constraining event to tasks_completed, which is the main semantic guidance an agent needs.

  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 a concrete verb-resource pair ('Register a user-provided URL via webhooks.create') and immediately narrows scope to the only supported event, tasks_completed. This is enough to distinguish it from the remove sibling and from the task tools.

  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?

  It gives clear context for the create action and the supported event, so an agent can infer when to use it. However, it does not state when not to use it or point to webhooks_remove or another alternative, leaving routing to inference.

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