Read group activities/classes (turmas). Actions: list — list activities offered schedule — class schedule / available spots (filter by date)
[Flattened action: schedule]
| Name | Required | Description | Default |
|---|---|---|---|
| date | No | ||
| account | No | ||
| id_branch | No |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
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.
Add one secure layer between your agents and this server.
Several tools are duplicated with nearly identical descriptions, distinguished only by a '[Flattened action]' footnote (e.g. evo_activity_list vs. evo_activity_schedule, evo_member_get vs. evo_member_list, evo_prospect_write_create vs. evo_prospect_write_update). An agent would struggle to pick the correct one without parsing fine-print labels. authenticate and connect also blur the auth boundary.
The EVO tools use a rough 'evo_<noun>_<action>' pattern but mix verb positions and styles: evo_member_get, evo_list_accounts, evo_activity_schedule, evo_sales_create, evo_bank_accounts. Platform tools like authenticate, connect, report_bug, and marketplace abandon the evo_ prefix entirely, and the giant marketplace tool follows no naming convention.
26 tools is above the 15–25 'heavy' band, and several are redundant flattened variations that should be merged. The set also mixes domain-specific EVO tools with unrelated platform utilities (marketplace, toolkit_info, report_bug), inflating the count without coherent coverage.
The domain is gym management (members, activities, prospects, sales, receivables), but the surface has major gaps: no member create/update/delete, no activity-create or schedule management, and only partial write operations elsewhere. Some tools contain unresolved 'PROBE' prompts, indicating unfinished endpoints that agents cannot reliably use.