enem-mcp

Corrigir simulado

corrigir_simulado

Grades mock exams by comparing submitted answers with the answer key, reports correct answers and per-discipline scores, and saves results to performance history.

Instructions

Corrige um simulado: mostra acertos, nota por disciplina e o gabarito. O resultado fica salvo no histórico.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "simulado_id": "<simulado_id>",
      "respostas": "<respostas>"
    },
    "name": "corrigir_simulado"
  }
}

Input Schema

Name	Required	Description	Default
`respostas`	Yes	Letras marcadas, na ordem das questões, ex.: ['A','C','E']. Use '' para questão em branco
`simulado_id`	Yes	ID retornado por criar_simulado

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 6, 2026

TDQS

A3.6/5.0

Behavior3/5

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

The annotations declare readOnlyHint=false with destructiveHint=false, and the description usefully explains the side effect that justifies the write flag: 'O resultado fica salvo no histórico.' That is real value beyond the annotations. It does not cover idempotency (does re-correcting create duplicate history entries?) or error behavior for an unknown simulado_id, which matter for a state-mutating tool.

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

Conciseness5/5

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

Two short sentences, zero filler. The primary action and its outputs come first and the persistence side effect follows – exactly the right front-loading order.

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

Completeness4/5

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

With a small two-parameter schema, full coverage, and no output schema, the description carries the return-value burden well by naming acertos, nota por disciplina, and o gabarito in prose. Only the failure/idempotency behavior is unaddressed, which keeps it just short of complete.

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

Parameters3/5

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

Schema description coverage is 100%: respostas documents ordering and the empty-string convention for blank answers, and simulado_id points back to criar_simulado. The description adds no meaning beyond that, so the baseline of 3 applies.

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

Purpose4/5

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

The description states a specific verb and resource ('Corrige um simulado') and enumerates the outputs (acertos, nota por disciplina, gabarito), which clearly separates it from criar_simulado, listar_simulados, and exportar_simulado_pdf. It stops short of naming a sibling or defining scope conditions (e.g., whether it works on any simulado or only one the user created), so it is clear but not maximally differentiated.

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

Usage Guidelines3/5

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

Usage is only implied: the agent can infer this is the step performed after the user answers a simulado, since the schema points to an ID from criar_simulado. There is no explicit when-to-use, when-not-to-use, or statement about what to do if the simulado was already corrected or the ID is invalid.

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

Deploy Server