NEXUS AGI

Answer a pending question

answer_question

Idempotent

Apply an answer to a question returned by get_next_question.

Answers change the world model: resolving a contradiction may close a
relation, accepting or rejecting a learned type updates the ontology,
and "fusionar" merges two entities (reversible).

Args:
    tipo: The question's ``tipo``: "contradiccion", "ontologia" or
        "fusion".
    question_id: The question's ``id``.
    respuesta: One of the question's ``respuestas``, or "posponer" to
        hide it for 3 days.
        contradiccion: "vigente" (pass relation_id of the one still
            true; the other is closed), "coexisten", "descartar",
            "investigar" (hidden 7 days).
        ontologia: "aceptar" (optionally with parent), "rechazar".
        fusion: "fusionar" (optionally with conservar), "distintas".
    relation_id: For contradiccion + "vigente": the relation that remains
        true.
    parent: For ontologia + "aceptar": corrected parent type.
    conservar: For fusion + "fusionar": which entity survives, "a" or
        "b". Default: the one with more relations.
    por_usuario: True (default) if this relays the user's answer; False
        if the agent decided on its own.

Input Schema

Name	Required	Description	Default
`tipo`	Yes
`parent`	No
`conservar`	No
`respuesta`	Yes
`por_usuario`	No
`question_id`	Yes
`relation_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 8, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only cover safety (readOnlyHint=false, idempotentHint=true, destructiveHint=false); the description adds the real consequence model: 'vigente' closes the other relation, ontology answers update the ontology, and fusion is explicitly reversible. It also discloses timing side effects ('posponer' hides for 3 days, 'investigar' for 7), which is exactly the kind of behavior annotations can't express.

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

Conciseness4/5

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

Front-loaded with the core action, then a structured Args block with no filler sentences. It is long, but the length is justified by 0% schema coverage; a small amount of nesting in the respuesta line makes it slightly denser than ideal.

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

Completeness5/5

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

For a 7-parameter mutation tool with no output schema and no per-parameter schema docs, the description supplies every decision an agent needs: which answers are valid, which extra args each requires, and what each answer does. Nothing material is left unspecified.

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

Parameters5/5

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

Schema description coverage is 0% across 7 parameters, so the description carries the full burden and does so well: each of tipo, question_id, respuesta, relation_id, parent, conservar, and por_usuario is explained, including which respuesta values pair with which tipo and the default for conservar and por_usuario.

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

Purpose5/5

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

States a specific verb and resource ('Apply an answer to a question returned by get_next_question') and ties the input to a named sibling that produces it. It also enumerates the three question families (contradiccion/ontologia/fusion), so an agent can distinguish it from get_next_question (fetch) and the lower-level relation tools.

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

Usage Guidelines4/5

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

The entry condition is explicit: only use it for questions produced by get_next_question, with per-tipo choices spelled out. It falls short on sibling differentiation -- it never says when to use this versus resolve_contradiction, decide_merge_proposal, or ratify_relation, which all touch the same contradiction/merge space.

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

All NEXUS AGI tools Inspect

Try in Browser

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?