MFIT Personal

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

The description discloses that the tool sets authentication state, with session vs permanent behavior. Annotations indicate idempotentHint true, which aligns with repeated calls using the same token. No contradictions. Adds value beyond annotations by explaining the config option.

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, each sentence provides essential information (permanent vs session, how to invoke). No fluff.

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 output schema, description hints at return values (link vs login). It could be more complete about success/failure or token storage, but covers core behavior adequately for an auth tool.

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

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

Schema has one optional token parameter with 0% coverage. Description fully explains token as JWT from browser login, and behavior when omitted (returns link). This compensates completely for the lack of schema description.

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 handles authentication for MCP.AI IDE agents, explaining two permanent and session methods. This is specific and distinct from sibling tools (none are authentication-related).

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 covers when to use each authentication method: permanent via config, session via pasting token, or no args to get a link. While it doesn't explicitly state when not to use, the guidance is clear and practical.

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 destructiveHint=false. Description adds value by specifying exact return values in two scenarios (authenticated:true vs connect_url), providing behavioral context beyond 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 with zero waste. Front-loaded with core purpose, then conditional behavior efficiently explained. Every sentence adds value.

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 status check tool with no parameters and no output schema, the description fully covers return values and conditions. No 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?

No parameters; baseline is 4. Description is consistent with schema (empty properties) and needs no further parameter information.

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 uses specific verb 'Returns' with resource 'connection status and URLs', and distinguishes two clear states (all connected vs missing credentials). Differentiates from sibling 'authenticate' by focusing on status rather than performing authentication.

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: check connection status. No explicit when-not or alternatives, but the context of a read-only status check is clear from annotations and description.

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?

Describes behavioral traits beyond annotations: invoke runs one-off without adding to toolkit, install makes permanent, writes require workspace owner/admin. Explains behavior when credentials or payment are needed. No contradiction with annotations (readOnlyHint=false, destructiveHint=false).

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 lengthy (over 200 words) and dense. It front-loads key info but contains some redundancy ('THE official' emphasis). While justified for a complex tool, it could be more structured.

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 13 parameters, no required params, and no output schema, the description covers the core flow and most actions, including edge cases (credentials, payment). However, it lacks details on return values and error states, leaving some 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?

Schema coverage is 0%, so description must add meaning. It explains the action parameter via the core flow and mentions mcp_id, tool_id, arguments in context. However, many parameters (limit, immediate, tier_slug, etc.) are not described. The description partially compensates but not fully.

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 is 'THE official mcp.ai marketplace' and lists specific actions (search, describe, invoke, etc.) with a defined core flow. It distinguishes from external registries and sibling tools like toolkit_info.

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 instructs to use this tool FIRST for capability discovery. Provides clear guidance on when to use invoke (one-off) vs install (permanent), and what to do when credentials are needed or wallet is empty. Also mentions alternative actions like list_tools.

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 provide destructiveHint=true. The description adds 'irreversible', which reinforces the destructive nature. It also mentions bulk support, providing additional context beyond annotations. However, it does not disclose permissions or other side effects.

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 two short, clear sentences. It front-loads the key action and irreversibility, then adds bulk support in a second sentence. 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?

The tool has 5 parameters, no output schema, and is destructive. The description covers purpose and bulk mode but lacks details on required vs optional parameters, ID formats, return values, or error handling. Significant gaps remain given the 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?

With 0% schema description coverage, the description should compensate. It only mentions 'client_ids, file_ids for batched execution', but does not explain the individual parameters (e.g., account, client_id, file_id) or their formats. This adds minimal value over 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 clearly states the action ('Delete') and the resource ('student file'), and notes irreversibility. It distinguishes from sibling delete tools by specifying 'student file', differentiating from other delete tools like mfit_workout_delete_exercise.

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 for deletion and mentions bulk support, but does not explicitly state when to use this tool versus alternatives or provide exclusions. No guidance on prerequisites or 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.

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

Annotations already provide readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety is clear. The description adds that batch execution is supported and that 'sharing info' is returned for get actions. No additional behavioral traits (e.g., rate limits, permissions, or side effects) are disclosed, but annotations cover the core traits.

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-load the purpose and actions, then add batch support concisely. No filler or redundancy. The mention of both list and get in one sentence slightly reduces clarity but overall 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?

With 5 parameters, 0% schema coverage, and no output schema, the description is incomplete. It does not explain the return format (beyond 'file detail with sharing info'), pagination, or error handling. Batch behavior is mentioned but not fully specified (e.g., response structure for multiple results). An agent would lack sufficient context to use the tool reliably.

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 0%, so the description must compensate. It explains that client_ids and file_ids enable batch execution, and 'client_id' is implied for listing all files. However, the 'account' parameter is entirely unexplained, and the distinction between single vs. batch identifiers (file_id vs. file_ids) is absent. The description provides some semantics but leaves significant gaps.

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 reads student files/attachments, listing types (diet plans, exams, planners, misc). Mentioning 'list' and 'get' actions distinguishes it from sibling tools like mfit_client_files_delete and mfit_client_files_write. However, the presence of a sibling named mfit_client_files_list creates slight ambiguity about whether this tool also lists or only gets.

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 guidance on when to use this tool vs alternatives like mfit_client_files_list or mfit_client_files_write. The description mentions dual actions (list/get) but does not specify scenarios for each, leaving the agent to infer. Batch support is noted but not contextualized with prerequisites or when batching is appropriate.

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 readOnlyHint=true and idempotentHint=true. The description adds batch execution context and non-destructive nature, but does not disclose pagination, response format, or potential rate limits. No contradiction with 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?

The description is relatively concise but has a slightly confusing structure with the '[Flattened action: list]' notation. It front-loads the purpose but could be cleaner.

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 detail return values, but it only vaguely states 'all files for a student' for list. Missing information about required parameter combinations and result format.

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 0% schema coverage, the description only partially compensates by mentioning client_ids and file_ids for batching. However, other parameters like 'account' and individual 'file_id'/'client_id' are not explained, leaving ambiguity.

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 reads student files/attachments (diet plans, exams, planners, misc) and specifies the list action for all files for a student, distinguishing it from sibling tools like mfit_client_files_get which handles individual file details.

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 usage guidance by mentioning bulk support with client_ids and file_ids, and contrasts list versus get actions. However, it lacks explicit exclusions or when-not-to-use scenarios.

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 indicate write operation (readOnlyHint=false), non-destructive (destructiveHint=false). The description adds specific behaviors: renaming, changing sharing settings, and bulk execution. These go beyond annotations, though it could detail more on side effects or idempotency.

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 cover purpose and bulk support without redundancy. Every part earns its place, making it efficient and 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?

With 6 parameters and 0% schema coverage, no output schema, and minimal annotations, the description fails to explain the other parameters or return behavior. It is insufficient for autonomous selection and invocation.

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 file_id and file_ids are mentioned in the description. The remaining four parameters (nome, groups, account, clients) have zero schema description coverage and no explanation here, leaving their meaning and use unclear.

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 updates a student file via rename or sharing settings, distinguishing it from sibling tools like delete, get, list. It specifies the verb 'Update' and the resource 'student file', providing concrete actions.

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 mentions bulk support via file_ids, hinting at batch usage. However, it lacks explicit when-to-use vs alternatives (e.g., when to use write vs delete or get), and no prerequisites are 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds useful behavioral traits: bulk support via client_ids, dynamic note about list_groups, and static field types. No contradictions with 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?

The description includes a bulleted action list and sections, but has redundancy (e.g., 'Read students in MFIT' repeated in title context). It is moderately structured but could be more concise without losing clarity.

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 7 parameters, 0% schema coverage, and no output schema, the description should be comprehensive. It lacks explanations for key parameters (account, search, client_ids) and the action 'Flattened action: get' is confusing. The tool's overall behavior is not fully specified.

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 0%, so the description must compensate. It mentions 'filter by status/name' and implies page/page_size, but does not explain individual parameters like account, client_id, client_ids, or search. The mapping from actions to parameters is incomplete, leaving the agent unclear about how to use each parameter.

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

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

The description states 'Read students in MFIT' as the main purpose, but then lists multiple actions (list, get, list_groups) which creates ambiguity. Given sibling tools like mfit_client_list exist, the tool's distinct role is unclear. The verb 'Read' is specific, but the resource and actions are muddled.

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 a usage hint for list_groups (call before create/update for valid groupId), but does not explain when to use this tool over alternatives like mfit_client_list or mfit_client_get. No explicit when-to-use or when-not-to-use guidance is present.

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 provide readOnlyHint, idempotentHint, and destructiveHint. The description adds some value with bulk support info and field type details, but does not significantly extend behavioral context beyond what annotations imply.

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 moderately sized but includes extraneous action listings that belong to other tools, reducing clarity. The 'Flattened action: list' note adds confusion. Overall, it could be more concise and focused.

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 7 parameters, no output schema, and no enum constraints, the description omits critical details such as output format, pagination behavior, and exact filtering logic. It is insufficient for an agent to fully understand the tool's capabilities.

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 0% schema coverage, the description must heavily compensate. It explains status values and bulk execution via client_ids, but leaves most parameters (page, search, account, client_id, page_size) unexplained or only vaguely referenced.

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 'Read students in MFIT' and identifies 'list' as the primary action, but it also includes 'get' and 'list_groups' as actions, which are actually separate sibling tools. This muddles the purpose and fails to clearly differentiate from siblings.

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

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

No guidance is provided on when to use this tool vs alternatives like mfit_client_get or mfit_client_list_groups. The inclusion of those actions as part of this tool's description is misleading and offers no usage 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety is clear. The description adds that the tool is dynamic (needs fresh call) and supports bulk execution. No contradictions, but additional behavioral details (e.g., pagination, sorting) are missing.

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 cluttered with references to other tools (list, get) and unrelated field type notes. The essential information is buried, making it hard to parse quickly. Not concise or well-structured.

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, yet the description fails to specify return format or fields beyond 'valid groupId'. Parameters are not fully explained. For a listing tool, this is incomplete guidance.

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 0%, yet the description only explains client_ids (for bulk) and implies groupId is returned. Parameters like page, search, status, client_id, account, page_size are not described. This is insufficient for a tool with 7 parameters.

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 'list_groups — trainer's custom groups' but also includes unrelated actions (list, get) from other tools, creating confusion. While the tool's purpose is discernible, the mixed content reduces clarity.

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 advises to call before creating/updating a student to obtain a valid groupId (DYNAMIC). Also mentions bulk support with client_ids. No guidance on when not to use, but the given direction is clear and actionable.

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 show destructiveHint=false and readOnlyHint=false, indicating a non-destructive write. The description adds bulk support via client_ids and notes that deactivation is reversible, but fails to disclose behavior on duplicate entries, response format, or error conditions. With no output schema, more detail would be beneficial.

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 moderately concise with a bullet-like structure, but includes repetitive or unnecessary elements like listing all three actions when only create applies. The flattened action note helps, but overall it could be tighter.

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 11 parameters, 0% schema coverage, and no output schema, the description lacks completeness. It does not explain return values, error handling, or the effect of bulk operations. The agent would need to infer or experiment to fully understand the tool's 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 coverage is 0%, so the description partially compensates by explaining required fields for create, gender as static m/f, and groupId as dynamic requiring a prior call. However, many parameters (e.g., account, lastName, birthDate, blockOverdue) remain undocumented, limiting full understanding.

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 'Create / update / deactivate students' but clarifies 'Flattened action: create', making the primary purpose clear. It specifies required fields for create (name, email, phone). However, the broader list of actions could confuse, and the tool name suggests only create, which aligns with the flattened action note.

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 for creating students and mentions prerequisites like calling list_groups for groupId. It does not explicitly distinguish when to use this tool versus sibling tools mfit_client_write_update and mfit_client_write_deactivate, leaving the agent to infer from the flattened action note.

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 provide little behavioral context (readOnlyHint=false, destructiveHint=false). The description adds that deactivation is reversible via update and notes bulk support for client_ids. It does not mention auth requirements, rate limits, or other side effects. Given the sparse annotations, the description adds moderate value but could be more detailed.

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 moderately concise but could be better structured. It uses bullet points for actions and field types, and includes a note about flattened action. However, it is somewhat verbose and could be trimmed to focus on the deactivate action, especially given the existence of separate create/update tools.

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 complexity (11 parameters, no output schema, 0% schema coverage), the description is incomplete. It does not explain the return values or response format, leaving the agent unaware of what to expect. Additionally, the relationship with sibling create/update tools is unclear, further reducing completeness.

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

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

The description explains that name, email, and phone are required for create, and that client_ids enable bulk execution. It also clarifies that gender is static (m/f) and groupId is dynamic (requires calling list_groups first). However, other parameters like account, lastName, birthDate, and blockOverdue are not described. With 0% schema coverage, the description partially compensates but leaves many parameters unexplained.

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 that the tool can create, update, and deactivate students, with the specific action 'deactivate' indicated. However, the inclusion of create and update actions creates confusion because sibling tools 'mfit_client_write_create' and 'mfit_client_write_update' exist, suggesting these actions are separated. The purpose is generally clear but not fully aligned with sibling tool boundaries.

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 does not provide explicit guidance on when to use this tool versus its siblings. It mentions create, update, and deactivate, but does not explain the rationale for combining these actions in one tool when separate tools exist for create and update. No when-to-use or when-not-to-use conditions are given, leaving the agent to guess.

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 are minimal (readOnlyHint=false, destructiveHint=false). The description adds valuable behavioral context: deactivation is reversible, updates are partial, and bulk execution is supported. No contradiction with 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?

The description is concise, front-loading the core purpose and listing actions clearly. It uses bullet points and notes tidily. No superfluous content.

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 11 parameters, 0% schema coverage, and no output schema, the description is incomplete. It omits details on many optional parameters, return values, error conditions, and does not fully compensate for the low schema coverage. The three actions add complexity but are only partially documented.

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 0% schema coverage, the description must compensate. It adds meaning for a few parameters: required fields for create, gender as m/f, groupId as dynamic requiring a prior call. However, most parameters (lastName, birthDate, account, blockOverdue, etc.) are undocumented, and formats (e.g., date) are missing.

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 creates, updates, and deactivates students in MFIT, listing specific actions. However, sibling tools mfit_client_write_create and mfit_client_write_deactivate exist, and the description does not differentiate when to use this tool versus those. The 'Flattened action: update' note adds minor confusion.

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 some usage guidance, such as calling mfit_client list_groups first for dynamic groupId field and mentioning bulk support. However, it does not explicitly compare this tool to the sibling create/deactivate tools or state prerequisites like authentication.

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 destructiveHint=false, so the description's mention of 'can be sent to students' adds context but no additional behavioral traits beyond what annotations provide.

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 concise sentence (12 words) that front-loads the verb and resource, but it could include parameter details without significant increase in length.

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 has one parameter and no output schema, the description provides minimal context. It lacks explanation of output format, prerequisites, or how to use the templates, making it just 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?

The input schema has one parameter 'account' with no description (0% schema coverage), and the tool description does not explain its purpose or usage, leaving the parameter semantics unclear.

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 verb 'Get' and resource 'anamnesis form templates' with an example (PAR-Q), and it distinguishes from sibling tools like mfit_get_client_evaluations by specifying templates for sending to students.

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 for retrieving available templates for sending to students, but it does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions 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?

Annotations already indicate read-only and idempotent. The description adds that it returns a summary count of active and inactive students, which is useful but does not explain behavioral details like auth requirements or what happens if the account parameter is omitted. No contradictions with 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?

The description is a single short sentence, which is concise but at the expense of completeness. It front-loads the main purpose but omits critical parameter details, making it too terse for effective use.

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 lack of output schema and parameter descriptions, the description is insufficient. It does not explain the return format or the effect of the account parameter, leaving significant gaps for an agent to use 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?

The only parameter 'account' is undocumented in both the schema (0% coverage) and the description. The agent has no information about its meaning, format, or whether it's required, making it nearly useless without external knowledge.

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 returns a summary count of active and inactive clients, distinguishing it from sibling tools like mfit_client_list that return full client data. However, the term 'students' is slightly inconsistent with other sibling names using 'clients'.

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 vs. alternatives like mfit_client_list. The description does not mention any prerequisites or context for choosing this count tool over other get tools.

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 provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description adds minimal extra context. It confirms the tool returns evaluations but does not disclose additional behavioral traits like pagination, rate limits, or side effects.

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 is entirely front-loaded with the action and key data. Every word adds value; no fluff.

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 three parameters and no output schema, the description is incomplete. It omits parameter usage guidance and does not cover return format or example usage. The tool is moderately complex, requiring more explanation.

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 0%. The description does not explain any of the three parameters (account, client_id, client_ids). It fails to clarify the difference between single vs. multiple client IDs, making it hard for the agent to invoke correctly.

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 verb 'Get' and the resource 'evaluations for one or many students', and explicitly lists the data returned: heart rate zones, VO2max, and training frequency. This distinguishes it from sibling tools like mfit_get_client_notes or mfit_get_client_workouts.

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. The description does not mention prerequisites, filters, or scenarios where this tool is preferred over sibling tools.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the capability for bulk retrieval via client_ids, which is useful but not a behavioral disclosure beyond what annotations imply.

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 sentence that efficiently conveys the tool's purpose and key capability (bulk retrieval). No unnecessary 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?

The description is adequate for a read tool with three parameters, but lacks explanation for the account parameter and does not describe the return format or any pagination. Complete enough for basic use, but could be more helpful.

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

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

The description explains the purpose of client_id (one student) and client_ids (bulk), but does not mention the account parameter. With 0% schema description coverage, this partial explanation adds some value but is incomplete.

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 'Read notes/observations for one or many students', specifying the verb and resource. It distinguishes from sibling write tools by explicitly focusing on reading and noting bulk retrieval via client_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 provides clear context for reading notes, but does not explicitly state when not to use this tool (e.g., when the write tool is appropriate). However, sibling tool names like mfit_get_client_notes_write imply the distinction.

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?

The description states 'replaces any existing notes text,' which implies a destructive action (overwriting previous data). However, the annotation sets destructiveHint=false, creating a contradiction. Therefore, transparency is severely impacted.

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 with two sentences. The first sentence states the core action, and the second adds bulk support. No superfluous 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?

Given the tool has 4 parameters, no output schema, and annotations with a contradiction, the description is somewhat incomplete. It covers the basic overwrite behavior and bulk support but lacks information on return values, failure modes, or authorization requirements.

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 0%, so the description must compensate. While it mentions bulk support via client_ids, it does not explain the relationship between client_id and client_ids (e.g., mutual exclusivity), the format of notes, or the purpose of the account parameter. This leaves significant gaps.

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 saves/overwrites notes for a student, using specific verb ('Save') and resource ('notes/observations'). It distinguishes from sibling tools like mfit_get_client_notes (read) and mfit_client_write_update (likely general client updates).

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 does not provide explicit guidance on when to use this tool versus alternatives like mfit_client_write_update or mfit_get_client_notes. While the purpose is clear, it lacks when-to-use and when-not-to-use 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 declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds that the tool supports bulk via client_ids, which is useful but lacks details on authentication, rate limits, or behavior when both client_id and client_ids are provided.

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 with no wasted words. Key information is front-loaded: 'Get all workout routines assigned to one or many students' followed by bulk support. Highly concise.

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 0% schema coverage, no output schema, and 3 parameters, the description is incomplete. It does not explain the account parameter, the difference between client_id and client_ids, or what the return value is.

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 0%, so description must compensate. It only explains client_ids for bulk, leaving account and client_id without any semantic meaning. This is insufficient for 3 undocumented parameters.

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 verb 'Get' and the resource 'workout routines assigned to students', and specifies scope as 'one or many students' with bulk support via client_ids. It distinguishes from sibling tools by focusing on client workouts.

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 for retrieving workout routines but does not provide explicit guidance on when to use vs alternatives or any exclusions. No mention of prerequisites or 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.

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds no further behavioral context beyond the fact that it retrieves favorites, which is consistent with 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?

The description is a single, clear sentence with no unnecessary words. It is appropriately sized for a simple getter tool.

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 output schema and only one parameter, the description is minimally adequate. It misses explaining the parameter and what the return data contains, but annotations provide safety 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?

The input schema has one parameter 'account' with no description (0% coverage). The tool description does not explain what 'account' represents or how it affects the result.

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 uses a specific verb 'Get' and resource 'the trainer's favorite exercises,' clearly distinguishing from siblings like 'mfit_search_exercises' or 'mfit_get_user_exercises.'

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 'mfit_search_exercises' for searching exercises or 'mfit_get_user_exercises' for user-specific lists. No context provided.

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 description adds contextual details about returned fields, but doesn't reveal any behavioral aspects beyond what annotations provide.

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 with bullet-like list; no fluff, directly conveys purpose and output.

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?

Missing parameter explanation and fails to clarify if account is required or what it filters; lacks details on pagination or scope.

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 only parameter 'account' is completely undocumented in the description and schema, leaving the agent unable to determine its purpose or usage.

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 clearly states 'Get all unread workout feedbacks from students' and lists specific fields included, distinguishing it from sibling tools that deal with other data.

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 like mfit_get_client_notes or mfit_get_today_checkins; no mention of context or exclusions.

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, idempotentHint=true, and destructiveHint=false, indicating safe, read-only behavior. The description adds that the tool returns financial overview data, which is helpful but does not disclose any additional behavioral traits beyond what annotations provide. 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 a single 12-word sentence, making it concise and easy to read. It front-loads the main action. However, it could be slightly expanded to include parameter details without losing conciseness.

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 output schema, the description should explain the return format or structure, but it does not. It also lacks detail on how date ranges are interpreted (inclusive, format) and what specific data is returned (e.g., totals, list). The annotations help, but overall completeness is low.

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

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

The schema has 3 parameters (account, start_date, end_date) with 0% description coverage. The description mentions 'transactions in date range', which explains start_date and end_date, but does not explain the optional 'account' parameter. This leaves a gap in parameter understanding.

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 verb 'Get' and the resource 'financial overview', specifying it covers transactions in date range, wallet/payment info, and seller status. This is sufficiently specific to convey the tool's purpose, though it does not explicitly differentiate from sibling tools like mfit_get_invoices, which may overlap.

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. There is no mention of context, prerequisites, or exclusions. For example, it doesn't say to use this for a broad financial overview and reserve mfit_get_invoices for detailed invoice lists.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds the distinction between single (client_id) and bulk (client_ids) operations, which is useful but not extensive. No details on authentication, rate limits, or error 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 a single, well-structured sentence that is front-loaded with the action and resource. No unnecessary words or repetition.

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 the annotations, the description lacks details on output format, pagination, and what exactly is returned. The 'account' parameter is unexplained, and there is no guidance on when to use this tool over similar siblings like mfit_get_finances. An agent would have gaps in understanding.

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 0%, so the description must compensate. It explains that client_id is for a single student and client_ids for bulk, which adds value for two of three parameters. However, 'account' is not mentioned, leaving its purpose unclear.

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 action ('Get') and resource ('invoices/billing'), and specifies the scope ('for one or many students (bulk via client_ids)'). However, it does not differentiate from sibling tools like mfit_get_finances, which might have overlapping functionality.

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 vs alternatives. It does not mention prerequisites, what to do for single vs bulk, or when to prefer other billing-related tools. The description is too minimal to guide selection.

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 (readOnlyHint=true, idempotentHint=true, destructiveHint=false) already signal a safe read operation. The description adds value by specifying the returned data (name, email, plan, payment country) beyond the annotations, though it does not disclose authentication requirements or side effects.

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, clear sentence with no extraneous words. It front-loads the action and resource. However, it could be slightly more structured by explicitly listing the fields as a bullet list or separating the parameter explanation.

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 simplicity of the tool (one optional parameter, no output schema), the description covers the return fields adequately. However, the lack of parameter documentation and the absence of any context about when account is needed or left empty makes it incomplete for an AI agent to use correctly without additional knowledge.

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 'account' parameter is undocumented in both the schema and the description. With 0% schema coverage, the description should explain the parameter's meaning and usage, but it fails to do so. This forces the agent to guess whether and how to provide an account value.

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 verb 'Get' and the resource 'trainer's own MFIT profile', listing specific fields (name, email, plan, payment country). It distinguishes this tool from sibling tools that retrieve client profiles or client-related data.

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 mfit_client_get or other mfit_get_* tools. It does not specify prerequisites or exclusions, leaving the AI to infer that this is for the trainer's own profile only.

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 readOnlyHint, idempotentHint, and destructiveHint. Description adds the comparison behavior, but does not disclose additional traits like data freshness or permission requirements.

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 is direct and focused on the tool's core function. No unnecessary 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?

Lists returned metrics and comparison, but lacks detail on output format and behavior when parameters are omitted. With no output schema, more clarity on return structure would improve completeness.

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 0%, meaning description does not explain parameters. The two parameters (period, account) are not described, leaving the agent without guidance on valid values or defaults beyond the schema defaults.

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?

Clearly states the tool gets a retention dashboard with specific metrics (active clients, engagement rate, growth rate, churn rate, NPS) and compares current vs previous period. Distinguishes from sibling tools like mfit_get_retention_clients.

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 guidance on when to use vs alternatives. The description implies it's for a high-level retention overview, but does not mention when not to use or provide context for sibling tools.

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 destructiveHint=false. The description adds value by explaining the returned data (days since last workout, avg weekly workouts, WhatsApp link) and the focus on 'who needs attention'. No contradictions with 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?

Three concise sentences: first lists statuses, second lists data fields, third highlights utility. No fluff, front-loaded with key 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?

Given no output schema, the description adequately explains return fields (days since last workout, etc.) and purpose. However, it misses explanation of the 'account' parameter and does not address potential overlap with sibling tool mfit_get_retention. Slightly incomplete.

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

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

The input schema has 0% description coverage. The description partially compensates by explaining the 'status' parameter options (AT_RISK, ABANDONED, ACTIVE, all), but does not explain the 'account' parameter. This leaves a gap, but the status explanation is valuable.

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 lists students by retention status (AT_RISK, ABANDONED, ACTIVE, or all) and specifies what data is shown. It distinguishes itself from sibling tools like mfit_client_list by claiming it's 'much more useful than listing clients' and focuses on identifying who needs attention.

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 when you need to know which clients need attention (AT_RISK or ABANDONED). It contrasts with listing clients, providing context, but does not explicitly state when not to use this tool or name alternatives. However, the guidance is clear enough for an agent to infer appropriate 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?

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds that it scans all active students and returns two lists (who_trained, who_didnt), which is useful context but does not disclose any underlying side effects or limitations beyond 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?

The description is only two sentences, front-loading the purpose and return format without any superfluous 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?

The tool has no output schema, but the description compensates by outlining the return structure. However, the missing parameter documentation and lack of differentiation from sibling tools leave gaps in completeness.

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 has one parameter ('account') with no description (0% coverage). The description does not mention this parameter, leaving the agent to infer its purpose without any guidance.

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 purpose with specific verb 'Check' and resource 'which students trained today'. It distinguishes from one-by-one checking, and the tool name reinforces the 'today' and 'checkins' context.

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 as a single-call alternative to individual checks, but does not provide explicit when-to-use or when-not-to-use guidance, nor does it reference sibling tools that may offer similar functionality (e.g., mfit_client_list).

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description's addition of return format ('true/false per day of week') provides useful behavioral context without contradicting 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 concise sentences with no wasted words. The first sentence states the core purpose, and the second clarifies the output format.

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 description should fully elaborate on return structure, but it only vaguely mentions 'per day of week.' Input parameters are not adequately described for a 5-parameter tool with no schema descriptions.

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 0%, but the description fails to explain parameters like account, client_id, client_ids beyond their names. It mentions 'one or many students' but does not map to client_id vs client_ids. The date range reference to start_date/end_date is insufficient as the property names are self-explanatory.

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 clearly states the tool retrieves training frequency for students over a date range, specifying output as booleans per day of the week. This distinguishes it from sibling tools like mfit_get_retention or mfit_get_training_ranking.

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?

Description implies usage when days trained are needed but lacks explicit guidance on when not to use or alternatives. No mention of preferred scenarios over similar tools.

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, idempotentHint=true, destructiveHint=false. The description adds that it uses 'bulk frequency checks,' which is mild additional context but does not disclose any major behavioral traits beyond what annotations provide.

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 sentence of 18 words, front-loaded with the main purpose. It is efficient but could include more detail without losing conciseness.

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 has 7 parameters and no output schema, the description is incomplete. It does not explain return format, pagination (limit), status filter, account, date range, or what 'top performers' means in the response.

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 0% with 7 parameters, yet the description provides no information about any parameter except a hint about the month default. The description fails to add meaning beyond the schema, which itself lacks descriptions.

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 returns a ranking of top students based on training frequency for a given period, defaulting to the current month. This specific verb+resource combination distinguishes it from siblings like mfit_get_training_frequency.

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 the tool is for obtaining a ranking of top performers, but it does not explicitly state when to use this tool over alternatives (e.g., mfit_get_training_frequency or mfit_get_client_count). No guidance on 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 indicate read-only, idempotent, non-destructive behavior. The description adds that the tool retrieves custom exercises created by the trainer, but does not disclose additional behavioral traits like pagination, result limits, or what happens if no account is specified. It is adequate but not enriched.

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 sentence and very concise. However, it lacks parameter information and could be slightly restructured to include brief guidance. It is not verbose but omits essential details, balancing brevity and completeness poorly.

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 low complexity (1 optional parameter, no output schema), the description should explain the parameter and typical return values. It does neither, relying heavily on the tool name. The description is incomplete for an agent to fully understand behavior without additional 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?

The input schema has 0% description coverage and the only parameter 'account' is not mentioned in the description. The description fails to add any meaning to the parameter, such as its purpose, optionality, or filtering effect. This is a critical gap.

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 action ('Get') and the resource ('custom exercises created by the trainer'). It distinguishes from siblings like mfit_search_exercises and mfit_get_workout_library by specifying 'custom exercises'. However, it could be more explicit about the context (e.g., trainer vs client) but is sufficient for clarity.

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 such as mfit_search_exercises or when to provide an account parameter. Lack of usage context leaves the agent to infer from the name alone.

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 readOnlyHint, idempotentHint, destructiveHint, so the description adds value by noting bulk execution and root folder usage. No contradiction with 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, no fluff, front-loaded with purpose and immediate usage guidance. Every sentence adds value.

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 output schema and 0% schema coverage, the description covers basic usage but lacks details on response format, pagination, or the role of type and account parameters. Adequate but not fully complete.

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

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

Schema coverage is 0%, so description needed to clarify all parameters. It only explains folder_id and folder_ids, leaving type and account unexplained, which is insufficient.

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 browses workout library folders and saved routines with a specific verb ('Browse') and resource. However, it does not explicitly differentiate from sibling tools like mfit_workout_get_routine or mfit_workout_get_session, which are also about retrieving workout data.

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 hints like using folder_id=0 for the root and mentions bulk support via folder_ids, implying when to use. But it does not specify when not to use or suggest alternatives, leaving some ambiguity.

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, idempotentHint=true, and destructiveHint=false, covering safety and idempotency. The description adds minor behavioral context (return of 'is_default' flag behavior) but does not disclose additional traits beyond what annotations provide. The low bar from annotations yields a 3.

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 consists of two sentences with no fluff. The first sentence front-loads the purpose and key return fields. The second sentence provides essential parameter guidance. Every word earns its place, making it concise and well-structured.

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 (list accounts, one optional parameter) and the presence of annotations for safety, the description covers all necessary information: what it returns (id, email, label, is_default), the semantics of the output flag, and how to use the parameter in context of sibling tools. No output schema exists, but the description sufficiently describes return values.

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 has a single optional 'account' parameter (string) with 0% schema description coverage, so the description must compensate. It explains that the parameter accepts 'id, email, or label (full or partial)', adding clear semantics beyond the schema's bare type definition. This significantly aids correct parameter usage.

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 'List all MFIT accounts linked to this install' with a specific verb (list) and resource (accounts). It distinguishes from sibling mfit_* list tools (e.g., mfit_client_files_list) by specifying accounts as the resource and detailing returned fields.

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 explains the meaning of the 'is_default' flag and when to omit the 'account' parameter. It also guides usage of the 'account' parameter in other mfit_* tools, providing clear context for when to use this tool first and how to leverage its output. However, it does not explicitly state when not to use this tool or mention alternatives.

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 destructiveHint=false, so the description adds limited behavioral context beyond stating the search and return fields. Does not mention pagination or rate 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 sentences, front-loaded with the main purpose, no wasted words. Efficiently conveys core functionality.

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 4 parameters and no output schema, the description should cover pagination and account filtering, but it does not. The list of return fields is helpful but incomplete for a search tool.

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

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

With 0% schema description coverage, the description only explains the 'query' parameter (search by name) but ignores 'page', 'account', and 'hits_per_page'. Users must infer their purpose from defaults and names.

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 specifies searching the exercise library by name in Portuguese or English, and lists the returned fields, distinguishing it from sibling exercise tools like mfit_get_exercise_favorites.

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 like mfit_get_exercise_favorites or mfit_get_user_exercises. The description only states what it does.

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?

Adds 'irreversible' beyond the destructiveHint annotation, and mentions bulk support. However, it does not disclose other behaviors like cascading effects or required permissions.

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 includes unnecessary details about other actions (delete_routine, delete_session) that are not relevant to this tool, making it longer than needed.

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?

Lacks information about return values, required vs optional parameters for different scenarios, and error handling. Given the complexity (7 params, destructive, no output schema), the description is incomplete.

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

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

Only explains exercise_session_id, exercise_session_ids, routine_ids, and session_ids. Leaves account, routine_id, and session_id unexplained. With 0% schema coverage, this is insufficient.

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 removes an exercise from a session, distinguishing it from sibling tools like delete_routine and delete_session. However, the description includes multiple actions, making it slightly unfocused on this specific tool.

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 a hint to get exercise_session_id from another tool, but lacks explicit guidance on when to use this tool vs alternatives. Does not specify prerequisites or scenarios where bulk execution is appropriate.

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 mark destructiveHint=true, and the description adds key behavioral details: routine deletion is soft-delete (reversible) while session and exercise deletions are irreversible. It also explains how to obtain exercise_session_id via another tool. This goes beyond the annotations and provides actionable transparency.

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 structured with bullet points and a flattened action note, front-loading key information. It is informative but slightly verbose; however, every sentence adds value, so it earns a 4.

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 existence of sibling tools for deleting exercises and sessions, the description should have addressed why to use this combined tool. Additionally, there is no output schema and no description of return values, leaving a gap for an agent expecting feedback on deletion results.

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?

Despite 0% schema description coverage, the description explains the bulk support parameters (routine_ids, session_ids, exercise_session_ids) and gives a concrete path for exercise_session_id. However, it does not explain other parameters like 'account', and the relationship between singular and plural IDs is implicit.

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

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

The description clearly identifies three destructive actions with specific resources: delete_routine (soft-delete reversible), delete_session (irreversible), and delete_exercise (irreversible). It distinguishes between these actions and provides the flattened action as delete_routine, giving the agent a precise understanding of 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.

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

The description lists the actions and notes reversibility, but it fails to provide explicit when-to-use guidance compared to sibling tools like mfit_workout_delete_exercise and mfit_workout_delete_session. An agent would benefit from knowing when to use this multi-action tool versus the specific single-action siblings.

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?

The description adds detail beyond annotations by explicitly stating deletion is irreversible, which annotations (destructiveHint=true) do not specify. It also mentions bulk support, providing context on execution 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 includes extraneous details about sibling actions that are not necessary for this specific tool. While structured with bullets and a bulk note, it could be more concise by focusing solely on delete_session.

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 7 parameters and no output schema, the description is incomplete. It fails to explain parameter relationships, whether specific IDs are required for single deletions, or how the tool behaves without required parameters. Bulk support is mentioned but not fully clarified.

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 0% schema description coverage, the description must compensate but only partially covers parameters. It mentions bulk via plural fields (routine_ids, session_ids, exercise_session_ids) but does not explain the singular forms or the account parameter. The hint for exercise_session_id is relevant to a different tool.

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

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

The description clearly identifies the tool as handling the delete_session action, with a specific verb and resource ('remove a session from a routine'). It distinguishes from sibling tools for delete_routine and delete_exercise by naming them and noting the flattened action.

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 clear context for when to use this tool ('remove a session from a routine (irreversible)') and implicitly differentiates from sibling actions by listing them separately. Bulk support is mentioned, but no explicit exclusions are 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?

Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds that it performs reads and supports batch execution, which is useful but minimal. No contradiction with 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?

The description is short and front-loaded with the main purpose. However, the 'Actions' and 'Flattened action' lines add some redundancy. Could be slightly more streamlined but overall 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?

Given 5 parameters, no required ones, and no output schema, the description lacks completeness. It does not explain parameter distinctions (e.g., routine_id vs routine_ids), the account parameter, or return values. The tool is underspecified for an agent to use 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?

With 0% schema description coverage, the description should compensate. It only mentions routine_ids and session_ids for batching, but ignores account, routine_id, and session_id. No explanation of parameter purpose or usage beyond batching.

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 reads workout routines and sessions, enumerating two sub-actions (get_routine, get_session) and mentioning bulk support. It distinguishes from sibling tools like mfit_workout_get_session by including session retrieval here. However, the 'Flattened action' note introduces slight ambiguity.

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

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

Usage is implied: use this tool to read routines/sessions. It mentions bulk support but does not specify when to prefer this over alternatives like mfit_workout_get_session. No explicit when-not or exclusions.

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 provide readOnlyHint, idempotentHint, destructiveHint. Description adds that this tool supports batched execution via routine_ids and session_ids, which is beyond annotations. 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?

Description is brief (3 sentences) with clear bullet-like formatting for actions. Every sentence adds value. Slight redundancy in mentioning the flattened action, but overall 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?

Given 5 parameters, no schema descriptions, and no output schema, the description does not cover all parameters (missing account), nor does it address parameter interactions or return format. This leaves the agent without sufficient context for correct invocation.

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 has 0% coverage, so description must compensate. It explains routine_ids and session_ids for bulk use and routine_id/session_id for single actions, but fails to describe the 'account' parameter. With 5 params and no schema descriptions, partial coverage leaves significant gaps.

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 reads workout routines and sessions, specifies two actions with their return content (get_routine details all sessions, get_session gives prescription with exercises/exercise IDs), and clearly distinguishes from sibling mfit_workout_get_routine. The flattened action clarification avoids confusion.

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 when to use each action (routine vs session details) and mentions bulk support for routine_ids/session_ids. However, it lacks explicit 'when to use this vs alternatives' and does not state when not to use, leaving some ambiguity.

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 indicate readOnlyHint=false and destructiveHint=false. The description adds behavioral context such as bulk support and reversible archiving, but does not disclose all behavioral traits like authentication needs, side effects, or error handling. The description adds some value beyond annotations but is not comprehensive.

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 with purpose but is lengthy due to listing multiple actions and static options. While it attempts to be structured, the inclusion of actions not directly relevant to 'add_exercise' adds noise. It could be more concise by focusing on the add_exercise action and cross-referencing sibling tools for other actions.

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 complexity (26 parameters, no output schema), the description is incomplete. It provides workflow hints (use search then add then update series) but does not explain return values, error conditions, or behavior for bulk operations. The description lacks sufficient detail for an agent to fully understand the tool's scope and usage.

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 0%, meaning no parameter descriptions in the schema. The description mentions some parameters (e.g., exercise_id, serie_id, day, goal) but does not explain most of the 26 parameters. For a tool with many parameters and no schema descriptions, the description heavily under-documents parameter semantics, failing to compensate adequately.

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 the tool creates/updates workout routines, sessions, and exercises, listing multiple actions like create_routine, add_exercise, etc. However, the tool name is 'mfit_workout_write_add_exercise', suggesting a focused purpose of adding exercises, but the description covers many actions, causing ambiguity. The phrase 'Flattened action: add_exercise' tries to clarify but contradicts the broad 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 provides some usage guidance: it mentions using mfit_search_exercises to find exercise_id and directs destructive operations to mfit_workout_delete. However, it does not clearly distinguish when to use this tool versus sibling tools like mfit_workout_write_create_routine, since the description includes those actions. The guidance is partially helpful but lacks explicit when-to-use vs alternatives.

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 readOnlyHint=false and destructiveHint=false. The description adds that archiving is reversible (status=1) and mentions bulk support, which goes beyond annotations. However, it does not disclose behavior for other actions (e.g., whether updates are partial or full replacement).

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 verbose and includes an enumerated list of actions, many of which are not relevant to the archive routine focus. It front-loads a broad verb ('Create / update') instead of the specific action. The bulk support note and static options add detail but could be more concise.

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 26 parameters, no output schema, and 0% schema coverage, the description does not provide enough context for correct invocation. It does not explain which parameters are required for each action, nor does it describe return values or error conditions. The static options are helpful but insufficient for comprehensive use.

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 0%, so the description must explain parameters. It provides static options for trainingType, goal, difficulty, day with numeric mappings, which helps. However, it does not explain many other parameters (reps, rest, weight, instructions, etc.) and fails to map which parameters apply to which action. Bulk-related IDs are mentioned but not detailed.

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?

Tool name specifies 'archive_routine' but description opens with 'Create / update workout routines, sessions, and exercises', which expands the scope ambiguously. The listing of multiple actions (create_routine, update_routine, archive_routine, etc.) suggests a general write tool, contradicting the name. The flattened action note indicates archive_routine, but the description does not focus on that single purpose.

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 mentions using mfit_workout_delete for destructive operations, providing some alternative guidance. However, it does not clarify when to use this tool vs. sibling write tools (mfit_workout_write_create_routine, mfit_workout_write_update_routine, etc.) or when to use archive vs. create/update actions. The agent is left to infer usage from the action list.

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

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

Annotations indicate readOnlyHint=false and destructiveHint=false. The description adds significant behavioral context beyond annotations: it lists reversible operations (archive/unarchive), bulk support, and the need to use update_serie after adding exercises. It does not mention permissions or error states, but overall provides good transparency.

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 structured with bullet points and sections, starting with a clear summary. It is dense but well-organized, referencing other tools inline. It could be slightly more concise by grouping information, but it remains efficient and easy to parse.

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 complexity (26 parameters, multiple operations) and no output schema, the description provides extensive guidance but lacks completeness in some areas: it does not describe the output or response format, error handling, or what happens with optional parameters. It covers usage steps well but misses some contextual completeness.

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 has 26 parameters with 0% description coverage. The description compensates well by providing domain-specific enumerations for trainingType, goal, difficulty, and day, and explains how to obtain IDs for serie_id, exercise_session_id, etc. Not all parameters are covered (e.g., account, instructions, booleans), but the key ones are explained, greatly aiding the agent.

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 'Create / update workout routines, sessions, and exercises in MFIT' and lists specific actions. It distinguishes from siblings by explicitly directing destructive operations to mfit_workout_delete. However, the flattened action 'create_routine' may cause confusion about the primary use case, and there is overlap with sibling tools like mfit_workout_write_update_routine.

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 guidance on when to use this tool versus alternatives: 'For destructive operations... use mfit_workout_delete.' It also references mfit_search_exercises and mfit_workout_get_session for finding necessary IDs. However, it does not clarify when to use this combined tool versus the specific sibling tools like mfit_workout_write_update_routine, leaving potential overlap ambiguous.

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 indicate readOnlyHint=false and destructiveHint=false, which aligns with the description's write orientation. The description adds bulk support and mentions the flattened action, but does not disclose potential side effects or authorization needs beyond what annotations imply. 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?

The description is lengthy and includes redundant information, such as listing multiple actions that may belong to separate tools. The structure is not front-loaded; the core purpose (create_session) is obscured. The bulk support note is useful but adds to verbosity. It could be more concise and focused.

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 26 parameters and no output schema, the description should provide comprehensive guidance. It lacks explanation of return values, error handling, and parameter relationships. The static options help but are insufficient for such a complex tool.

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

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

Schema description coverage is 0%, so the description must compensate. While it provides static option values (e.g., trainingType, goal, difficulty, day) and some guidance (e.g., use mfit_workout_get_session for IDs), it does not explain the purpose of many parameters (e.g., account, endDate, instructions, allowPdfDownload). The mapping between actions and parameters is missing.

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 covers multiple actions (create_routine, update_routine, archive_routine, etc.) which dilutes the specific purpose of this tool. The '[Flattened action: create_session]' hint is buried at the end, so the primary function is unclear. The title is null, and the description fails to specify clearly that this tool is for creating a session (and possibly other related actions).

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 mentions when to use sibling tools like mfit_search_exercises and mfit_workout_get_session, and directs destructive operations to mfit_workout_delete. However, it does not explicitly differentiate this tool from other write tools (e.g., mfit_workout_write_create_routine, mfit_workout_write_update_serie) for the different actions listed. The guidance is present but not thorough.

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?

The description states the action is reversible ('restore archived routine to active'). However, it lacks details like side effects, whether it checks preconditions, or if it overwrites any fields. Annotations already indicate it is not read-only and not destructive; the description adds minimal behavioral context beyond that.

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 overly long (multiple actions) and not front-loaded for the specific unarchive tool. The relevant information is a single line buried in a paragraph. The rest is noise that could mislead the agent.

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 high complexity (26 parameters, no schema descriptions, no output schema), the description is severely incomplete. It does not specify required parameters, return values, error conditions, or prerequisites. The tool is for a single action but the description is a catch-all for multiple actions.

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 has 26 parameters with 0% schema description coverage. The description does not explain which parameters are relevant for the unarchive action. Bulk support is mentioned but not linked to unarchive. The agent cannot determine required inputs (likely routine_id) from the description.

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 includes a line 'unarchive_routine — restore archived routine to active (status=0)' which clearly states the action and resource. However, the description is cluttered with nine other actions, diluting the focus. The tool name itself is specific, but the description does not differentiate it from siblings like archive_routine or create_routine.

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. It mentions destructive operations should use mfit_workout_delete, but does not specify prerequisites (e.g., routine must be archived) or contexts where unarchive is appropriate versus other actions.

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?

Provides detailed behavioral info beyond annotations: explains that adding an exercise creates an empty set, how to get IDs for series, and bulk support. No contradiction with annotations (readOnlyHint=false, destructiveHint=false). The archive/unarchive are reversible, consistent.

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 moderately lengthy with bullet points and a flattened action note. While organized, it contains some redundancy and could be more concise by grouping actions better.

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 complexity (26 params, no output schema, sparse annotations), the description covers most needed context: how to find IDs, bulk support, static options, and references to sibling tools for destructive ops. Missing only return value details.

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 26 parameters and 0% schema coverage, the description adds some meaning via static option mappings (trainingType, goal, difficulty, day) and action-specific explanations. However, many parameters (e.g., account, allowPdfDownload) are not explained. The description partially compensates but leaves gaps.

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 handles create/update/archive operations for workout routines, sessions, and exercises. However, it bundles multiple actions (create, update, archive, unarchive) under one tool, which may blur the purpose. The title implies 'update' but description includes creation, so it's slightly broad but still clear.

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 mentions that destructive operations should use mfit_workout_delete, but does not clarify when to use this tool versus sibling write tools like mfit_workout_write_create_routine. The 'Flattened action: update_routine' note is confusing. Usage guidance is partial.

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 indicate readOnlyHint=false and destructiveHint=false, consistent with the description's create/update actions. The description notes bulk support and how to get IDs from other tools. However, it lacks details on authorization, rate limits, or side effects beyond the listed actions. Some transparency 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.

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

The description is structured as a list of actions and static options, with a flattening line. It front-loads the broad purpose but is somewhat verbose and includes redundancy. The organization is moderate but could be more concise and focused.

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 high complexity (26 parameters, 0 required, no output schema), the description is insufficient. It does not explain return values, which parameters apply to which action, or error handling. The description tries to cover all actions but lacks completeness for the specific update_serie action.

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 0%, so the description must compensate. It explains static options like trainingType, goal, difficulty, and day with their enum meanings. It also clarifies the use of serie_id and exercise_session_id via reference to mfit_workout_get_session. However, many parameters (e.g., reps, weight, rest) are not explained, leaving gaps.

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 'Create / update workout routines, sessions, and exercises' but the tool name suggests specific focus on update_serie. The '[Flattened action: update_serie]' line clarifies the specific action, but the inclusion of many other actions dilutes clarity. The purpose is vague but discernible.

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 mentions using mfit_workout_delete for destructive operations and references mfit_search_exercises and mfit_workout_get_session for IDs. However, it does not clearly differentiate when to use this tool versus sibling tools like mfit_workout_write_create_routine, especially since this tool also lists create_routine. Overlapping responsibilities cause confusion.

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?

The description adds behavioral context by instructing users to include the conversation array for reproduction, which implies a write operation. However, it does not detail side effects (e.g., ticket creation) or clarify the idempotentHint (which may be misleading for bug reports). Annotations already indicate non-destructive and idempotent, so the description adds modest value.

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, well-structured sentence that efficiently conveys the tool's purpose and a key usage hint. No unnecessary words or repetition.

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 covers the basics but lacks information about the tool's output (e.g., confirmation, ticket ID) and the system's response. Given the tool's simplicity and lack of output schema, the description is minimally adequate but could be improved by specifying what happens after submission.

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

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

The description mentions the 'conversation' parameter and its purpose (recent messages for reproduction), but does not explain 'context' or the required 'message' beyond implied usage. With 0% schema description coverage, the description partially compensates but leaves gaps in parameter meanings.

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: reporting a bug, missing feature, or sending feedback. It uses specific verbs (report, send) and identifies the resource (bug, feature request, feedback). This distinguishes it from sibling tools, which are primarily for client management and other operations.

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 clear context on when to use the tool (for reporting issues or feedback) and even provides a guideline to include the conversation array. However, it does not explicitly state when not to use it or mention alternative tools, though no close alternatives exist among siblings.

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. The description adds that it shows version information, which is consistent and adds minor context beyond 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?

The description is a single, clear sentence with no unnecessary words. It is front-loaded with the action and subject.

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 tool with no output schema, the description is complete. Annotations cover behavioral traits, and the description specifies what is shown.

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?

There are no parameters (schema coverage 100% empty). The description does not need to add parameter information. It adds no param info but is not required to.

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 verb 'Show' and the resource 'MCP platform and adapter versions'. It distinguishes itself from sibling tools that deal with client or workout data.

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 is provided on when to use this tool versus alternatives. For a simple version tool, explicit guidelines are minimal but lacking.

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, idempotentHint=true, and destructiveHint=false. The description adds context about what the return data contains (installed MCPs, connection status, catalog counts), which goes beyond the annotations. 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 a single sentence that efficiently communicates the tool's purpose and output. Every word is informative, with no redundancy or 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?

Given the tool's simplicity (no parameters, no output schema), the description covers the main output aspects. It lacks details on return format, but for an introspection tool, the level of completeness is 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?

The tool has no parameters, so the baseline is 4. No parameter information is needed, and the description adds no parameter details, which 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 the verb 'returns' and the resource 'current toolkit state', with explicit details about what is included (installed MCPs, connection status, catalog counts). This distinguishes it from sibling tools, which are all functional or data manipulation 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?

The description implies this tool is for checking toolkit status, but it does not explicitly state when to use it versus alternatives or when not to use it. For a simple introspection tool, the context is clear but lacks explicit guidance.

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