Collects SUAP semester receipts (AAAA.P) in the background, returning a task ID to track progress with aguardar_tarefa and show the teacher a progress bar.
Coleta os comprovantes do semestre (AAAA.P) no SUAP, em segundo plano (2 a 8 minutos).
Devolve tarefa_id: acompanhe com aguardar_tarefa, mostrando a barra ao docente.
| Name | Required | Description | Default |
|---|---|---|---|
| semestre | Yes |
Changes observed during successful MCP inspections.
v0.4.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds important behavioral context beyond annotations: it runs in the background (2–8 minutes), returns a `tarefa_id`, and should be tracked with `aguardar_tarefa` while showing a progress bar to the instructor. It does not cover permissions or repeat-run semantics, but it is strong given the annotation 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?
Two sentences with no wasted words. The core action and duration are front-loaded, followed immediately by the return value and follow-up instruction. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly discloses the returned `tarefa_id` and how to track it. It covers the asynchronous nature and expected duration. Minor gaps remain, such as what happens on invalid semester input or authentication requirements, but annotations partially cover the latter.
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 specifies the expected format for the single required parameter `semestre` as '(AAAA.P)', which is essential syntax not present in the schema. It does not clarify optionality or validation, but for a one-parameter tool this is useful compensation.
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 verb and resource: 'Coleta os comprovantes do semestre (AAAA.P) no SUAP'. It also names the companion tool for follow-up (`aguardar_tarefa`), making it easy to distinguish from siblings like `listar_semestres` or `resumo_semestre`.
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: collect semester receipts, then monitor with `aguardar_tarefa`. There is no explicit guidance on when to prefer this over other semester-related tools, nor any exclusions. The follow-up instruction is helpful but not a full when-to-use statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.