EVO Academia

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

Annotations already indicate idempotent and non-destructive behavior. The description adds useful context: the tool returns a login link when called with no arguments, accepts a pasted JWT for session-only access, and supports a permanent non-expiring configuration. It does not detail the exact response on token submission, but the overall flow is disclosed.

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 dense and packs all necessary guidance into one sentence, but it is somewhat run-on with multiple parentheticals and modes. It remains reasonably concise and front-loaded with the 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 optional single parameter, annotations, and no output schema, the description covers the main flows: permanent config, session token, and no-arg link request. It does not describe the expected response after submitting a token, but this is a minor gap for an auth flow 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 schema only defines an optional token string with no description. The description fully compensates by explaining that token should be the JWT pasted by the user and that calling with no arguments returns the login link.

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

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

The description clearly identifies the tool's purpose: authenticate an IDE agent via browser login and token submission. It distinguishes itself by stating specific actions: get a login link, paste a JWT, or configure a permanent Authorization header.

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

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

It gives explicit usage paths: no args to retrieve the link, provide token for session-only login, and recommends adding the token to server config for a permanent connection. This tells the agent exactly when and how to invoke the tool and which method to prefer.

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, and openWorldHint=false, so the safety profile is well-covered. The description adds useful behavioral context: it specifies what happens in different states (all connected vs missing credentials) and mentions the structure of the return (authenticated, pending[], connect_url). This goes beyond the annotations by explaining the conditional output.

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, two sentences, and front-loaded with the core purpose. Every sentence adds value: the first states what it returns, the second explains the conditional states. No fluff.

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

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

Given the tool's simplicity (no params, no output schema), the description is quite complete. It covers the main states and key fields. It could mention whether the status is for all providers or a subset, or whether there's any network dependency, but for a status-check tool with no params and no output schema, this is adequate. The annotations cover safety, so the description doesn't need to repeat that.

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

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

The tool has zero parameters, and schema coverage is 100% (vacuously). Per the rubric, 0 params = baseline 4. The description doesn't need to explain parameters, and it doesn't, which is appropriate.

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

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

The description states the tool returns connection status and URLs, which is a clear purpose. It distinguishes itself from sibling tools like authenticate and toolkit_info by focusing on status/URLs rather than performing auth or general info. However, it doesn't explicitly name the sibling tools but implies the difference.

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: it explains the behavior when all providers are connected vs when credentials are missing, implying it's for checking connection state. It doesn't explicitly say when not to use it or mention alternatives, but the context is clear enough for an agent to infer 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, and destructiveHint=false, so the safety profile is known. The description adds minimal behavioral context by stating it reads activities, but it does not describe pagination, response format, or any other behaviors. There is no contradiction between the description and annotations.

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

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

The description is short and uses bullet-like formatting, but it includes redundant action definitions and a confusing 'flattened' note that adds noise. While it is concise, the structure could be clearer and more front-loaded.

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

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

With no output schema and minimal parameter documentation, the description leaves significant gaps. It does not explain what the tool returns after listing activities, nor does it clarify the purpose of each parameter. For a read tool with three parameters, this 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?

Schema description coverage is 0%, so the description must compensate, but it does not. The only parameter mention is 'filter by date' under the 'schedule' action, which is then flattened out. The three parameters (date, account, id_branch) are left entirely undocumented, providing no meaning beyond the raw 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 this tool reads group activities/classes (turmas) and lists activities offered, with a clear verb+resource. It distinguishes from siblings like evo_activity_schedule by mentioning 'list' as the primary action, though the inclusion of a 'schedule' action that is later flattened introduces slight ambiguity.

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

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

No explicit when/when-not guidance is provided. The description mentions a 'schedule' action but then says '[Flattened action: list]', which could confuse an agent about when to use this tool versus evo_activity_schedule. There is no reference to alternatives or exclusions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety. It adds the action breakdown and the specific 'filter by date' detail, but does not disclose return formats, pagination, or error behavior. This is adequate given the annotations, with minor extra context.

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 uses a clear action list format. It includes only essential information, though the mention of 'list' alongside the flattened action could be trimmed. Overall, it is concise and front-loaded with the 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?

With 3 parameters, no output schema, and only basic annotations, the description should offer more operational detail. It lacks parameter semantics, expected return values, and any caveats. The tool appears simple, but the description does not fully prepare an agent to use it correctly, especially given the schema coverage 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 schema has 3 parameters with 0% description coverage. The description only mentions date filtering in the 'schedule' action, but does not explain 'account' or 'id_branch' at all. It fails to compensate for the missing schema descriptions, leaving these parameters ambiguous for the agent.

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

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

The description clearly states it reads group activities/classes, and lists the actions 'list' and 'schedule', with a note that it is flattened to the 'schedule' action. This distinguishes it from write tools like evo_activity_write_enroll and identifies the resource (turmas). However, including both actions when only 'schedule' is active creates slight ambiguity.

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

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

The description implies usage for checking class schedules and available spots, with a mention of date filtering. It does not explicitly state when to use this versus alternatives like evo_activity_list or other sibling tools, nor does it provide exclusions. The context is clear enough for a read operation but lacks direct guidance.

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

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

Annotations already disclose readOnlyHint=false and destructiveHint=false, but the description adds little beyond that. It gives example statuses (attended/cancelled) but does not explain side effects of changing status, required permissions, or whether the change is reversible.

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, but the action list plus flattened-action note creates redundancy and ambiguity. It could be tighter and clearer by focusing only on the change_status action.

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?

This is a nested-object write tool with no output schema and no parameter descriptions, so the description should provide a fuller picture. It does not specify required data fields, valid status values beyond two examples, or expected behavior/errors, leaving significant gaps.

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

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

Schema description coverage is 0%, and the data object is an unrestricted nested object, so the description must explain what keys/values are needed. It only says 'enroll a member into a scheduled class' or 'change status' without documenting the data payload or account field.

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 names a concrete operation ('change an enrollment's status') and gives examples, but the opening sentence also says 'Enroll a member in a class' and the action list includes enroll, which conflicts with the tool name and with sibling evo_activity_write_enroll. The '[Flattened action: change_status]' note partially clarifies but does not cleanly distinguish this tool from the enrollment 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?

No explicit when-to-use guidance is provided. The description lists two actions but does not say when to choose this tool over evo_activity_write_enroll or when not to use it; the flattened-action note is the only hint that enroll is not actually available here.

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, but the description does not clarify side effects like whether enrollment changes are reversible, if they require specific permissions, or what the impact of a status change is. The 'Flattened action: enroll' note is ambiguous—it does not explain behavioral implications beyond the listed actions.

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

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

The description is compact and front-loads the main purpose, followed by a simple action list. However, the 'Flattened action: enroll' note is redundant and may confuse rather than clarify, slightly reducing structural efficiency.

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, minimal annotations, and an opaque 'data' parameter, the description is insufficient for an agent to confidently invoke the tool. It does not explain required fields for 'data' or how to format status changes, leaving critical gaps for correct usage.

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

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

Schema description coverage is 0% and the schema uses an open 'data' object with no defined properties. The description mentions actions but does not explain how the 'data' parameter should be structured for each action, offering no added meaning beyond the schema's generic object type.

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 enrolls a member in a class or changes an enrollment status, listing specific actions (enroll, change_status). It distinguishes from sibling tools like evo_activity_write_change_status, but the flattened action note could confuse by indicating only one action is active.

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 like evo_activity_write_change_status, despite the sibling existing. The description does not specify prerequisites or exclusions, leaving the agent to infer the appropriate 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, which the description does not contradict. The description adds a minor scoping detail ('the gym's') but does not elaborate on return behavior, pagination, or authentication requirements. Given the annotation coverage, this meets the baseline but does not exceed 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 a single sentence with no redundant words. It is front-loaded with the action and resource, making it easy to scan. This is appropriately concise for the simple purpose, though the brevity trades off against completeness.

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 two optional parameters and no output schema, the description is severely lacking. It does not explain what the parameters do, what the output looks like, or any filtering capabilities. The low schema coverage means the description must carry this information, and it fails to do so, making the tool inadequate for an agent to use correctly.

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

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

Schema description coverage is 0%, and the description provides no explanation of the two parameters ('account' and 'id_branch'). With no additional documentation, the agent cannot know what values to supply or how they affect the result. The description fails entirely to 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 action ('List') and the resource ('the gym's bank accounts'). It is specific and easy to understand, though it does not explicitly differentiate from the sibling tool 'evo_list_accounts', which might be a broader listing tool. Still, the intent is 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?

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or comparison with sibling tools like 'evo_list_accounts'. The description simply states what it does, leaving the agent to infer 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?

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description's 'Get' is consistent with these. The description adds a small amount of context by naming the returned configuration fields, but it does not provide additional behavioral details such as auth requirements, rate limits, or behavior with missing parameters.

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, lean sentence that leads with the verb, names the resource, and lists key fields in parentheses. Every word contributes, with no filler or irrelevant detail.

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 a simple tool, good read-only annotations, and no output schema, the description provides a decent but not complete picture. It names the configuration fields, but omits any guidance on parameter usage, optionality, or what happens when no parameters are supplied. Given the tool's potential account and branch scoping, this is an avoidable 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?

Schema description coverage is 0%, so the description must compensate by explaining the input parameters. It does not mention 'account' or 'id_branch' at all, and simply says 'gym/branch configuration' without clarifying what values these parameters accept or whether they filter/scope the result. The property names are somewhat evocative, but not enough for reliable invocation.

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

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

The description uses a specific verb ('Get') and a clear resource ('gym/branch configuration'), and enumerates the content ('name, timezone, gateway, occupation, card flags'). This clearly distinguishes it from sibling evo_* tools, which target members, activities, sales, and other domains.

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 the tool—when branch/gym configuration details like timezone or gateway are needed—but it does not explicitly state when to prefer it over alternatives or mention any exclusions. Sibling tools are not referenced, so the agent infers context from the listed fields rather than explicit guidance.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds no additional behavioral context beyond the list action, such as pagination behavior, auth requirements, or response format. Given the annotations, this is minimally adequate.

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

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

The description is a single concise sentence that directly states the tool's purpose with no filler. It is front-loaded and efficient, earning perfect marks for 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?

The tool has 5 undocumented parameters and no output schema. The description only states 'list gym employees/staff' and does not explain filtering options, pagination, or the return structure. This leaves the tool incomplete for practical use, as the agent cannot safely invoke it with meaningful filters or interpret 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?

The schema includes 5 optional parameters (name, skip, take, email, account) with 0% description coverage. The description provides no explanation of these parameters, leaving the agent unable to understand their purpose, format, or how to use them for filtering. This is a critical gap for a tool with multiple 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 it lists gym employees/staff, using 'list' as a specific verb and 'gym employees/staff' as the resource. This distinguishes it from sibling tools like evo_member_list (members) and evo_prospect (prospects).

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 usage guidance is provided. The description does not mention when to use this tool vs alternatives, nor does it state exclusions or prerequisites. The agent must infer usage from the tool name and sibling context.

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

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

Annotations already indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safe, read-only nature is known. The description adds the bulk support behavior but doesn't disclose potential edge cases like pagination defaults, date format requirements, or response size. Given the annotations, a score of 3 is appropriate—it adds some value but not full 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 concise (three lines plus a bulk support note) and front-loaded with the primary purpose. Every sentence adds value: the first defines the tool, the second covers filtering, and the third mentions bulk. No fluff or 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?

The tool has 7 parameters, no output schema, and annotations only cover safety (read-only, idempotent). The description is short and doesn't cover critical usage details like pagination semantics (skip/take), date format expectations, or the distinction between member_id and member_ids. For a list tool with multiple parameters, this is insufficient for an agent to use it effectively without guessing.

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 for parameter meanings. However, the description only mentions member_id(s), start_date, end_date as filters, but doesn't explain skip, take, or account, which are likely pagination and tenant scoping. It also doesn't mention that exactly one of member_id/member_ids is needed or the semantics of date ranges. The description adds minimal parameter semantics, so a score of 2 is warranted.

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 gym entries (check-ins / turnstile access) and mentions optional filtering by member and date range. It distinguishes itself from siblings like evo_member_list and evo_activity_list by specifying the domain (gym entries), but it doesn't explicitly contrast with a similar list tool, so it doesn't fully earn a 5.

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

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

It mentions 'optionally by member and date range' and 'Bulk support', indicating when to use it (listing entries) and hinting at batched usage, but it doesn't explicitly state when not to use it or provide alternatives (e.g., for member details use evo_member_get). The guidance is implied rather than explicit.

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 readOnly, idempotent, and non-destructive hints. The description adds value by specifying the return structure ({ active, total }) and clarifying the 'active' filter, which goes beyond annotations. It does not add error or pagination details, but given the simple read-only nature, this is sufficient.

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 purpose and return shape without any fluff. 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?

The tool is simple and the return shape is given, but the unexplained parameter leaves a significant hole. For a one-parameter read-only tool, the description should at least hint at what 'account' means. Without it, the description is not fully complete.

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

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

The description does not mention the 'account' parameter at all. With 0% schema description coverage, the agent has no idea what 'account' refers to, making it impossible to correctly invoke the tool. This is a critical gap.

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

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

The description clearly states the tool's function: counting active members, and ties it to billing tier, distinguishing it from sibling tools like evo_member_list and evo_member_get. The return shape is also specified.

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 use for billing-related queries ('drives the billing tier') but does not explicitly state when to use this over alternatives or provide exclusions. It offers context but no clear guidance on selecting this tool among siblings.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description need not repeat safety traits. The description adds return details: 'Returns each account's id, dns, label, and an "is_default" flag (true when only one is linked).' It also explains the account parameter format for other tools, which is behaviorally relevant. No contradictions with annotations exist.

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, front-loads the purpose, and provides additional details efficiently. Every sentence contributes meaningful information without redundancy.

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

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

For a read-only list tool with no output schema and one optional parameter, the description covers the return format and the cross-tool usage of account. However, it omits the semantics of the tool's own 'account' parameter, which is a significant gap given the schema has no description. This prevents full comprehension and potentially incorrect 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 an optional 'account' parameter with no description (0% coverage). The description fails to explain what this parameter does for this specific tool. It only mentions that other tools accept an account parameter and how to format it, but does not clarify whether passing 'account' to evo_list_accounts filters results, returns a single account, or has any effect. This leaves the parameter 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 'List all EVO gyms/branches linked to this install.' This is a specific verb and resource, and it distinguishes from sibling evo_* tools which focus on other entities like activities, employees, or sales. The scope ('linked to this install') is explicit.

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

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

The description explains the tool's role in the ecosystem: it returns account identifiers used by other evo_* tools. It states 'When multiple are linked, every other evo_* tool accepts an optional `account` parameter; pass id, dns, or label (full or partial).' This gives clear context on when to use this tool (to obtain account info) and how it relates to siblings. It doesn't explicitly say 'use this tool before others' but implies it strongly, and it does not mention exclusions or 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?

The annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description does not need to repeat those. The description adds some behavioral clarity by showing that list is paginated and get supports multiple IDs, but it does not disclose output shape, missing-ID behavior, or any side effects or caveats 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 compact and front-loaded with the core intent, then flows from list to get and ends with the flattened action note. Every sentence or bullet adds meaningful context without redundant filler.

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

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

This is a reasonably simple read-only tool, and the description covers the high-level purpose and entry arguments. Still, the absence of an output schema and any return-value note, combined with the unclear role of account and the overlap with evo_member_list, leaves the agent with noticeable unanswered questions for a tool with 8 parameters.

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 helpfully ties name, email, document, and status to the list action and member_ids to the get action. However, it does not explain skip, take, or account, and the relationship between the flattened get action and the list-related parameters remains unclear.

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

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

The description opens with 'Read gym members', which clearly states a read-oriented purpose and resource. It then distinguishes the two main operations (list/search vs get-by-id). However, it does not explicitly differentiate itself from the sibling tool evo_member_list, and the '[Flattened action: get]' adds a bit of ambiguity about whether the list action is actually available.

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

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

The description provides usage context by describing when list versus get is appropriate: list for search/pagination and get for fetching by member_ids. However, it does not mention when to prefer this tool over evo_member_list or evo_member_count, and it lacks explicit exclusions or alternative-tool guidance.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds that list can filter by name/email/document/status and get fetches by member_ids, which is helpful. It doesn't mention pagination behavior details beyond the schema, but since annotations cover safety, a 3 is appropriate.

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 a clear structure: one-line summary followed by bullet-like list of actions. The '[Flattened action: list]' instruction is a bit vestigial but doesn't waste much space. It's front-loaded with the main 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 8 parameters and no output schema, the description covers the main actions but omits details on pagination (skip/take defaults), the 'account' parameter, and what the response contains. With read-only annotations, it's adequate but not thorough; more explanation of filter semantics and output would push it higher.

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. The description names the filterable fields (name, email, document, status) and the member_ids parameter for get, which adds meaning beyond the raw schema. However, it doesn't explain the meaning of skip/take/account or the exact format of member_ids, so it partially compensates but leaves gaps.

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

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

The description clearly states 'Read gym members' and outlines two actions: list and get, with list as the primary action. This distinguishes it from sibling tools like evo_member_get (which is likely the 'get' action) and evo_get_member_count, though it doesn't explicitly mention alternatives.

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

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

It lists the actions and their purposes (list for search/paginate, get for fetching by ids), implying when to use each. However, it doesn't provide explicit context on when to prefer this tool over siblings like evo_member_get, and it doesn't mention any exclusions or specific scenarios.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safe read behavior is covered. The description adds minimal context ('offered by the gym') but does not disclose any additional behavioral traits such as filtering behavior, branch relevance, or response format. It does not contradict 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, front-loaded sentence with no filler words, making it efficient. However, it is arguably under-specified given the two undocumented parameters; it is concise but not fully informative. Still, it earns a 4 for clean structure.

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 two optional parameters, the description ought to explain what the returned list contains and how the parameters affect results. It only states that plans are listed, which is minimally viable for a simple read-only tool but leaves the parameter semantics and response shape unclear.

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 meaning for the 'account' and 'id_branch' parameters. With no parameter hints, an agent cannot understand how to use these optional fields or which might be required for a given context. This is a significant gap that the description fails to compensate for.

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 is specific with a clear verb ('List') and resource ('membership plans'), and the parenthetical 'planos' clarifies the domain. It distinguishes itself from sibling tools like evo_member_list (which lists members) and evo_activity_list (which lists activities).

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 intended use is implied by 'List membership plans offered by the gym' — when you need to retrieve available plans. However, there is no explicit guidance on when to use this tool versus alternatives like evo_member_list or evo_get_member_count, and no exclusion criteria are given.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior, but the description adds no behavioral context such as pagination, filtering limitations, result ordering, or what data is returned. It simply repeats the list operation without enriching 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 a single concise sentence with the verb front-loaded. It contains no unnecessary fluff, making it easy to parse.

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

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

This is a 7-parameter tool with no output schema and minimal description. The description is too sparse to inform an agent about optional filters, pagination semantics, date range handling, or expected results. It is minimally viable for identifying the operation but not 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?

There are 7 parameters with 0% schema description coverage, yet the description does not explain any of them. It does not mention that email/name/account/start_date/end_date act as filters or that skip/take control pagination.

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 action ('List') on a specific resource ('prospects/leads') and clarifies the domain ('CRM'). It clearly distinguishes reads from the sibling write tools evo_prospect_write_create and evo_prospect_write_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 indicate when to use this tool versus the numerous sibling tools, nor does it mention alternatives or filtering utilities. There is no contextual guidance beyond 'list prospects/leads.'

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, destructiveHint=false, but no idempotentHint. The description does not disclose behavioral traits beyond the action list, such as whether update is idempotent, what happens on duplicate names, or any validation requirements. It adds minimal context beyond the annotations.

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

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

The description is concise and structured with a clear action list. It front-loads the primary purpose and provides a compact action breakdown. However, the '[Flattened action: create]' line is somewhat redundant and could be omitted without loss.

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

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

Given the tool has 7 parameters, no output schema, and no schema descriptions, the description is incomplete. It does not explain the 'data' object, the meaning of fields like account or id_branch, or the expected response. The description is adequate for a simple create but insufficient for the complexity of the schema.

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 does not explain any parameters beyond mentioning 'name + at least one contact' for create and 'id_prospect' for update. The 'data' object is completely unexplained, and other fields like email, phone, account, id_branch are not described. The description fails to compensate for the lack of 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 the tool creates or updates a prospect/lead, with distinct actions for create and update. It distinguishes from siblings like evo_prospect_write_update by covering both actions, though the flattened action is create. The verb 'create/update' is specific to the resource 'prospect/lead'.

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 basic guidance on when to use create vs update (requires id_prospect for update), but does not explicitly mention when to prefer this tool over siblings like evo_prospect_write_update or evo_prospect. The context is implied but not fully explicit.

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 the tool is not read-only (readOnlyHint=false), and the description implies mutation. It does not contradict annotations. However, the description does not add much beyond the annotations; it does not disclose potential side effects, permissions, or what happens on update (e.g., partial vs full overwrite). With no additional behavioral context, the score is at baseline.

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 a clear action list and a note about flattened action. It is front-loaded with the primary purpose and quickly explains the two actions. The exclusion of the bracket note 'Flattened action: update' might be confusing, but it does not add much length. Overall, it is efficient but could be slightly clearer.

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

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

Given the tool has 7 parameters, no output schema, and moderate complexity (nested object), the description is insufficient. It does not explain the 'data' parameter, the expected return format, or any business rules beyond the basic create/update distinction. Annotations are minimal, so the description should provide more guidance, but it falls short.

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 7 parameters with 0% coverage, but the description explains that 'id_prospect' is required for update and that create requires 'name + at least one contact'. This adds some meaning to parameters. However, it does not explain the 'data' parameter (which is a nested object and likely critical for action details), nor does it clarify the distinction between 'name', 'email', 'phone' vs the 'data' object. Given the low coverage, the description should compensate more, but it only partially does.

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

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

The description clearly states that the tool creates or updates prospects/leads, and it distinguishes between create and update actions. It explicitly mentions that 'update' requires id_prospect, which helps differentiate from the sibling tool evo_prospect_write_create. However, it could be more explicit about the resource being 'prospect' and the scope, but overall it is 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 provides some usage guidance: it explains when to use create vs update (create for new prospects, update for existing with id_prospect). However, it does not explicitly compare with alternatives like evo_prospect_write_create or evo_prospect, nor does it specify when not to use this tool. The guidance is present but minimal.

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 tool's safety is known. The description adds context about filtering by date/status and bulk support, which is beyond the annotations but not deeply detailed. It doesn't disclose return format or pagination behavior, but the safety profile is covered by annotations. No contradiction detected.

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 (two sentences) and front-loads the core action. However, including 'PROBE: confirm param names' is a developer note that adds noise without value for an agent. It is concise but incomplete, and the probe note reduces overall quality.

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

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

For a tool with 7 parameters, no output schema, and zero schema descriptions, the description is insufficient. It doesn't explain the return structure, pagination (skip/take), or all filter options. The mention of 'status' is misleading since no status parameter exists. The bulk support hint is useful but not enough to cover 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 mentions date filtering (start_date/end_date) and member_ids for bulk, but ignores other parameters (skip, take, account, member_id). The 'PROBE' note indicates uncertainty about param names, undermining reliability. Does not explain date formats or relationships between member_id and member_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?

Clearly states 'List receivables' with a specific resource, and mentions filtering by date/status. However, it does not explicitly distinguish from sibling list tools like evo_sales or evo_entries, though the resource name itself differentiates. The 'PROBE' note adds uncertainty but does not obscure the core 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?

Implied usage for listing receivables, with a hint about bulk support via member_ids. No explicit when-not-to-use or alternatives are given, but the description does mention filtering options and batched execution, which provides some usage context. No exclusions or comparisons to other 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 readOnlyHint=false and destructiveHint=false, so the description doesn't need to cover those. The description adds that it marks an item as received/paid, which is a mutation. The PROBE warning about confirming body shape is a transparency note about schema uncertainty, but it does not disclose side effects, required auth, or response behavior. This adds some value beyond annotations, but not extensively.

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 (two sentences), so it is concise. However, the second sentence 'PROBE: confirm body shape with a live gym' is a developer note that is not informative for tool selection or invocation; it adds noise. While brevity is good, the content should be purposeful. The structure is simple but the PROBE instruction is extraneous.

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?

This is a mutation tool with a nested object parameter, no output schema, and no descriptions in the schema. The description fails to explain what the 'data' object should contain, what the effect of marking as received is, or any side effects. Given the tool's complexity and lack of schema information, the description is severely inadequate for an agent to use it correctly.

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

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

Schema description coverage is 0%, and the description provides no information about the parameters. The 'data' object and 'account' string are completely unexplained. With such low schema coverage, the description must compensate, but it fails to do so entirely, offering zero parameter semantics.

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

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

The description clearly states the action: 'Mark a receivable as received/paid.' This is a specific verb and resource, and it distinguishes from sibling tools like evo_receivables (likely listing) and evo_sales. However, the second sentence 'PROBE: confirm body shape with a live gym' adds ambiguity and is not part of the purpose, slightly reducing 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?

No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, when to choose it over evo_receivables or other write tools, or any exclusions. The description only states what it does, not the context of use.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description doesn't need to repeat that this is a safe read operation. The description adds date-range scoping and the Portuguese 'vendas' clarification, which is useful. However, it does not disclose behavior like pagination limits (skip/take), potential empty results, or any performance considerations, relying mostly on 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 concise sentence, front-loaded with the main action (list sales) and scope (date range). It includes a helpful Portuguese translation 'vendas' in parentheses for clarity. No wasted words, though it could be slightly more descriptive without losing conciseness.

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

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

With 5 parameters, no output schema, and minimal annotation coverage, the description is insufficiently complete. It introduces the date range but fails to explain pagination (skip/take) and account filtering, which are key for users to retrieve the correct data. Given the complexity of the schema, the description should provide more guidance on how to structure queries.

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 for parameter documentation. It mentions date range (start_date, end_date) but does not explain skip/take pagination or account filtering. The description adds minimal semantic value beyond the schema, and with zero coverage, the agent has limited guidance on how to use parameters correctly.

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

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

The description 'List sales (vendas) over a date range' clearly states the tool's action (list) and resource (sales/vendas), and the date range scope is explicit. It distinguishes itself from siblings like evo_sales_create (which creates sales) and other list tools (evo_member_list, evo_list_accounts), though it does not explicitly name alternatives.

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

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

The description implies usage for retrieving sales within a date range, which is clear enough. However, it does not explicitly state when to use this tool versus alternatives like evo_sales_create or other reporting tools, nor does it mention any exclusions or prerequisites. It is minimally adequate but lacks explicit guidance.

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

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

Annotations already indicate a non-read-only, non-idempotent, non-destructive operation, and the description simply restates the write intent without adding behavioral detail. It does not disclose side effects, required permissions, or the nature of the created sale beyond the example.

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, but the 'PROBE: confirm body shape' sentence is an instruction to the agent rather than useful tool documentation. It is concise yet sacrifices meaningful content.

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

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

With a required nested 'data' parameter, no output schema, and no parameter descriptions, the description is severely incomplete. The 'PROBE' note confirms that the body shape is unresolved, leaving the agent without enough information to invoke the tool reliably.

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

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

Schema description coverage is 0% and the description does not explain the 'data' or 'account' parameters. The 'PROBE: confirm body shape' line explicitly defers parameter understanding rather than providing semantics.

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

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

Description uses a specific verb ('Create') and identifies the resource ('a sale') with a clarifying example ('sell a membership/plan to a member'). This clearly distinguishes it from sibling tools like evo_sales or evo_prospect_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?

No guidance is given about when to use this tool versus alternatives such as evo_sales, evo_membership, or evo_prospect_write_create. The 'PROBE' note hints at schema uncertainty but does not explain use cases 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?

The description goes beyond annotations by detailing behavior such as: invoke runs MCPs even when not installed, it returns connect links if credentials are needed, checkout links if payment is required, and writes require workspace owner/admin. It also explains the distinction between installed_in_toolkit vs installed_in_workspace. No contradictions with annotations (readOnlyHint false aligns with write 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?

The description is long (~500 words) but well-structured, front-loading the central flow and then elaborating on specifics. Every section adds value—the distinction between invoke and install, the prompt library, and permission notes are all relevant. It could be trimmed slightly, but the complexity justifies the length.

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

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

Despite no output schema and a massive parameter set, the description comprehensively covers the tool's capabilities, the core workflow, edge cases (credentials, payments, permissions), the prompt library, and alternative actions. It provides enough context for an agent to effectively decide when and how to use this tool, including the distinction from sibling tools.

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 23 parameters and 0% schema description coverage, the description carries the burden. It explains the core action parameter (enum values like search, describe, invoke, install) and the interrelation of mcp_id, tool_id, and arguments. It also touches on keyword parameters like action=search, describe, and prompt library actions. However, it doesn't cover all parameters (e.g., cancel_reason, prompt_targets, request_details), but given the enormous scope, it provides substantial meaning 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 clearly states the tool's purpose as the official mcp.ai marketplace, serving as a catalog and execution engine for MCPs/tools. It distinguishes from siblings by emphasizing its role as the in-platform catalog and the way to run them, covering searches, descriptions, and invocations. The verb+resource structure is explicit and unique among 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?

Usage guidelines are explicit and comprehensive. It specifies when to use 'invoke' (for single/occasional use) vs 'install' (for permanent addition), describes the core flow (search → describe → invoke), and lists alternatives like 'report_bug', 'request_mcp', and 'list_tools'. It also clarifies when to use the prompt library actions, providing clear when-to-use and when-not-to-use guidance.

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

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

Annotations already indicate this is not read-only, not destructive, and idempotent. The description adds the behavioral requirement to include the conversation array for reproduction, which is useful. However, it does not disclose what happens after reporting, whether authentication is required, or any side effects beyond sending the report.

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

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

The description is two short sentences, front-loaded with the primary purpose, and contains no filler. Every sentence contributes useful guidance.

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 reporting tool with no output schema and a small parameter set, the description covers the main usage scenario adequately. It explains why the conversation array is needed, which is the most non-obvious part. It could be slightly more complete by describing expected outcomes, but overall it is sufficient.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning. It does explain that the conversation parameter should contain recent messages for reproduction, but it does not clarify the semantics of the required 'message' field or the 'context' field beyond what their names imply.

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

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

The description clearly states the tool's purpose with specific actions and targets: 'Report a bug, missing feature, or send feedback.' This is distinct from sibling tools like evo_activity_list or authenticate, and it is not a tautology of the tool name.

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

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

The description gives clear context for when to use this tool: any time a bug, missing feature, or feedback needs to be sent. It also provides a concrete usage instruction ('Include the conversation array with recent messages for reproduction'), though it does not explicitly name alternatives or exclusions.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is fully covered. The description adds the fact that it reports both platform and adapter versions, which is useful context beyond the annotations. No contradictions. However, it doesn't disclose whether it requires authentication or network access, but with readOnlyHint and no parameters, the behavioral expectations are minimal.

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, compact sentence that conveys the essential purpose without any fluff. It is front-loaded and every word earns its place. No redundancy with 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?

For a trivial version-query tool with no parameters, no output schema, and strong annotations, the description is sufficient to set expectations. It tells the user what info they'll get (platform and adapter versions). It could mention return format, but given the simplicity, this is adequate.

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

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

With 0 parameters, the schema coverage is 100% (no params to cover), so the baseline is 4. The description correctly indicates there are no parameters to configure, adding no extra semantics but not needing to. It's clear the tool requires no input, so parameter semantics are complete.

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 shows the current MCP platform and adapter versions, which is specific and unambiguous. It distinguishes itself from sibling tools by focusing on version information, though it could be more explicit about what 'MCP platform and adapter versions' entail.

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

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

The description implies this is a diagnostic/informational tool to check versions, which is a clear usage context. It doesn't explicitly state when not to use it, but given its simplicity and lack of alternatives among siblings, this is 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 declare readOnlyHint=true and destructiveHint=false. The description adds value by detailing the included state information (installed MCPs, connection status, accounts, catalog counts), which goes beyond the raw annotation flags. 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?

A single sentence that front-loads the purpose ('Returns the current toolkit state') and lists key output components without any fluff. 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?

With no output schema, the description must convey return contents, and it does list the main elements. It could hint at the data structure (e.g., whether it's a nested object or list), but given the simple status tool, the coverage is adequate.

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

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

Tool has zero parameters, so the description need not explain them. The schema is empty with 100% coverage, and the baseline for zero-param tools is 4. The description correctly omits parameter discussion.

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

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

The description uses a specific verb 'Returns' and clearly specifies the resource: 'current toolkit state' with enumerated details (installed MCPs, connection status, accounts, catalog tool counts). This distinguishes it from siblings like show_version and authenticate.

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 inspecting the overall toolkit state but does not explicitly contrast with alternatives. Given the simple zero-parameter nature, the context is clear enough, though explicit exclusions are absent.

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