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

With no annotations provided, the description carries the disclosure burden and does so well: it reveals side effects (saves file to disk, returns path), and it describes defensive behavior (detects and rejects error/session-expired pages disguised as files via redirect or Content-Type text/html). Missing details are limited to session/auth prerequisites and exact path/error return format, which are useful but not critical given the level of context shown.

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 dense sentence that earns its length: it covers request construction, response expectation, error rejection, disk persistence, return value, and relation to existing download flows. It is not fluffy, though the long dash-separated structure could be slightly easier to scan if split into separate sentences.

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

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

Given there is no output schema, the description appropriately states the return value ('devolve o caminho'). It also covers the main invocation-relevant behaviors: request construction, binary response expectation, and rejection of spoofed HTML errors. Some context is left implicit, such as requiring a prior login/session and the exact shape of the returned path, but the description is complete enough for an agent to select and invoke the tool safely.

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 covers 100% of the parameters with descriptions, so the baseline is 3. The description adds only a general mapping to method, url, and form fields; details like 'application/x-www-form-urlencoded' and 'javax.faces.ViewState' are already present in the schema, so the description does not add meaningful parameter semantics beyond it.

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: it builds and triggers a request to sigs.ufrpe.br expecting a binary file, saves it to disk, and returns the path. It also differentiates itself from the sibling-specific download tools (sigaa_get_historico_pdf, sigaa_get_vinculo_pdf) by explicitly framing itself as the generalized download flow for any SIGAA download action.

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

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

The description gives clear context: use it when a SIGAA action is expected to return a binary file (PDF, schedule attachment) instead of HTML, and it generalizes hardcoded download flows for arbitrary actions. It does not explicitly name sibling tools or state when-not-to-use, so it stops short of full routing 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It names the output content and implies a read-only lookup through the word 'detalhes', but it does not explicitly state that the operation causes no changes, mention authentication requirements, or describe failure behavior.

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

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

The description is compact and front-loaded: the first clause defines what the tool returns, and the second sentence maps both parameters to their source. Every sentence earns its place without verbose explanations.

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 two-parameter, schema-rich lookup tool, the description is largely complete: it states the returned data categories and the exact provenance of both inputs. It omits minor operational details such as error behavior or login prerequisites, but those are likely common to all sigaa_* 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?

The input schema already provides 100% parameter coverage, so the baseline is 3. The description adds real value by linking each parameter to a specific upstream field from sigaa_get_curriculo, which is extra navigation semantics that the schema alone does not fully convey.

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 resource ('componente curricular específico') and enumerates the returned data categories: ementa, tipo, modalidade, carga horária, pré-requisitos e equivalências. It lacks an explicit verb like 'consulta' or 'retorna', but the intended purpose is unmistakable.

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 concrete usage guidance by stating that both parameters come from sigaa_get_curriculo, mapping idComponente to componentes[].id and curriculo to estruturaCurricular.codigo. It does not list exclusions or alternatives, but it clearly explains the expected workflow.

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

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

With no annotations, the description carries the behavioral-transparency burden. It exposes the output organization (by semester), component categories, and the fields needed for the next call. It does not mention prerequisites such as being logged in, nor any side effects or failure behavior, but 'Lista' reasonably implies a read operation.

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 efficient sentences: the first states the purpose, and the second gives the actionable next step. There is no filler, and the key differentiating information is 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?

Given zero parameters, no output schema, and no annotations, this is a simple read-style tool and the description is nearly complete. It names the important returned fields, but it leaves minor context implicit, such as authentication dependency and the full return format.

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

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

The tool has zero parameters and the input schema documents this completely, so there are no parameter semantics for the description to add. The baseline for zero-parameter tools is 4; the mention of response fields like 'componentes[].id' relates to output chaining, not to input 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 opens with a specific verb ('Lista') and a specific resource ('componentes curriculares do curso do aluno'), and adds meaningful qualifiers: the component types and the semester organization. This clearly separates it from sibling tools such as sigaa_get_notas or sigaa_get_turma.

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 communicates the intended flow: fetch the curriculum structure first, then use returned fields to call sigaa_get_componente. It does not explicitly state when not to use this tool or name an alternative, but the chaining instruction is a clear, actionable 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?

There are no annotations, so the description carries the transparency burden. It discloses the main non-obvious behaviors: the tool writes a PDF to disk and depends on a valid ViewState. It does not describe the return value or failure behavior with an invalid/expired ViewState, but the core effects are clear.

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 no filler: the first states the action and output format, and the second states the prerequisite and required follow-up call. Both sentences earn their place.

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

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

For a simple zero-parameter tool, the description covers the action, the side effect, and the only prerequisite an agent must satisfy before calling. It is slightly incomplete because it does not state what is returned after saving to disk or explicitly differentiate from sigaa_get_vinculo_pdf.

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 zero properties, so there are no parameter details for the description to add. The zero-parameter baseline is 4, and the ViewState note is procedural prerequisite context rather than parameter 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 uses a specific verb ('Baixa') and a specific resource ('histórico escolar do aluno em PDF'), and adds the disk-saving side effect, so an agent knows what the tool does. It implicitly differentiates from siblings like sigaa_get_vinculo_pdf by naming 'histórico escolar,' but it does not explicitly contrast the two PDF tools.

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

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

The description provides a clear prerequisite and actionable guidance: a valid ViewState is required, and the agent should call 'sigaa_main_data' first if it does not have one. It does not mention explicit alternatives or when-not-to-use scenarios, so it stops short of 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?

With no annotations provided, the description carries the behavioral burden and does so well: it discloses raw no-parsing output, that error/expired-session pages are returned for inspection, and session/auth dependency. It does not mention response status codes or redirects, but the key behaviors are covered.

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

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

Two sentences, front-loaded with the core action and output, and every clause earns its place: URL scope, session behavior, raw output, error handling, and the login prerequisite.

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 fetch tool with no output schema and one required parameter, the description is reasonably complete: it covers what is returned, the auth prerequisite, and that errors are not masked. The main gap is not positioning it relative to sigaa_raw_request, a sibling that may overlap.

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 already documents url, method, and referer with 100% coverage, so the baseline is 3. The description adds meaning by restricting the URL to the sigs.ufrpe.br domain, which is not in the schema. It does not detail method/referer, but those are fully described in the schema.

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

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

The description states a specific action ('Busca uma URL sob sigs.ufrpe.br') and a precise output ('HTML bruto da resposta, sem nenhum parsing'), including error/session-expired pages. It clearly separates this from parsed-data siblings, though it does not explicitly distinguish it from the similarly low-level sibling sigaa_raw_request.

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 an explicit prerequisite ('Use sigaa_login antes se a página exigir autenticação') and a purpose ('para inspeção'). It does not explicitly say when to prefer sigaa_raw_request or parsed siblings, so some alternative-selection guidance is missing.

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?

No annotations are provided, so the description carries the full burden. It discloses an important behavioral dependency (valid ViewState) and how to satisfy it. However, it does not explicitly state that the operation is read-only, nor does it mention failure behavior, so a 5 is not warranted.

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 no filler: the first front-loads what the tool returns, and the second provides the only necessary usage condition. Every word earns its place.

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

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

For a no-parameter tool with no annotations and no output schema, the description covers the key output content and the required prerequisite clearly. It does not describe the exact response structure or edge cases, but for invocation purposes it is sufficiently 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 input schema has zero parameters, so the rubric baseline is 4. The description correctly avoids inventing parameter details and instead focuses on prerequisite context.

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 resource (atestado de matrícula) and the data it returns: período letivo, vínculo, curso, and turmas matriculadas. The title adds 'estruturado', which distinguishes it from HTML/PDF siblings, but the first sentence lacks an active main verb and relies on the participle 'extraídos', so it is not a full 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?

The description explicitly states a required precondition: a valid ViewState. It also tells the agent exactly what to do if that precondition is not met: call 'sigaa_main_data' before. This is clear when-not and sequencing 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?

With no annotations provided, the description carries the responsibility for disclosing behavior. It reveals a stateful dependency (valid ViewState) and provides the remediation step. This is a meaningful behavioral disclosure, though it does not mention output format or error behavior if the ViewState is invalid.

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

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

The description is two sentences with no filler. The purpose is front-loaded, and the prerequisite is stated as a direct instruction. Every word earns its place.

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

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

For a parameterless tool, the description covers what data is returned and the only prerequisite needed to invoke it. It does not describe the return format or pagination, but no output schema exists, and the simplicity of the tool makes this a minor 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 tool has zero parameters, so the baseline for this dimension is 4. There is no parameter information to add, and the description correctly focuses on the prerequisite rather than parameter details.

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

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

The description states exactly what the tool returns: grades from the current and previous semesters. It is clear and specific to the 'sigaa_get_notas' resource, but it does not explicitly name or distinguish itself from sibling tools like 'sigaa_get_historico_pdf' or 'sigaa_get_componente'.

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

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

The description gives clear usage context by explaining the ViewState prerequisite and telling the agent to call 'sigaa_main_data' first if needed. It does not discuss when to choose this tool over alternatives, but the sequencing guidance is actionable and directly supports correct invocation.

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

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

With no annotations, the description carries the behavioral burden. It reveals that 'nome'/'info' are used for internal navigation and that the response is validated to never return another turma's data. However, it does not mention auth requirements, error behavior, or whether the operation is strictly read-only.

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

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

Two sentences front-load the core function and then give the key constraint and guarantee. There is no filler or repetition.

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

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

The description covers the source of the input, the enrichment content, the required handling of fields, and a validation guarantee. The main gap is the absence of response structure details, but for a single-parameter enrichment tool this is largely 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 coverage is 0%, but the description compensates by telling the caller to send the 'turma' object back unchanged and by explaining the role of 'nome'/'info' in navigation. This is meaningful semantic guidance 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 uses a specific verb ('Enriquece') and names the exact resource (a turma from sigaa_main_data) plus the added data types (cronograma, notícia, total de faltas). This distinguishes it from sibling tools like sigaa_main_data (listing) or sigaa_get_notas (grades).

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 anchors usage to a prior step: the 'turma' must come from sigaa_main_data, and the user is told to send it back unaltered. This gives clear context for when to call the tool, though it does not explicitly name alternatives or when-not conditions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals the core behavior (downloading a PDF and saving it to disk) and the key precondition (valid ViewState). It does not describe error behavior or file output details, but for a zero-parameter download tool this is reasonably transparent.

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 filler. The main purpose and side effect are front-loaded, and the prerequisite is stated clearly in the second sentence. Every sentence earns its place.

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

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

For a simple zero-parameter tool without an output schema or annotations, the description covers the essential action and the most likely failure point (missing ViewState). It omits return value and file path details, but these are minor given the tool's simplicity.

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, so the baseline is 4. The description adds useful context by mentioning ViewState as a required runtime state, even though it is not an input parameter.

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

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

The description clearly states the action ('Baixa' - downloads), the specific resource ('declaração de vínculo do aluno em PDF'), and the side effect ('salva em disco'). This is specific enough to distinguish it from siblings like sigaa_get_historico_pdf, which deals with a different document.

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 usage context by stating that a valid ViewState is required and explicitly instructs calling 'sigaa_main_data' first if one is not already available. It does not discuss alternatives or exclusions, but the prerequisite guidance is concrete and actionable.

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

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

With no annotations, the description carries the full burden and does well: it discloses that the login handles an interstitial 'Aviso de Logon', that the session is stored in memory on the MCP server, and that it is reused automatically. It does not cover failure behavior or session expiration, but the disclosed stateful behavior goes beyond a simple 'logs in' statement.

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 well-constructed sentence that immediately states the action, provides the resource context, mentions the interstitial handling, and explains the key session-reuse detail. Every part earns its place with no 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 simple two-parameter authentication tool, the description is largely complete: it identifies required inputs, explains the session flow, and distinguishes the tool's role among siblings. The main omission is what the tool returns on success or failure, especially since no output schema is provided, but this is a minor gap given the tool's primary role.

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 100%, so the schema already documents both parameters. The description adds nothing beyond what the property descriptions say, which is acceptable under the baseline of 3 for high schema coverage.

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

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

The description clearly states a specific verb ('Autentica'), the target resource ('SIGAA UFRPE'), and the required credentials (usuário e senha), making the tool's purpose unmistakable. It also explains the session handling, which distinguishes it from the sibling tools that operate on authenticated data.

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 conveys that authentication is performed once and the resulting session is automatically reused by other tools, implying that users do not need to call other tools with tokens. It does not explicitly state that this should be called before using the other sigaa tools or what to do on failed authentication, but the usage context is clear enough for an agent.

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

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

With no annotations and no output schema, the description carries the behavioral burden and does well: it discloses the login prerequisite, the summarized nature of the data, and what is omitted. It stops short of stating read-only behavior or error conditions when not logged in, but those are reasonably inferable from 'depois do login'.

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 definition is a single dense sentence that front-loads the most important context ('Ponto de entrada depois do login') and organizes the rest with parentheses and a dash. Every phrase adds information and there is no redundancy or 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?

For a no-argument data-retrieval tool, this is largely complete: it names the main data categories and points to the relevant sibling for deeper detail. However, since there is no output schema, the description only gives high-level categories and not the exact response structure, which is a modest gap for an agent that must interpret the return value.

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, so the baseline is 4; there are no parameter semantics to document. The description adds nothing about parameters because nothing is needed.

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

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

The description clearly identifies the tool as the post-login entry point and enumerates the data it provides: nome, matrícula, turmas resumidas, índices acadêmicos e carga horária pendente. It also distinguishes itself from sigaa_get_turma by explicitly stating that turmas are summarized and that the sibling tool should be used for details.

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

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

It states when to use the tool ('depois do login') and gives an explicit alternative: use sigaa_get_turma when detailed class information is needed. The exclusion of cronograma/notícia/faltas further tells an agent which scenarios this tool is NOT appropriate for.

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

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

With no annotations provided, the description carries the full burden and discloses substantial behavior: automatic JSESSIONID cookie attachment from the current session, raw HTML return, and extraction of the new javax.faces.ViewState with an instruction to feed it into the next request's formFields. It does not cover error behavior (non-2xx responses, redirects, expired sessions) or warn that arbitrary POSTs can mutate server-side state, which keeps it one step from a 5.

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

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

Three sentences with zero waste: capability first, then the concrete use case, then return value and state protocol. Every sentence earns its place and the most decision-relevant information (scope, session cookie, dedicated-tool exclusion) is 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?

For a complex 5-parameter arbitrary-request tool with no output schema and no annotations, the description covers scope (restricted to sigs.ufrpe.br), session handling, return value (raw HTML + ViewState), and the ViewState refresh workflow — essentially compensating for the missing output schema. The gaps are error handling and a mutation-safety note for POST, both worth mentioning for a raw-request 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?

Schema description coverage is 100% — url, method enum, referer, formFields, and contentType each already have meaningful descriptions. The schema even documents the ViewState requirement in formFields. The description adds only the state-refresh workflow ('atualize seu próximo formFields com esse valor'), which is marginal value over the schema, so the baseline 3 applies.

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: 'Monta e envia uma requisição HTTP arbitrária (method + url + campos de formulário) contra qualquer URL sob sigs.ufrpe.br'. It also distinguishes itself from the sibling getter tools by positioning as the escape hatch 'quando não existe uma tool dedicada para essa ação', so an agent can tell it apart from sigaa_get_notas or sigaa_download_file without inspecting schemas.

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 trigger condition: use to 'reproduzir uma ação JSF descoberta ao inspecionar o HTML' (e.g., a 'jscook_action' or 'jsfcljs' found in an onclick attribute). It also provides the when-not: 'quando não existe uma tool dedicada', implying the specialized siblings should be preferred — explicit routing that leaves nothing to inference.

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