Skip to main content
Glama

Check before acting

antes_de_actuar
Read-onlyIdempotent

Look up the user's stored rules, procedures and past mistakes that apply to an action the agent is about to take, and return a verdict based on the level the user set for those rules.

Intended for actions that reach someone else (an email, a message, a
post, sharing a document), commit the person (paying, quoting a price,
accepting a meeting, signing), cannot be undone (deleting, cancelling,
filing, submitting), touch something shared or official (a client
record, the accounts, a government portal, the production system),
carry sensitive data, or act in the person's name. Reading, searching
and drafting are outside its scope.

With `consultar=True` NEXUS looks up rules and procedures; with
`consultar=False` it records the agent's assessment that nothing needed
looking up, and still returns any serious past mistake it holds for
that action. Each call is logged as an evaluation for the account.

Returns `evaluacion_id`; `situaciones` (each with its name, the level
the user set, what to watch for and its rules, with the mistake that
created each one); `procedimientos`; `vigencia_segundos` (how long a
verdict that allows the action stays valid, 0 otherwise);
`texto_para_el_agente` (the same, as short text in the account's
language); and a `veredicto`:
- "proceder": no stored rule objects to the action;
- "proceder_con_lista": the action is allowed with the returned list
  applied;
- "preguntar_a_la_persona": the user's rules require their confirmation
  for this action;
- "no_hacerlo": a rule the user set forbids this action, including other
  ways of reaching the same effect; only the user can approve it.
record_procedure_usage records the outcome of a returned procedure.

Args:
    accion: The action about to be taken, described in plain words.
    intencion: Why: what was asked and which part of the work this is.
    objetivo: Who or what it is done to (a client, a case, a patient, a
        channel, a project, a repository).
    riesgo_percibido: The agent's own assessment: whether it can be
        undone, who it reaches, whether there is an agreed way or a rule.
    consultar: True to have NEXUS look up rules and procedures; False to
        only record that the agent judged it unnecessary.
    clave: The key given by a stop point (hook), if one stopped the action.
    herramienta: The tool about to be called, if any.
    detalle: Optional exact text (the email, the command). Stored
        truncated and with secrets masked, never whole.
    session_id: The agent's NEXUS session id, if any.

Input Schema

NameRequiredDescriptionDefault
claveNo
accionYes
detalleNo
objetivoNo
consultarNo
intencionNo
session_idNo
herramientaNo
riesgo_percibidoNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Goes well beyond the annotations: discloses that every call is logged as an evaluation for the account, that detalle is stored truncated with secrets masked ('never whole'), that a verdict has a validity window (vigencia_segundos, 0 when not allowing), and that no_hacerlo extends to 'other ways of reaching the same effect'. The logging/truncation disclosures are exactly the kind of side-effect detail annotations cannot carry.

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 purpose, scope, then return shape, then args — a sensible order, and the verdict enumeration earns its length since there is no output schema. It runs long, and the sentence 'record_procedure_usage records the outcome of a returned procedure' sits orphaned between the return contract and the args without explaining when to call it.

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?

With no output schema and a 9-parameter schema with zero descriptions, the description must cover everything — and it does: return fields are enumerated with meanings, all four verdicts are defined, and the logging/masking behavior is stated. An agent can call this correctly and interpret the result from the description alone.

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 9 parameters, so the description carries the full burden — and does: every parameter is given operative meaning, including why intencion and riesgo_percibido exist, that clave comes from a hook stop point, and that detalle is masked and truncated. This fully compensates for the empty schema.

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?

Specific verb and resource: 'look up the user's stored rules, procedures and past mistakes that apply to an action the agent is about to take, and return a verdict'. The outcome (a veredicto with four named values) makes the tool unmistakably a pre-action gate. It does not, however, name or contrast with the closest siblings (match_procedures, get_procedure, list_rules), so it stops short of full sibling differentiation.

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

Usage Guidelines5/5

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

Explicit inclusion criteria in plain operational terms — reaching someone else, committing the person, irreversible, shared/official, sensitive data, acting in the person's name — plus an explicit exclusion: 'Reading, searching and drafting are outside its scope.' The consultar=True/False split further tells the agent which mode to pick and why.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources