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

Discloses behavior beyond annotations: 'makes NO Weeek API call (no token required, no network)', explaining why it works even with a missing or expired token. This aligns with the readOnlyHint and idempotentHint annotations, adding useful context about auth and network independence.

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

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

Three concise sentences: purpose, distinction from siblings, and usage guidance. All content is relevant and front-loaded, with no filler.

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

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

The description fully covers the tool's behavior, usage context, and edge cases (missing token). The tool is simple, and the description is complete given the schema and annotations.

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

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

The schema describes msg as 'Message to echo back', and the description adds how it appears in the output: 'returns pong: <msg>'. This enriches the parameter semantics without being verbose, exceeding the 100% schema coverage baseline.

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

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

The description clearly states the tool's purpose: 'PRIMARY tool for connection sanity-check: returns pong: <msg>'. It also distinguishes itself from siblings by explicitly stating it makes no Weeek API call, unlike weeek_get_me.

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

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

Provides explicit guidance: 'Use when the agent first connects to verify the MCP transport itself is alive before reaching for any weeek_* tool.' Also contrasts with weeek_get_me, clarifying when not to use it.

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

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

Annotations already cover readOnly, idempotent, and non-destructive behavior. The description adds behavioral context by noting the tool makes a live network call and 'proves both transport AND credentials,' which is beyond what annotations express. It does not describe failure modes but the output schema covers the response.

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 three concise sentences, front-loaded with 'PRIMARY tool for confirming' which immediately conveys the main purpose. Each sentence adds distinct value: purpose, return shape, and usage distinction. No redundant or extraneous wording.

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

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

Given the tool's simplicity (no parameters, output schema present), the description covers the essential context: what it does, when to use it, and how it differs from ping. The return values are also summarized even though an output schema exists. There are no significant gaps.

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 has zero parameters, and schema coverage is complete at 100%. Per the baseline for zero-parameter tools, a score of 4 is appropriate since the description does not need to elaborate on parameter meaning. The description's non-mention of parameters is fine.

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

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

The description clearly states it is the PRIMARY tool for confirming WEEEK_ACCESS_TOKEN works against the live API and returns {id, email, name} for the account owning the token. It explicitly distinguishes from sibling ping, making the tool's unique purpose and resource unambiguous.

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

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

It explicitly provides guidance on when to use the tool: 'Use when an agent is about to run weeek_list_* / weeek_get_* and wants a one-shot token sanity-check first.' It also contrasts with ping, stating that ping never reaches the network, thus giving an explicit alternative and exclusion.

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?

While annotations already declare read-only and idempotent behavior, the description adds the error behavior for unknown ids (weeek_get_project failed / weeek_not_found) and confirms the returned object includes the description. This supplements the annotations with valuable operational context, and no contradiction 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?

The description is three sentences, each earning its place: the first states the primary function and return shape, the second differentiates from the sibling list tool, and the third gives usage and error guidance. It is front-loaded with 'PRIMARY tool' and wastes no 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 one-parameter read-only tool with an output schema, rich annotations, and sibling context, the description covers purpose, usage, differentiation, and failure mode. Nothing critical is missing for an agent to select and invoke it correctly.

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

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

The schema already describes the single parameter (project_id) with its source and constraints, and schema coverage is 100%. The description reuses this information but adds no new semantic detail 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?

The description clearly states it fetches a single project's full detail by id and lists the exact return fields ({id, title, description, color, isPrivate}). It explicitly distinguishes itself from weeek_list_projects, which returns summaries only, making the scope unambiguous.

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

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

It explicitly says 'Use when you already know the project id... and need the description or want to confirm a single project still exists.' It names the alternative (weeek_list_projects) and explains its limitations, providing clear when-to-use and when-not-to-use 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?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond annotations: it specifies that this is the only tool returning the full description field, and describes the error format for unknown ids (weeek_not_found). This enriches the agent's understanding of the tool's behavior.

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

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

The description is concise and well-structured: it opens with the primary purpose, followed by a distinct sibling differentiation, usage guidance, and error behavior. No word is wasted, and all key information is front-loaded.

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

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

Given the tool's low complexity (one parameter), rich annotations, and presence of an output schema, the description is complete. It covers purpose, usage, sibling distinction, return fields, and error behavior—enough for an agent to select and invoke the tool correctly without additional documentation.

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

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

The input schema provides 100% coverage for the single parameter task_id, with a clear description of where to obtain it (from weeek_list_tasks or the Weeek UI) and a minimum constraint. The tool description itself does not add additional parameter-level semantics, 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 clearly states the tool fetches a single Weeek task by task_id, lists the returned fields, and explicitly distinguishes itself from weeek_list_tasks by being the only tool that returns the full description field. This makes the purpose unambiguous and differentiated.

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 provides explicit when-to-use guidance: 'Use when an agent already has a specific id and needs full details.' It also names the alternative (weeek_list_tasks) and explains the error behavior for unknown ids, giving clear decision-making context.

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

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

Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds useful context: returns all columns in upstream sort order and emphasizes that 'the array order is the signal.' This goes beyond annotation hints and clarifies a key behavioral trait.

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

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

The description is front-loaded and information-dense. The first sentence states purpose and return shape, the second adds usage context. The parenthetical return shape detail might be slightly redundant with the output schema, but it serves immediate comprehension. 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 one clearly documented parameter and an output schema present, the description covers all necessary context: what the tool returns, ordering significance, required parameter, and when to use it. It is fully sufficient for the agent to select and invoke this tool correctly.

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

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

Schema description coverage is 100%, with board_id fully documented including source and error behavior. The description only repeats 'board_id is required,' which adds no new meaning. Baseline 3 is appropriate since the schema carries the parameter 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?

The description opens with 'PRIMARY tool for board-column discovery' and explicitly states it 'returns every column of a Weeek board' with a clear return shape. This verb+resource combination clearly distinguishes it from sibling tools like weeek_list_boards or weeek_list_tasks.

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 explicit use-case guidance: 'Use when the agent needs a board's column/stage layout, e.g. to interpret a task's status or drive a board view.' It also labels itself as 'PRIMARY tool' for this purpose, implying precedence over alternatives, though it does not explicitly state when not to use it.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds that the endpoint returns all boards, lists the per-board fields, and explicitly states pagination is not exposed—useful behavior beyond the annotations.

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

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

Two sentences, front-loaded with purpose, includes essential usage and limitation info without 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 single-parameter list tool with a rich schema and annotations, the description covers discovery, usage, return shape, and limitations, making it nearly self-sufficient.

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

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

Schema description covers project_id 100% with origin and HTTP 422 error detail. The description only restates that project_id is required, adding no new semantic information, so 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?

Description explicitly states it returns every Weeek board in the given project, lists the fields, and positions itself as the PRIMARY tool for board discovery, distinguishing it from siblings like weeek_list_board_columns.

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

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

Provides explicit usage direction: use when a board_id is needed to feed into weeek_list_board_columns or to surface the board picker. Also notes project_id is required and pagination is not exposed, giving context on limitations.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds useful context beyond this: output fields ({id, email, firstName, lastName}) and that member id is a string 'unlike most Weeek resources,' which is non-obvious and behaviorally relevant. No contradiction.

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, each earning its place: primary purpose plus output structure, sibling distinction, and a concrete use case with ID type note. No redundancy, front-loaded with the most important information.

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

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

For a zero-parameter, read-only list operation with comprehensive annotations and an output schema, the description covers what an agent needs: scope (all workspace participants), distinguishing from the self endpoint, and the string-typed member id. Complete.

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

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

Tool has zero parameters, so baseline is 4. The description adds no parameter-specific meaning, but none is needed; it focuses on output and usage, which is appropriate for a parameterless endpoint.

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 it is the 'PRIMARY tool for member discovery' and 'returns every member of the configured Weeek workspace' with specific fields. Explicitly distinguishes from weeek_get_me, which returns the caller. Clear verb+resource with sibling differentiation.

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

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

Provides explicit use case: 'Use when an agent needs to resolve a name/email to a member id.' Explicitly names weeek_get_me as a distinct alternative and explains the difference ('returns the caller' vs 'every workspace participant'). Clear 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?

Annotations already establish readOnly/idempotent/destructive properties. The description adds context about token-visible scope, per-project fields, and the absence of pagination, which goes beyond the annotations and adds valuable behavioral detail.

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

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

Three concise sentences, front-loaded with purpose, including usage and limitations. No redundant information; every sentence contributes meaningfully.

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

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

For a zero-parameter list operation with an output schema and comprehensive annotations, the description fully covers purpose, usage, and limitations. It includes return field details and integration with related tools, leaving no critical gaps.

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

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

With zero parameters, the baseline is 4. The description explains 'No filters' which clarifies why the schema is empty and confirms no input is needed, adding meaning beyond the empty schema.

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

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

The description clearly states the tool's function: 'returns every Weeek project visible to the configured token' and lists per-project fields. It distinguishes itself from siblings by being the 'PRIMARY tool for project discovery' and by referencing use with weeek_list_tasks, making it distinct from weeek_get_project or list tools.

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

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

Explicitly states when to use: 'Use when the agent needs a project_id to feed into weeek_list_tasks or to surface the project picker to the user.' It also notes limitations: 'No filters; pagination is not exposed,' providing clear 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?

Annotations already declare this as read-only, idempotent, and non-destructive. The description adds valuable behavioral context beyond annotations: 'No pagination' (meaning all results returned at once) and the exact fields per tag. This helps the agent understand what to expect without relying solely on the output schema.

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

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

Two tightly written sentences front-load the primary purpose and then specify the exact output and usage. Every word earns its place—no filler, no repetition of the title or annotations, and the structure is easily scannable.

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

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

Given the tool's simplicity (no parameters), the presence of an output schema, and the strong annotations, the description covers all essential aspects: what it returns, that it returns all tags, no pagination, and when to use it. It is complete for the tool's complexity.

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

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

The tool has zero parameters, so the schema coverage is 100% by default (actually vacuous). The description clarifies that there is no pagination, which explains the absence of paging parameters and prevents the agent from looking for them. This is a reasonable baseline with a useful extra note.

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

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

The description explicitly states 'PRIMARY tool for tag discovery' and defines the exact resource ('every tag defined in the configured Weeek workspace') with output shape ({id, title, color}). It clearly distinguishes itself from sibling list tools and explains why it exists (mapping tag names to ids).

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

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

The description gives a clear usage scenario: 'Use when an agent needs to map a user-supplied tag name to a stable tag id'. It does not explicitly name alternatives or state when not to use it, but the 'PRIMARY tool' phrasing and the distinct resource make the intended context obvious.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds behavioral context: returns only one page, pagination via offset/per_page (default 20, max 100), returns summaries without description/details, and to follow hasMore for the next page. No contradictions.

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

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

The description is compact and front-loaded with 'PRIMARY tool', then lists what it does, offers usage guidance, clarifies the distinction from weeek_get_task, and closes with pagination advice. Every sentence earns its place.

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

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

Despite having 7 optional parameters and an output schema, the description covers the main use case, pagination, the summary-versus-detail distinction, and the next-page mechanism. The output schema supplies return-value details, so the description is adequately complete.

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

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

Schema description coverage is 100% with rich per-parameter descriptions (e.g., error behavior for invalid IDs, assignee matching semantics). The description merely restates the filter names without adding new meaning, 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 this is the PRIMARY tool for task discovery and filtering, returns one page of Weeek tasks with explicit filter parameters, and distinguishes itself from weeek_get_task (summaries vs full details). This clearly identifies the tool's function and scope.

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 explicitly says 'Use the filters to locate the card a write tool is about to act on instead of paging a whole project' and instructs to 'fetch a single full task via weeek_get_task' when details are needed, plus when a list view is required. This provides clear when-to-use and alternative guidance.

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