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

Annotations already flag destructiveHint=true and openWorldHint=true, but the description adds real behavioral context: only FUTURE trainings and only ones this MCP created, so the blast radius is deliberately limited. The user-confirmation requirement is not derivable from annotations either. It does not state whether the deletion is reversible or what happens to already-synced calendar entries.

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 short sentences, zero filler, with the scope constraint and the confirmation gate both front-loaded before any invocation attempt.

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?

An output schema exists and annotations cover the safety profile, so the description only needs scope plus preconditions — which it delivers. The remaining gap is parameter identification for a destructive call, where guessing evento_id wrong is costly.

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% and neither of the two required parameters (atleta, evento_id) is described in the schema. The description adds no meaning — it never says what atleta identifies or that evento_id must refer to an event returned by listar_treinos/criar_treino, which is exactly the ambiguity that would cause a wrong deletion.

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

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

States a specific verb ("Apaga") and resource ("treino"), and narrows scope with "futuro" and "criado por este MCP", which separates it from atualizar_treino and criar_treino. It stops short of naming the sibling to use instead when the target is a past or externally-created event.

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?

Gives an explicit precondition — only call after the user confirms — which is the key gating rule for a destructive operation. It does not say what to do when the target isn't a future MCP-created training, so the alternative path is left implicit.

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 safety is covered. The description adds genuine operational context the annotations do not: the 1–42 day window limit and, importantly, that Strava-sourced activities are invisible via the API and require a Garmin sync — a data-freshness gotcha an agent would otherwise misread as 'no activities'.

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 tight sentences: the capability and its metric list come first, and the data-source caveat follows. No filler; the only slight wasted opportunity is that the caveat could be sharper about what the agent should report when data is missing.

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?

An output schema exists, so return values need not be spelled out, and the metric enumeration plus the Strava/Garmin sync caveat cover the main failure mode for a read-only aggregate tool. The remaining gap is the unexplained required 'atleta' parameter.

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 carry parameter meaning. It does clarify 'dias' with an explicit 1–42 range beyond the bare integer schema, but the required 'atleta' parameter receives no explanation at all (identifier format, whether it must match a value from listar_atletas). Partial compensation justifies a middle score.

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

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

States a specific verb+resource: a summary of completed activities over the last N days, enumerating the metrics returned (duration, HR, load, HR zones, RPE). An agent can tell it is a read-only aggregate report rather than a CRUD tool, though it never explicitly contrasts itself with siblings like listar_treinos.

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 bounds usage ('últimos N dias (1 a 42)') and notes a data-source caveat (Strava imports won't appear; athlete must sync via Garmin). However, it never says when to prefer this aggregate summary over listar_treinos or what to do if the range is exceeded — usage is implied rather than routed.

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=false, destructiveHint=false and openWorldHint=true, and the description adds genuinely new behavior: it is a partial update ("Campos omitidos ficam como estão"), it can only touch records this MCP created, and it requires prior user approval. It does not disclose what happens on an invalid evento_id or whether an external system rejects the change.

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 short sentences with zero filler: the action and mutable fields come first, and the approval gate follows. Nothing is repeated from the name or the schema.

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 mutation tool this is mostly complete: safety profile is covered by annotations, return values by the output schema, and partial-update semantics are spelled out. The remaining gap is identity resolution — how atleta and evento_id are obtained and what happens if evento_id does not exist — which an agent needs before calling.

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 carry parameter meaning. It does add real semantics for four fields by explaining that omitted/null values leave the existing value untouched (matching the null defaults), but the two required parameters, atleta and evento_id, are never explained or distinguished from the optional ones.

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

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

States a specific verb and resource ("Altera um treino") and enumerates the mutable fields (data, nome, esporte, texto), plus a scope restriction to workouts created by this MCP, which separates it from apagar_treino/criar_treino by implication. It never explicitly names a sibling or an alternative, so it stops short of full differentiation.

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

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

"Só chame depois que o usuário aprovar a alteração" gives a concrete precondition for invoking the tool, which is exactly the kind of gating rule an agent needs for a write operation. It offers no guidance on when to prefer this over listar_treinos/criar_treino or what to do if evento_id is unknown.

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 a write operation (readOnlyHint=false, openWorldHint=true, destructiveHint=false), and the description reinforces this with the Garmin sync side effect and the user-approval gate, both consistent with openWorldHint. It says nothing about conflicts on an already-populated date, idempotency, or what happens on sync failure. With annotations carrying much of the load, this is adequate but thin.

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 purpose is front-loaded in the first sentence, then parameter notes are laid out one per line with no filler. Every sentence carries information the agent could not get from the schema, and the closing precondition is the right thing to end on.

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 the essentials for a 5-required-param write tool: purpose, external side effect, date bounds, payload syntax, and an approval gate. An output schema exists so return values need no explanation. Remaining gaps are the meaning of 'atleta' and 'nome' and conflict handling on repeat scheduling, so not fully complete.

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

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

Schema coverage is 0%, so the description must carry the burden, and it does for three of five params: date format AAAA-MM-DD with a 120-day forward range, valid sport values (Ride, Run, Swim, WeightTraining), and the Intervals.icu step syntax ('-' at line start). 'atleta' and 'nome' are left entirely unexplained — notably whether 'nome' is the workout title shown in the calendar — which keeps it from a 5.

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

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

States a specific verb and resource ('Publica um treino planejado no calendário do atleta'), which reads clearly opposite to siblings like apagar_treino and atualizar_treino without needing to name them. The added detail that it syncs with Garmin sharpens what 'publish' means here. It stops short of explicitly routing against siblings, so not 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?

Gives an explicit precondition: 'Só chame depois que o usuário aprovar o treino', which is exactly the kind of gate an agent needs before a write. The date window (hoje até 120 dias à frente) further bounds legitimate calls. No explicit 'when not to use' or named alternative, so not a 5.

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 and openWorldHint=true, so the safety profile is covered. The description adds one genuinely useful behavioral fact beyond that: only nicknames of authorized athletes come back, not full profiles. It says nothing about ordering, paging, or behavior when no athletes are authorized, which for a zero-parameter list call would have been easy to add.

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 short sentence with no filler, and the resource plus scope are front-loaded. Every clause carries information.

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

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

An output schema exists, so return-value shape need not be explained, and a zero-parameter read tool has little surface area to cover. The remaining gap is usage routing against the treino siblings, which the description leaves unaddressed.

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 takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly implies no filtering input is required.

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

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

States a specific verb ("Lista") and resource ("apelidos de atletas autorizados neste MCP"), so an agent knows it enumerates athlete identifiers rather than workouts. It also scopes the result set to athletes authorized in this MCP, which separates it from the treino-oriented siblings. It does not explicitly name a sibling alternative, so it falls short of 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?

There is no statement of when to call this versus listar_treinos or atividades_recentes, and no preconditions or exclusions. The phrase "autorizados neste MCP" hints that it is an identity/discovery call, but the agent must infer that usage. That is guidance by implication only.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description still adds real value: a hard 90-day maximum window and an explanation of the 'criado_pelo_mcp' flag that tells the agent which entries are mutable via this MCP.

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 short sentences, zero filler, with the resource and scope front-loaded and the format/limit caveat immediately after. Nothing is repeated from the schema or annotations verbatim.

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?

An output schema exists, so the brief note on 'criado_pelo_mcp' is a bonus rather than a requirement, and the read-only profile is covered by annotations. The only real gap is the unspecified format of the 'atleta' argument.

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 carry the load. It supplies the date format (AAAA-MM-DD) and the 90-day span for 'de'/'ate', but says nothing about what 'atleta' expects (id, name, slug?), leaving one of three required parameters unexplained.

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

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

The description gives a specific verb and resource ("Lista treinos planejados e provas") plus the scope (an athlete's calendar between two dates), which is far more informative than the bare name. It implicitly separates itself from atividades_recentes by covering planned sessions and races rather than past activities, but never names a sibling explicitly.

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 by the scope: query a bounded window of an athlete's calendar. The 90-day cap and date format are constraints rather than guidance on when to pick this tool over atividades_recentes, and no exclusions or prerequisites are stated.

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