eva_responder_foroPublishes a reply to an EVA Moodle course forum after showing the full message and requiring physical confirmation in Canal B.
Publica una respuesta en un foro de cátedra de EVA Moodle. Muestra el texto completo y requiere confirmación física en Canal B.
| Name | Required | Description | Default |
|---|---|---|---|
| mensaje | Yes | Mensaje exacto a publicar en el foro (máx 350 caracteres) | |
| discusion_id | Yes | ID numérico del hilo o debate de foro |
Changes observed during successful MCP inspections.
v1.0.8Input schema / $schemaRemoved value: -"http://json-schema.org/draft-07/schema#"Input schema / additionalPropertiesRemoved value: -falseInput schema / properties / discusion_id / exclusiveMinimumRemoved value: -0Input schema / properties / discusion_id / maximumAdded value: +9007199254740991Input schema / properties / discusion_id / minimumAdded value: +1Output schema / (root)Previous value: -{
- "$schema": "http://json-schema.org/draft-07/schema#",
- "additionalProperties": false,
- "properties": {
- "aprobado": {
- "type": "boolean"
- },
- "detalles": {
- "additionalProperties": {},
- "type": "object"
- },
- "exito": {
- "type": "boolean"
- },
- "instruccion": {
- "type": "string"
- },
- "mensaje": {
- "type": "string"
- }
- },
- "required": [
- "exito",
- "mensaje"
- ],
- "type": "object"
-}New value: +nullv1.0.6Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly=false, destructive=false, idempotent=false, openWorld=true), the description discloses the human-in-the-loop gate: the full text is shown and physical confirmation in Canal B is required before publishing. It does not say whether the reply is publicly visible to the class or error-recoverable, so not 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?
Two sentences, front-loaded with the action and resource, followed by the behavioral caveat; nothing is padded. 'Muestra el texto completo' is slightly vague about who sees it, which keeps it from a 5.
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 mutation with annotations covering the safety profile and no output schema, the definition covers what the tool does and the confirmation requirement. It omits what the tool returns on success (e.g., post ID or link) and whether the reply is public to the whole course forum.
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 100%, and the schema already documents both parameters including the 350-character limit and the numeric thread ID. The description only adds that the full message text is displayed for confirmation, which is marginal semantic value over 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?
States a specific verb and resource: 'Publica una respuesta en un foro de cátedra de EVA Moodle', which is distinguishable from read-oriented siblings like eva_foros and eva_hilo_foro. It does not explicitly name those siblings as the read alternatives, which keeps it just below 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?
Usage is implied (reply to an existing thread) and the description adds a real precondition — the response must be confirmed physically in Canal B — but there is no explicit when-to-use/when-not or named alternative for reading threads first versus replying.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.