MFIT Personal

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

The description discloses behavioral traits beyond annotations: the two authentication modes (permanent vs. session), token format (JWT), and the effect of calling with no args (returns link). Idempotency and non-destructiveness are implied but not explicit, and annotations already indicate idempotentHint=true.

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 paragraph of three sentences, front-loaded with immediate context ('MCP.AI for IDE agents'), and each sentence adds unique value—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 description covers the main use cases (config and session) and explains behavior well. It slightly lacks details on error handling or response format, but given no output schema, it is fairly complete for a simple authentication 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?

The input schema has a single undocumented 'token' parameter. The description adds essential context: token is a JWT obtained from browser login, can be omitted to get a link, or passed for session login. This fully compensates for the 0% schema coverage.

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

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

The description clearly states the tool authenticates IDE agents to MCP.AI, with specific verb 'log in' and resource 'MCP.AI server'. It distinguishes two methods: permanent config and session-based token.

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 usage scenarios (config vs. session) but does not compare with sibling tools like 'connect' or state when not to use this tool. Guidance is present but lacks explicit 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, idempotentHint, and destructiveHint. The description adds value by describing conditional behavior (different outputs for connected vs. missing credentials), which is not covered by 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?

Two sentences with no wasted words. The first sentence states the overall purpose, and the second elaborates on two common scenarios. Information is front-loaded and efficiently communicated.

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 parameters and no output schema, the description fully covers the tool's behavior. It addresses both normal and missing credentials cases, making it complete for a simple status-checking 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?

There are no parameters, so schema coverage is 100%. Per rules, baseline is 4. Description does not need to add 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?

The description clearly states the tool returns connection status and URLs, distinguishing it from siblings like 'authenticate' by focusing on status checking. It specifies two distinct output states based on provider connection status.

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 implicitly indicates when to use the tool (to check connection status) but does not explicitly mention when not to use it or suggest alternatives like 'authenticate' for missing credentials. The guidance is clear but lacks exclusionary 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?

Beyond the annotations (readOnlyHint=false, openWorldHint=true, etc.), the description discloses key behavioral traits: invoke works even when the MCP is not installed, runs one-off without bloating the tool list; credentials and payment edge cases (returns connect link or checkout/top-up link); permission requirements ('Writes ... require workspace owner/admin'); and installed_in_toolkit vs installed_in_workspace flags. These add substantial context not available from annotations alone.

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 long but dense with valuable information, organized around the core flow and key distinctions. Each sentence adds meaningful content, and the use of 'KEY:', 'Core flow:', and conditional statements provides structure. A slight deduction because it could be split into sections or trimmed for easier scanning, but no sentence is wasted.

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 23 parameters, 14 actions, no output schema, and moderate annotations, the description covers a remarkable amount: the main flow, edge cases for credentials/payments, permission levels, and the prompt library. However, it does not describe the exact response format for key actions like search/describe/invoke, and leaves several parameters (immediate, tier_slug, cancel_reason) undone. The description is robust but not fully complete given the tool's complexity.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the meaning of the central 'action' parameter by enumerating values and their flow, and clarifies key parameters like tool_id, mcp_id, and the prompt_* family. However, several parameters (limit, immediate, tier_slug, cancel_reason, conversation, prompt_targets, etc.) receive little or no explanation, leaving the agent to infer meanings from the schema enums and 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?

The description states a specific, multi-faceted purpose: 'the official mcp.ai marketplace — the in-platform catalog of every MCP/tool, AND the way to run them.' It clearly distinguishes the tool from siblings by highlighting its role as a catalog and execution platform, and it enumerates distinct actions (search, describe, invoke, install, list_tools, etc.) with a clear core flow.

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 each action and preference ordering: 'Core flow: action=search discovers MCPs by intent → describe returns one MCP's full profile ... → invoke RUNS that tool.' It explicitly contrasts invoke vs install: 'prefer invoke for a single/occasional use... Use install only to make an MCP PERMANENT in the active toolkit.' Also clarifies when to use list_tools, search_prompts, get_prompt, and publish_prompt.

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 set destructiveHint=true, and the description adds 'irreversible' and mentions bulk execution. However, it does not disclose side effects, return values, or authorization needs 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 very concise at two sentences, but could better front-load the bulk support note. Nevertheless, it is efficient and to the point.

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

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

No output schema exists, and the description omits return value, error behavior, and parameter relationships. For a destructive tool with 5 parameters, this is insufficient for complete 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%, and the description barely explains parameters. It mentions client_ids and file_ids for bulk but does not explain the singular vs plural distinction or the account parameter, leaving much 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 'Delete a student file (irreversible).' The verb 'delete' and resource 'student file' are specific, and it distinguishes from sibling tools like get, list, write.

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 deleting one or more files with bulk support. It does not specify when not to use or provide alternatives, but the context of siblings makes it clear enough.

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

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

Annotations already indicate readOnly, idempotent, and non-destructive. The description adds value by disclosing 'Bulk support: accepts client_ids, file_ids for batched execution' and the 'flattened action' note, which go 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 concise with three sentences, front-loading purpose and actions. The bracketed note about flattened action is slightly extraneous but not overly verbose.

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 optional parameters and no output schema, the description does not explain parameter semantics, the difference between list and get modes, or return value structure. It omits important 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 coverage is 0%, yet the description only mentions 'client_ids' and 'file_ids' in the bulk context. It fails to explain the other parameters (account, file_id, client_id) or differentiate between singular and plural IDs. This is insufficient compensation for the missing schema 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 'Read student files/attachments' and lists actions (list, get) and file types (diet plans, exams, planners, misc). It distinguishes from siblings like delete/write, but the 'flattened action: get' is slightly confusing given a separate list sibling exists.

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 guidance on when to use this tool vs the alternative mfit_client_files_list. It mentions list and get actions but does not clarify prerequisites or select between them.

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 the safety profile is clear. The description adds that the tool supports batched execution (client_ids, file_ids), which is useful context, but does not mention return format or pagination.

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 purpose. However, the redundant mention of 'get' action before flattening to 'list' could be streamlined.

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 undocumented parameters and no output schema, the description is incomplete. It provides the file categories and batch support but fails to explain important parameters like account or how single vs bulk listing works.

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 mentions two parameters (client_ids, file_ids) in the context of batch support. The other three parameters (account, file_id, client_id) are not explained, leaving the agent uninformed.

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 reads student files/attachments (diet plans, exams, planners, misc) and the primary action is 'list' (all files for a student). This distinguishes it from the sibling get/delete/write tools, though the mention of a 'get' action creates minor 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?

The description does not provide explicit guidance on when to use this tool vs alternatives like mfit_client_files_get or mfit_client_files_delete. It implies listing is for retrieving all files, but no when-not or context is given.

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

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

Annotations indicate readOnlyHint=false, and the description confirms write behavior. It adds bulk support context via file_ids, but lacks details on destructiveness or idempotency 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, front-loaded with purpose, no redundancy, efficient for an AI 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?

Covers core purpose and bulk support, but lacks output details and full parameter specifications, leaving gaps for an agent to infer.

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 maps 'rename' to likely 'nome' and 'sharing settings' to 'groups', 'account', 'clients', providing moderate semantic value but not full parameter details.

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

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

The description clearly states 'Update a student file' with specific actions 'rename or change sharing settings', distinguishing it from sibling tools like mfit_client_files_delete and mfit_client_write_create.

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 updating existing files but does not explicitly state when not to use or compare to alternatives like mfit_client_write_create for new files.

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 useful behaviors beyond annotations: bulk execution via client_ids, dynamic nature of list_groups, and status field mapping. No contradiction with readOnlyHint and other 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?

Description is somewhat verbose but structured with bullet points and sections. Could be tightened, but the structure aids readability.

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?

Tool has 7 parameters and no output schema; description does not explain return values or output format. Many behavioral aspects like pagination details are missing, leaving 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 has 0% description coverage. Description barely explains parameters: only status mapping (0=active/1=inactive) and client_ids for bulk. page, search, account, client_id are not described.

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 starts with 'Read students in MFIT,' but then lists multiple actions (list, get, list_groups) with a note 'Flattened action: get', causing confusion about the primary purpose. It somewhat distinguishes from siblings like mfit_client_list but lacks crispness.

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 guidance for list_groups ('call before creating/updating a student to get valid groupId') and mentions bulk support. However, no explicit when-to-use vs alternatives like mfit_client_list or mfit_client_get.

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 read-only and idempotent. Description adds further behavioral context: paginated listing, filtering by status/name, and bulk support with client_ids. Exceeds what annotations alone 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?

Description is structured with sections but includes extraneous details (get, list_groups actions) that confuse the scope. The 'Flattened action: list' clarification helps but adds redundancy.

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

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

Despite annotations, description lacks return format, error handling, auth requirements, and comprehensive explanation of all parameters. With no output schema and high parameter count, more detail is needed.

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%. Description mentions filtering by status/name and notes status field values, but does not explain most parameters (page, search, client_id, client_ids, account, page_size). Inadequate compensation for 7 undefined params.

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 'Read students in MFIT' and specifies the 'list' action for paginated listing. It distinguishes from sibling tools like mfit_client_get and mfit_client_list_groups.

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?

Implies that this tool is for listing students, mentions filter and bulk support, but does not explicitly state when to use it versus alternatives or 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 readOnlyHint=true and idempotentHint=true, so the description adds value by noting the 'DYNAMIC' nature (must call before mutations), the static status field interpretation (0=active/1=inactive), and bulk support via client_ids. There is 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 messy: it starts with a generic 'Read students in MFIT.', lists multiple actions, then switches to list_groups specifics. The field types and flattened action notes are embedded awkwardly. While short, it lacks clear structure and has redundant elements.

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, no output schema, and 0% schema coverage, the description misses critical details like pagination behavior, return format, and how client_ids interact with other parameters. The dynamic usage note and bulk support are good, 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?

Schema description coverage is 0%, so the description must explain parameters. It only covers 'status' (as static field) and 'client_ids' (for bulk), leaving 5 out of 7 parameters (page, search, account, client_id, page_size) unexplained. This is insufficient for an agent to understand all 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 indicates that the tool lists trainer's custom groups (list_groups) and is used before creating/updating a student to get a valid groupId. Although the description starts with a broader 'Read students in MFIT' and lists multiple actions, it clarifies that this specific tool is the flattened action for list_groups, making the purpose 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 explicitly says 'call before creating/updating a student to get valid groupId', providing a clear use case. It does not mention when not to use it or alternatives, but the context is sufficient for an agent to understand the primary usage scenario.

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 discloses that deactivation is reversible via update, indicates partial update support, and mentions bulk execution via client_ids. These go beyond the minimal annotations (readOnlyHint=false, destructiveHint=false). However, it omits details like permission requirements or error states.

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 uses bullet points and sections for actions and field types, making it scannable. It is relatively concise for the amount of information, but could be more focused on the create action given the tool name, reducing redundancy.

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

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

Given 11 parameters, no output schema, and multiple actions, the description is incomplete. It lacks return value information, error handling, and details on how parameters interact for bulk operations. The focus on create is diluted by inclusion of other actions without full specifications.

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 adds meaning for key parameters: name, email, phone required for create; gender is static (m/f); groupId is dynamic per trainer. However, 7 of 11 parameters (e.g., account, lastName, birthDate, blockOverdue) remain undocumented, 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 the tool creates, updates, and deactivates students, but the tool name and 'Flattened action: create' indicate it is specifically for creation. This inconsistency with sibling tools (e.g., mfit_client_write_update, mfit_client_write_deactivate) may confuse an agent about which tool to use for which operation.

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 versus its siblings for update or deactivate. The description implies actions exist but doesn't direct the agent to use the dedicated sibling tools for those operations. The hint to call mfit_client list_groups first is helpful but insufficient.

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

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

The description adds that deactivation is reversible and bulk support exists, but annotations already provide no hints. It does not disclose permissions, idempotency, or parameter requirements for deactivation, leaving significant behavioral gaps.

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 short but includes extraneous information about create and update for a deactivation-focused tool. The bullet list and flattened action note help, but the structure could be more 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 complexity (11 parameters, no output schema, multiple actions), the description is incomplete. It does not clarify which parameters are relevant for deactivation, response format, or error handling.

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 explain parameters but only lists required fields for create and mentions client_ids for deactivation. The 11 parameters are not mapped to actions, offering minimal value beyond 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 states it can create, update, or deactivate students, but then specifies 'Flattened action: deactivate', creating confusion. The tool name and sibling tools suggest it is specifically for deactivation, yet the description includes actions for create and update.

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 explicitly state when to use this tool versus the dedicated mfit_client_write_create and mfit_client_write_update siblings. It mentions actions but fails to provide clear guidance on tool 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?

Beyond annotations (which are all false), the description adds valuable behavioral context: deactivation is reversible via update, gender is statically constrained to m/f, groupId is dynamic and requires a prerequisite call to list_groups, and bulk execution via client_ids is supported. This enriches the agent's understanding of side effects and preconditions.

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 very concise, using a structured list to clearly separate actions and field types. Every sentence adds value, and the key information is front-loaded. 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?

Given 11 parameters, no output schema, and limited annotations, the description is moderately complete. It explains the main actions and bulk support but lacks details on return values, error handling, and several parameters. Additional context about side effects or response format 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?

The description explains a subset of parameters (name, email, phone for create; gender; groupId; client_ids) but leaves 5 of 11 parameters undocumented (e.g., lastName, birthDate, account, blockOverdue, client_id). With 0% schema coverage, the description partially compensates but remains incomplete for many 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 tool creates, updates, and deactivates students in MFIT, and identifies the default action as update via '[Flattened action: update]'. However, the inclusion of create and deactivate when dedicated siblings exist (mfit_client_write_create, mfit_client_write_deactivate) introduces slight ambiguity about which tool to use for each 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?

No explicit guidance on when to use this tool versus the create or deactivate siblings. The description implies it handles multiple actions but does not specify conditions for choosing this tool over its counterparts. The '[Flattened action: update]' hint is insufficient 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 already indicate readOnlyHint=true and idempotentHint=true, so the description's 'Get' alignment is sufficient. No additional behavioral context is provided, but annotations carry the burden, resulting in an adequate score.

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, front-loaded sentence that efficiently conveys the tool's purpose. It could be improved by incorporating parameter details, but remains 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 (1 parameter, no output schema), the description omits critical details: the 'account' parameter and return format. While the core purpose is clear, the lack of completeness hinders effective usage 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 description does not explain the single parameter 'account'. With 0% schema description coverage, the description should compensate but fails to add any meaning. This leaves the agent without guidance on how to use the 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 clearly states the tool retrieves anamnesis form templates, with an example (PAR-Q). It uses a specific verb 'Get' and resource 'anamnesis form templates', and distinguishes from sibling 'get' tools by focusing on a unique domain.

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 to get templates for sending to students. However, no explicit guidance on when to use versus alternatives, nor any exclusions. Since no sibling tool covers anamnesis, the description is adequate but lacks explicit direction.

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 behavior. Description adds that it returns a summary count of active and inactive students, but does not detail the response structure or define 'active/inactive'. With annotations, the description adds moderate 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, front-loaded sentence without fluff. It is concise but could benefit from slightly more detail without being verbose.

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, so the description should explain the return format. It does not. Also lacks parameter explanation. For a simple tool, it 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?

The schema has one optional parameter 'account' with 0% description coverage. The tool description does not mention the parameter, leaving its purpose and effect completely 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 it gets a summary count of active and inactive students, which is a specific verb and resource. It distinguishes from sibling tools like mfit_client_list (list clients) and mfit_client_get (single client detail).

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_client_list or other count-related tools. No mention of prerequisites or 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, and destructiveHint=false, covering safety. The description adds context about the returned data fields but does not describe any edge cases or constraints. 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?

Description is a single, clear sentence. It is front-loaded and concise. Minor improvement could include listing parameters explicitly, but it is not wasteful.

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 tool with 3 parameters, no output schema, and no nested objects, the description is mostly adequate. However, it omits details like default behavior, output format, and whether all evaluations are returned. Lacks completeness for a fully self-contained definition.

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

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

Schema description coverage is 0%. The description weakly hints at multiple students via 'one or many' but provides no explanation of account, client_id, or client_ids parameters. It does not compensate for the lack of schema documentation.

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 retrieves evaluations with specific data points (heart rate zones, VO2max, training frequency) for one or many students. It uses strong verb 'Get' and identifies the resource ('evaluations'), distinguishing it from sibling tools like 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. Sibling tools such as mfit_get_training_frequency or mfit_get_client_workouts exist but the description does not differentiate usage scenarios or mention 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 and destructiveHint=false, so the description's 'Read' aligns. It adds the bulk capability detail but does not disclose any 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 extremely concise: one sentence, 12 words. It front-loads the primary action and resource, with 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?

No output schema is provided, but the description does not mention the return format, pagination, ordering, or any constraints. Given the tool has 3 parameters, especially 'account', the description lacks 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?

With 0% schema description coverage, the description partially compensates by noting 'bulk via client_ids', but it does not explain the 'account' parameter or the difference between client_id and client_ids.

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 ('Read notes/observations'), the resource ('notes/observations for one or many students'), and mentions bulk capability via client_ids, distinguishing it from sibling tools like mfit_get_client_notes_write.

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 reading notes but does not explicitly state when to use this tool versus alternatives, nor does it provide when-not-to-use or prerequisites. No guidance on bulk vs. single student 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?

Description says 'Replaces any existing notes text' (destructive behavior) but annotations set destructiveHint=false. This is a direct contradiction, misleading the agent.

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

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

Two concise sentences, front-loaded with primary purpose, bulk support added efficiently. No 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?

Covers key purpose and bulk capability, but lacks output description and parameter details. The annotation contradiction undermines completeness. Adequate but with clear gaps.

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

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

With 0% schema description coverage, description should compensate but only mentions 'client_ids' for bulk and implies 'notes'. Does not explain 'account' or differentiate between 'client_id' and 'client_ids' 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?

Clearly states 'Save (overwrite) notes/observations for a student' with specific verb (save/overwrite) and resource (notes). Distinguishes from sibling 'mfit_get_client_notes' which is read-only.

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 when to use: to set or overwrite notes, singly or in bulk. Does not explicitly state when not to use or alternatives, but sibling tool names provide 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, destructiveHint=false, idempotentHint=true. Description adds 'Supports bulk via client_ids' which is useful but does not disclose rate limits, permissions, or return format. Adds moderate value 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, no filler. Every word 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?

No output schema. Description does not mention return format, pagination, or error conditions. For a list operation, more detail would help agent anticipate 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?

Schema coverage is 0%. Description only mentions 'bulk via client_ids' but does not explain any parameter (account, client_id, client_ids). Agent cannot infer meaning or constraints from 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?

Description specifies verb 'Get', resource 'workout routines', scope 'assigned to one or many students', and mentions bulk capability. Clearly distinguishes from siblings that deal with individual routines or different entities.

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 vs alternatives like mfit_workout_get_routine. Does not state exclusions or context where other tools might be better.

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, but the description adds no additional behavioral context (e.g., requires authentication, returns a list, etc.). The description is a near-tautology of the tool name, providing no extra value beyond structured data.

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 very short, but it is underspecified rather than concise. It barely earns its place as it adds no information beyond the tool name.

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 zero output schema, no parameter descriptions, and a single vague sentence, the tool is severely underdocumented. Numerous sibling tools exist, but no context helps the agent decide when to invoke this one.

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%, yet the description does not explain the sole parameter 'account' whatsoever. The agent receives no semantic help beyond the parameter name.

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 'Get the trainer's favorite exercises,' which clearly indicates the verb (get) and resource (favorite exercises). It is specific enough to distinguish from siblings like mfit_get_user_exercises, though it does not explicitly differentiate.

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 or mfit_get_user_exercises. No context or exclusions 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 and destructiveHint, indicating a safe read operation. The description adds detail on the data returned (student name, RPE, etc.) and the scope (unread feedbacks), enhancing transparency without contradiction.

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

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

Two concise sentences that front-load the main purpose and then list included fields. 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?

Describes the output data well, but fails to address the input parameter. For a tool with only one parameter and no output schema, this is a notable gap.

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 single parameter 'account' has 0% schema description coverage. The description does not explain its purpose, meaning, or required format, leaving the agent to guess.

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 verb 'Get' and resource 'unread workout feedbacks from students', differentiating from sibling tools like mfit_get_client_list or mfit_get_client_workouts. Specifies the content of each feedback.

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?

Implies usage for retrieving unread feedbacks, but provides no explicit guidance on when to use this tool versus alternatives (e.g., other 'get' tools) or when not to use it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, covering safety. The description adds no behavioral traits beyond listing returned data categories, which is useful but not behavioral.

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

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

One concise sentence that front-loads the main action. No wasted words, but could be more structured with separate listing of components.

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 3 parameters, the description covers the main return components but lacks details on output format, pagination, or error handling. Adequate for a simple read-only tool but not highly complete.

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

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

Schema description coverage is 0%, so description must explain parameters. It implies start_date and end_date are for date range via 'transactions in date range' but does not explain the optional 'account' parameter. Partial compensation for missing schema 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 it gets a financial overview, specifying three components: transactions in date range, wallet/payment info, and seller status. It uses a specific verb and resource but does not explicitly differentiate from sibling tools like mfit_get_invoices.

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 or prerequisites. The description only states what it does without providing context for proper usage.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that it can retrieve invoices for one or many students via client_ids, but does not add behavioral context beyond what annotations provide (e.g., no mention of authorization 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?

Single, front-loaded sentence that efficiently conveys the core purpose without extraneous words.

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

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

With no output schema, the description omits critical details such as response format, behavior when no parameters are provided, and potential pagination. For a billing tool, these gaps reduce 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 description coverage is 0%, so description must compensate. It explains that client_ids enables bulk retrieval but does not clarify the roles of 'account' or 'client_id', leaving two parameters undocumented.

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 specifies the verb 'Get', the resource 'invoices/billing', and the target 'students'. It distinguishes between single and bulk retrieval via client_ids, clearly differentiating from sibling tools like mfit_get_finances (broader finance) and mfit_client_get (client 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?

No explicit guidance on when to use this tool versus alternatives (e.g., mfit_get_finances for finance overview). It implies usage for invoices but does not state when not to use or provide 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 indicate readOnlyHint, idempotentHint, and destructiveHint. The description adds value by listing the returned fields, but it does not disclose any additional behavioral traits such as authentication requirements, rate limits, or that it only returns the trainer's own profile.

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, front-loaded sentence with no extraneous words. Every word adds value, stating the action, resource, and return fields.

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 is simple with one optional parameter and no output schema. While the return fields are listed, the missing parameter explanation and lack of usage context make it adequate but not complete. It meets the minimum viable level.

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%, yet the description provides no explanation of the 'account' parameter, its purpose, or its format. The user cannot determine what value to pass or whether it is needed.

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'), the resource ('trainer's own MFIT profile'), and the specific fields returned (name, email, plan, payment country). It distinguishes this tool from sibling tools like mfit_client_get which retrieve client profiles.

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 (e.g., other mfit_get_* tools) or prerequisites like authentication. It does not mention that the 'account' parameter is optional or how to decide whether to provide it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the description adds minimal behavioral insight beyond mentioning period comparison. However, it does not disclose any additional traits like data freshness or access 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?

The description is a single efficient sentence that front-loads the purpose and key metrics. 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?

For a simple read-only tool, the description is adequate but incomplete. It does not describe the output format or clarify what 'comparison' entails. Given no output schema, more detail 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%, so the description should compensate. It mentions 'current period vs previous' and a default of CURRENT_MONTH, but does not explain the period parameter format, allowed values, or the account parameter at all. This leaves significant 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 retrieves a retention dashboard with specific metrics (active clients, engagement rate, growth rate, churn rate, NPS) and comparison between periods. It distinguishes itself from siblings like mfit_get_retention_clients by indicating it provides aggregate dashboard data rather than individual client 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 implies usage for obtaining retention dashboard data but provides no explicit guidance on when to use this tool versus alternatives (e.g., mfit_get_retention_clients). It lacks context about prerequisites 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 indicate readOnlyHint=true and idempotentHint=true, so the description is not required to repeat that. The description adds value by disclosing returned data fields (days since last workout, avg weekly workouts, WhatsApp link) and the filtering by status, which is not evident from 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?

Two sentences, front-loaded with key information. Every sentence adds value, though the comparative claim is somewhat promotional. Could be slightly more structured, 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 no output schema, the description adequately explains the return fields. However, it lacks parameter documentation for 'account' and does not clarify how the retention statuses map to parameters or the exact output structure. Sibling tools like mfit_get_retention exist, but the description does not differentiate from them.

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 partially explains the 'status' parameter by listing possible values (AT_RISK, ABANDONED, ACTIVE, all), but does not describe the 'account' parameter at all. This leaves a significant gap for a tool with two 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 tool lists students by retention status (AT_RISK, ABANDONED, ACTIVE, or all) and provides specific data fields returned. It explicitly distinguishes itself from generic client listing by emphasizing it identifies who needs attention, making the purpose highly specific and unambiguous.

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

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

The description gives strong usage guidance by comparing to client listing ('Much more useful than listing clients — this tells you WHO NEEDS ATTENTION'), implying when to prefer this tool. However, it does not explicitly state when not to use it or mention alternatives among sibling retention tools (e.g., mfit_get_retention).

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 reveals that the tool scans all active students and returns two lists, and that it is a single call. Annotations already mark it as read-only and idempotent, so the description adds value by detailing the output format and efficiency.

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, no waste. The core purpose is stated first, followed by output details and efficiency note. 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 read tool without an output schema, the description covers what the tool does and what it returns. However, it omits details about the account parameter and the exact structure of the lists, leaving minor gaps.

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

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

The input schema has one optional parameter (account) with 0% description coverage. The description does not mention this parameter or its purpose, leaving its effect ambiguous. For a low-coverage schema, the description should compensate but fails to do so.

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 checks which students trained today, promising two lists (who_trained and who_didnt). This specific verb+resource distinguishes it from sibling tools, none of which focus on today's check-ins.

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 indicates the tool is a single call for today's check-ins and contrasts with checking one by one. It provides clear context for when to use it, though it does not explicitly exclude alternatives or name 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 and idempotentHint. The description adds that it returns true/false per day of week, which is useful but not extensive. 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?

Two compact sentences, front-loaded with the core action. Every word earns its place.

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

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

For 5 parameters and no output schema, the description is insufficient. It omits details like date format, account parameter, and the exact response structure.

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 mentions 'one or many students' and 'date range' but lacks details on format, constraints, or the account parameter. Minimal added 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 it gets training frequency for days of the week, with a specific verb and resource. It doesn't explicitly distinguish from sibling tools like mfit_get_training_ranking, but the purpose is clear enough.

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

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

No guidance on when to use this tool vs alternatives. The description only states what it does, without context for 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?

Description adds that it uses 'bulk frequency checks' and 'returns top performers', providing some behavioral context beyond annotations. Annotations already indicate readOnly, idempotent, and non-destructive. No mention of authentication or edge cases, but adequate given annotation coverage.

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

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

Two concise sentences with no wasted words. Front-loads the essential purpose and behavior. Ideal length for a quick understanding.

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 and no output schema or parameter descriptions, the description is too minimal. It does not explain key parameters like 'limit', 'status', 'account', 'include_frequency_payload', or the expected output format. Missing critical details for proper 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 description coverage is 0% and the description provides no information about any of the 7 parameters. The only hint is 'in a period (default: current month)' which loosely relates to 'month' or date parameters, but no concrete semantics. This is insufficient for a tool with many 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?

Description clearly states it ranks students by training frequency in a period (default: current month). The verb 'ranking' and resource 'students trained' are specific. However, it does not explicitly differentiate from sibling tool mfit_get_training_frequency, which might also involve frequency checks.

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 implies it's for ranking/top performers, but does not mention when not to use it or provide comparisons with siblings like mfit_get_training_frequency or mfit_get_client_workouts.

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 only adds that exercises are 'custom' and 'created by trainer,' which provides marginal behavioral context beyond safety flags. No disclosure of authentication needs, rate limits, or response structure.

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 with no wasted words. It is front-loaded and efficient, though very sparse. Could be improved with more structure (e.g., explanation of parameter), but it is 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 no output schema, an undocumented parameter, and minimal annotations, the description is insufficient. It does not clarify what the tool returns, how the 'account' parameter affects results, or any other context needed 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?

The input schema has one parameter 'account' with no description, and the schema coverage is 0%. The description does not explain the purpose or usage of this parameter, leaving it completely ambiguous.

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 'custom exercises created by the trainer.' This distinguishes it from sibling tools like mfit_search_exercises (general search) and mfit_get_exercise_favorites (favorites list). The scope 'created by the trainer' adds specificity.

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 such as mfit_search_exercises or mfit_get_workout_library. The description does not include any conditional or contextual advice.

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 does not need to repeat safety. It adds value by noting batched execution support, which is a behavioral detail 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 two sentences with no redundant words. It is front-loaded with the core purpose and key usage note.

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 does not describe the output format or structure, and there is no output schema. While the read-only nature reduces need for side-effect details, the lack of return value information is a gap given the tool's complexity.

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

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

Schema description coverage is 0%. The description adds meaning for folder_id (root usage) and folder_ids (bulk support) but ignores parameters 'type' and 'account'. It partially compensates.

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 'Browse' and the resource 'workout library folders and saved routines'. It distinguishes from siblings like mfit_workout_get_routine and mfit_workout_get_session, which target specific items.

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 specific usage hints: 'Use folder_id=0 for the root' and 'Bulk support: accepts folder_ids'. It implies browsing rather than fetching a single routine, but does not explicitly exclude alternative 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, idempotentHint, destructiveHint. Description adds valuable context about return fields, is_default semantics, and how other tools consume account info. 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?

Single paragraph packs essential info without redundancy. Front-loaded with main action. Could benefit from slight structuring, but no wasted sentences.

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

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

With no output schema and one optional param, description sufficiently covers purpose, return fields, and integration with sibling tools. Lacks explicit return structure but is functional for agent 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?

Input schema has one optional param 'account' with 0% description coverage. Description mentions account in context of other tools but does not clarify whether this tool accepts it or its purpose here. Ambiguous, leaving a 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?

Clearly states 'List all MFIT accounts linked to this install' with specific verb and resource. Lists return fields (id, email, label, is_default) and distinguishes from siblings by being the account listing 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?

Explicitly explains when to use this tool (first step) and how output is used by other tools (account parameter). Tells when account param is optional based on is_default flag, providing clear 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 already declare readOnlyHint=true and idempotentHint=true, so the safety profile is clear. The description adds the return structure (exercise name, category, muscle group, URL). However, it does not mention pagination behavior (page and hits_per_page parameters) or the optional account parameter, which are behavioral details 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 two sentences, starts with the action and resource, and lists the output fields. 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?

Given the absence of an output schema and 0% schema description coverage, the description should cover more context. It mentions returned fields but omits details about pagination parameters and the account parameter. The tool is simple but incomplete for agent invocation without additional inference.

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 the 'query' parameter supports Portuguese or English names, but it does not describe the 'page', 'account', or 'hits_per_page' parameters. This leaves most parameters without semantic 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 tool 'search[es] the exercise library by name' and lists the returned fields (name, category, muscle group, video/image URL). It distinguishes itself from sibling tools like mfit_get_exercise_favorites and mfit_get_workout_library which serve different retrieval purposes.

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 on when to use this tool—when you need to search exercises by name in Portuguese or English. It does not explicitly exclude other tools or provide alternative suggestions, but the purpose is unambiguous.

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 destructiveHint=true, so the description adds value by clarifying that delete_exercise is irreversible and specifying how to get exercise_session_id from another tool. Also mentions bulk support, enhancing 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 fairly long and includes a bullet list and flattened action note. It is structured but contains extraneous information (other actions) that could be omitted for the specific 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 7 parameters with 0% coverage and no output schema, the description should be thorough. It covers only a few parameters and does not explain return values or error behavior, leaving significant gaps for an agent.

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 compensate. It mentions routine_ids, session_ids, exercise_session_ids for bulk and exercise_session_id in the hint, but fails to describe account, routine_id, session_id, leaving many parameters ambiguous.

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 multiple destructive actions (delete_routine, delete_session, delete_exercise) beyond the tool's name, which focuses on delete_exercise. While it specifies the delete_exercise action and provides a hint, the mixed purpose reduces clarity, especially with sibling tools for routine and session deletion.

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 bulk support and provides a hint on obtaining exercise_session_id, but does not explicitly guide when to use this tool over siblings like mfit_workout_delete_routine or mfit_workout_delete_session. The 'Flattened action: delete_exercise' note is helpful but not sufficient.

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 destructive and non-readOnly. Description adds value by detailing soft-delete (reversible) vs irreversible, and bulk support. 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?

Description is well-structured with bullet points and front-loaded purpose. Slightly verbose but efficient overall.

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 explanation of return values and does not specify that at least one identifier parameter is needed. Sibling tool ambiguity is unresolved. Adequate but incomplete for a multi-action 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 coverage, description adds some meaning (identifies key parameters like routine_id, session_id, exercise_session_id and bulk variants), but does not explain 'account' parameter or clarify required combinations.

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 it handles destructive operations on routines, sessions, and exercises, specifying soft-delete vs irreversible. However, it does not differentiate from sibling tools mfit_workout_delete_exercise and mfit_workout_delete_session, causing potential 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?

Provides no guidance on when to use this tool vs alternatives (e.g., separate delete tools). Implies usage for any deletion but lacks explicit 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 set destructiveHint: true. The description adds important behavioral context: delete_session is irreversible, delete_routine is reversible (soft-delete), and bulk support. It does not describe return format or side effects, but the destructive nature and irreversibility are clearly stated.

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 reasonably structured with a list of actions and a flattened action note, but it includes extraneous details about other actions that are not the primary function. Could be more concise by focusing solely on delete_session and moving sibling actions to a 'see also' note.

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 destructive tool with 7 parameters and no output schema, the description covers key aspects: irreversibility, relationship to other tools, and parameter sourcing for exercise_session_id. Missing details on account and single-id parameters, but bulk support is well described. Adequate for an agent to invoke correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It adds context for exercise_session_id by referencing another tool, and mentions bulk parameters (routine_ids, session_ids, exercise_session_ids). However, it does not explain account, routine_id, session_id, or the exact role of each parameter. Partial improvement over the bare schema.

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

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

The description clearly states the tool performs 'delete_session', but it also lists other destructive operations (delete_routine, delete_exercise) which are handled by sibling tools. The 'Flattened action: delete_session' clarifies the intended action, but the extraneous list may cause confusion. Distinguishes from siblings as a session-specific deletion 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?

The description implies that this tool is for delete_session via 'Flattened action: delete_session', but does not explicitly state when to use it versus sibling tools for routine/exercise deletion. No guidance on prerequisites or when not to use. Bulk support mention is useful but insufficient for clear usage direction.

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 behavior. The description adds bulk support details but omits explanation of the 'Flattened action' concept and does not disclose error conditions or limitations.

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?

Relatively concise with three clear segments: purpose, action list, bulk support. Could be slightly more structured but effective.

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 output schema, and no nested objects, the description is insufficient. It fails to explain how to retrieve a single session versus routine, or when to use bulk parameters. Lacks completeness for an agent to use without trial and error.

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 should clarify each parameter's role. It only mentions routine_ids and session_ids for bulk, leaving account, routine_id, and session_id unexplained. No detail on parameter relationships or optionality.

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, listing two specific actions (get_routine and get_session). However, it doesn't differentiate itself from the sibling tool mfit_workout_get_session, which likely has a similar 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?

There is no guidance on when to use this tool versus the sibling mfit_workout_get_session. The description mentions bulk support but lacks explicit context for selection between routine_id/session_id and bulk arrays.

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 value by specifying the content of the response (exercises, series, exercise IDs) and the bulk execution capability with routine_ids and session_ids. 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 relatively concise and front-loaded with the main purpose. The bullet list of actions and bulk support note are useful. Some redundancy exists (tool name already implies session focus), but overall it is 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?

The description explains the session content and bulk support but does not address the required parameters (none are required, but usage context is missing), response structure (no output schema), or how routine_id and session_id relate. Given five parameters and no output schema, more detail 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?

With 0% schema description coverage, the description must compensate for parameter meaning. It explains that routine_ids and session_ids enable batched execution, which helps for the array parameters. However, it does not clarify the use of individual routine_id and session_id parameters or the account 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 clearly states the tool reads workout routines and sessions, specifically detailing 'get_session -- session prescription with all exercises, series, and exercise IDs'. It distinguishes from the sibling 'get_routine' action, making the purpose unambiguous.

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

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

The description outlines two separate actions (get_routine and get_session) which helps the agent choose between them. It also mentions bulk support. However, it does not explicitly state when to use this tool versus others or provide exclusion criteria.

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, so the tool performs non-destructive writes. The description adds that archive_routine is reversible and unarchive_routine restores, and explicitly directs destructive operations to another tool. It also mentions bulk support. However, it does not disclose idempotency or error behaviors 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 lengthy, listing multiple actions with bullet points and static options. The flattened action note is helpful, but the inclusion of many actions under a single tool description makes it less concise than focusing on the add_exercise action. The structure is readable but could be streamlined.

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 parameter count and no output schema, the description should explicitly link parameters to actions. It partially does for a few (exercise_id for add_exercise), but fails to cover parameters like instructions, showTrainingTime, or the bulk IDs. The static options only cover four fields; the rest are underdocumented. The description does not specify which parameters are required per action, leaving the agent underinformed.

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 26 parameters with 0% description coverage. The description provides static option mappings for trainingType, goal, difficulty, and day, adding value for those. However, many parameters (e.g., name, reps, rest, weight, allowPdfDownload) are not explained in the context of specific actions, leaving the agent to infer their usage from names alone.

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 says 'Create / update workout routines, sessions, and exercises', which broadly states its purpose. However, the tool name specifically focuses on 'add_exercise', yet the description includes many other actions (create_routine, update_routine, archive, etc.), causing ambiguity about the tool's primary function. The flattened action note hints at add_exercise, but the extra actions dilute 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 gives some usage guidance: for destructive operations use mfit_workout_delete, and references mfit_search_exercises to find exercise_id and mfit_workout get_session for serie IDs. However, it does not clarify when to use this aggregated tool versus separate sibling tools like mfit_workout_write_create_routine or mfit_workout_write_create_session, which exist for specific 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?

Annotations indicate readOnlyHint=false and destructiveHint=false, which align with the description's assertion that archive_routine is reversible. The description adds no additional behavioral context beyond what annotations imply, so it meets the baseline without exceeding it.

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 well-structured with bullet points for actions and static options, but it is somewhat lengthy and includes the confusing 'Flattened action' note. Every sentence serves a purpose, but the redundancy due to the name mismatch reduces 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 26 parameters, no output schema, and minimal annotations, the description provides substantial context: action breakdown, enum lists, bulk support, and references to sibling tools. However, it does not cover all parameters or describe return values, leaving gaps for a tool this complex.

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 schema description coverage at 0% and 26 parameters, the description partially compensates by listing actions and their relevant parameters, plus enum options. However, many parameters (e.g., account, allowPdfDownload) remain unexplained. The added value is moderate, not enough to reach a 4.

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 lists multiple actions (create, update, archive, etc.) but the tool name ends with 'archive_routine', creating confusion. The 'Flattened action: archive_routine' suggests a specific purpose, yet the intro claims 'Create / update workout routines, sessions, and exercises'. This inconsistency muddles the tool's core purpose, earning a 3.

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 guidelines for destructive operations (referring to mfit_workout_delete) and suggests using mfit_search_exercises to find exercise IDs. However, it lacks differentiation from sibling tools like mfit_workout_write_create_routine or mfit_workout_write_update_routine. The context is helpful but not sufficiently prescriptive.

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

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

With all annotation hints false, description provides crucial behavioral details: archive/unarchive status behavior, add_exercise adds empty set, bulk execution. Discloses reversible nature of archive. Lacks return value info but sufficient for safe usage.

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 front-loaded with overall purpose, then bullet actions, options, sibling references. Well-organized but slightly verbose; could be more concise while retaining 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 26 params, no output schema, and no enums in schema, description provides essential context: action definitions, parameter relationships, enum values, and tool chaining. Missing explanation for some less common parameters but covers core workflow thoroughly.

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% description coverage; description adds meaning for many parameters (client_id, routine_id, session_id, etc.) through action context and lists static options for enums (trainingType, goal, difficulty, day). Some params (e.g., instructions, allowPdfDownload) not explained, but overall compensates well.

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 (create_routine, update_routine, etc.), distinguishing it from sibling delete tools (mfit_workout_delete_*).

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 guides use of sibling tools: use mfit_search_exercises for exercise_id, mfit_workout_get_session for series IDs, and directs destructive operations to mfit_workout_delete. Also mentions bulk support.

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 beyond annotations: it lists multiple actions (create, update, archive, unarchive) and notes that archiving is reversible, mentions bulk support, and gives specific guidance on retrieving IDs using other tools. However, it does not clarify how the tool selects an action (e.g., based on which parameters are provided) or disclose any side effects 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?

The description is somewhat structured with a bullet list of actions and static options, but it is verbose and contains redundant statements (e.g., the first line repeats the actions list). The 'Flattened action: create_session' note is confusing and disrupts clarity. It could be more concise by focusing on the actual scope of this 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 the zero schema coverage and no output schema, the description fails to provide sufficient context for a 26-parameter tool. It does not explain which parameters are required for each action, the expected data types beyond numeric codes, or the workflow order. While it references related tools for finding IDs, it lacks examples or a clear usage pattern, making it incomplete for 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?

The input schema has 26 parameters with 0% description coverage. The description only explains static options for trainingType, goal, difficulty, and day, and briefly mentions how to get serie_id and exercise_session_id. The vast majority of parameters (reps, weight, rest, account, dates, etc.) are left unexplained, forcing the agent to guess their meaning and 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 claims to 'Create / update workout routines, sessions, and exercises' but the tool name and '[Flattened action: create_session]' suggest it is specifically for creating sessions. This ambiguity is compounded by the existence of sibling tools like mfit_workout_write_create_routine and mfit_workout_write_add_exercise, which implies this tool may not be the correct choice for those actions. The purpose is vague and inconsistent.

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 destructive operations should use mfit_workout_delete, but does not provide guidance on when to use this tool versus the other write siblings (e.g., mfit_workout_write_create_routine, mfit_workout_write_add_exercise). It seems to suggest this tool can handle all non-destructive writes, which may mislead the agent into using it for actions better served by more specific 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 indicate write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds that unarchive is reversible and mentions bulk support, but does not disclose any side effects, permissions, or state changes beyond what annotations imply. The lengthy action list obscures the precise 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 excessively long and dense, mixing multiple actions and options. It is not front-loaded; the specific action 'unarchive_routine' appears mid-list. Several sentences could be removed or reorganized to improve 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?

Given 26 parameters, no schema descriptions, and no output schema, the description is very incomplete. It fails to explain which parameters are needed for unarchive, the expected response, or preconditions. The inclusion of unrelated actions adds noise.

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 26 parameters with 0% described. The description adds static option mappings for trainingType, goal, difficulty, day, and mentions bulk IDs, but does not specify which parameters are relevant for the unarchive action. High parameter count requires more 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 starts with 'Create / update workout routines...' which is too broad and does not match the tool's specific action 'unarchive_routine'. While it lists 'unarchive_routine' later, the overall purpose is unclear and fails to distinguish from siblings like mfit_workout_write_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?

The description mentions 'For destructive operations use mfit_workout_delete' but does not provide guidance on when to use this tool versus other write tools (e.g., archive, create, update). No explicit when-to-use or when-not-to-use context is given.

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

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

Annotations are sparse (readOnly=false, destructiveHint=false). Description adds useful context: archive/unarchive are reversible, bulk support exists, and references other tools for IDs. However, it does not disclose whether updates overwrite or merge, authorization needs, or side effects beyond stated operations.

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 lengthy and poorly structured. Key information like 'Flattened action: update_routine' and bulk support is buried at the end. The list of actions and options makes it verbose; a clearer ordering would help.

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 26 parameters and no output schema, the description lacks completeness. It does not explain return values, required parameters (none required, yet some actions need IDs), or the full behavior of each action. Relies on referencing other tools, but still 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?

Schema description coverage is 0%, so description must compensate. It provides static option mappings for trainingType, goal, difficulty, day, and explains how to use serie_id and exercise_session_id via get_session. But many parameters (e.g., account, endDate, allowPdfDownload) are undocumented.

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 states 'Create / update workout routines, sessions, and exercises in MFIT', which is a clear verb+resource. However, it includes multiple sub-actions beyond updating (create, archive), and there is a sibling tool 'mfit_workout_write_create_routine' for creation, so the purpose blurs with 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?

Description mentions 'For destructive operations use mfit_workout_delete', providing a when-not for deletes. But it does not differentiate when to use this composite tool versus its sibling tools like mfit_workout_write_create_routine, mfit_workout_write_add_exercise, etc., 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 indicate readOnlyHint=false (write operation) and destructiveHint=false. The description adds context by listing the write actions, providing static option enums, and mentioning bulk support. However, it does not disclose whether updates overwrite or append, what happens to existing data, or any required permissions. The bulk support is mentioned but not explained in terms of 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 verbose and includes a bullet list of multiple actions that may not all be relevant to this specific tool. The key information about updating a serie is buried near the end after a long enumeration. The structure could be more focused and front-loaded with the tool's primary purpose.

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, no required fields, no output schema), the description is incomplete. It lacks explanations for many parameters, no example usage, no error handling info, and no return value description. The bulk support is mentioned but not detailed. An agent would struggle to use this tool correctly without additional documentation.

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

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

The input schema has 26 parameters with 0% description coverage. The description adds meaning for some parameters: trainingType, goal, difficulty, day (with enum values), and mentions serie_id, exercise_session_id, and bulk fields. However, many parameters (e.g., allowPdfDownload, showTrainingTime, instructions, account) are not explained, leaving gaps for an agent to understand their purpose.

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' and lists multiple actions, but the tool name is specifically 'update_serie'. The 'Flattened action: update_serie' note clarifies the primary purpose, but the inclusion of other actions (e.g., create_routine) creates ambiguity about which actions this tool supports versus sibling 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 provides some usage guidance, such as using mfit_search_exercises to find exercise_id and mentioning that after add_exercise, use update_serie to configure sets. It also directs destructive operations to mfit_workout_delete. However, it does not clearly distinguish when to use this tool versus other write siblings (e.g., mfit_workout_write_create_routine), and the list of multiple actions muddles the specific context for this tool.

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 idempotentHint=true, but reporting a bug typically creates a new entry each time, suggesting a contradiction. The description does not clarify side effects, idempotency, or what happens upon submission.

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 key information. It is efficient but could include more details on parameters.

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 param descriptions, the description is insufficient. It does not cover return values or prerequisite conditions for the conversation array.

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 should compensate. It only mentions 'conversation array' but does not explain 'context' or 'message' beyond their 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 states it is for reporting bugs, missing features, or feedback. It uses specific verbs and resources, distinguishing it from related tools like mfit_get_feedbacks which retrieves feedback.

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 including the conversation array for reproduction, giving some usage guidance. However, it lacks explicit when-to-use vs alternatives and no mention of 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 and idempotentHint, indicating safe, repeatable behavior. The description adds no new behavioral details beyond stating the output content, meeting but not exceeding the baseline expectation.

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 with no unnecessary words. Every element contributes to 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?

The tool is simple and the description, combined with rich annotations, fully informs the agent about what the tool does. No output schema is needed given the straightforward return value implied by the description.

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

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

With zero parameters, schema coverage is 100%. The description is not required to add parameter details, and it correctly focuses on the tool's action. Baseline of 4 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 explicitly states 'Show the current MCP platform and adapter versions,' using a specific verb and resource. It clearly distinguishes from sibling tools like 'toolkit_info' by focusing strictly on version information.

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 versus alternatives such as 'toolkit_info'. Usage is implied by the tool's self-explanatory purpose, but the description lacks differentiation criteria.

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 the safety profile. The description adds the specific return content, which is useful but does not disclose any further behavioral traits such as latency, ordering, or potential variability. With the strong annotation coverage, the description meets the minimum bar for adding context without contradicting the annotations.

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

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

The description is a single sentence that lists all key return elements in a clear, organized manner (installed MCPs, connection status, accounts, catalog tool counts). Every phrase carries meaning, with no waste or redundancy. It is appropriately front-loaded with the verb and resource.

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 information tool with no output schema, this description is fully complete. It tells the agent exactly what the tool provides and implies its use case. There are no missing details about prerequisites, side effects, or return format that would hamper 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?

The tool has zero parameters, and the input schema is an empty object with 100% schema description coverage. Per the rubric, a zero-parameter tool gets a baseline of 4. The description appropriately omits parameter details since there are none to explain.

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 the specific verb 'Returns' and clearly defines the resource as 'current toolkit state', enumerating exactly what it includes: installed MCPs, connection status, connected accounts, and catalog tool counts. This distinguishes it from sibling data-manipulation tools, which operate on client or workout data rather than the toolkit itself.

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 this tool: whenever the agent needs to inspect the state of MCP connections, accounts, or catalog tool counts. It does not explicitly name alternatives or exclusions, but among the siblings this tool is the only one providing toolkit-level diagnostic information, so the context is clear enough. No explicit when-not-to-use guidance is given, which is acceptable given its unique role.

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