guia_del_tutor

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

No annotations are provided, so the description carries the whole burden. It does imply a non-destructive instructional lookup (the 'skill loaded' caching note hints the call is a cheap retrieval of static guidance rather than a mutation), but it never states whether the call changes state, needs auth, or what the returned content looks like. Partial disclosure 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?

Three sentences, front-loaded with what the tool is, then the invocation rule, then the exception. Nothing is wasted, though the mode list is compressed into a clause rather than laid out, which slightly hurts scannability against a 12-value enum.

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 one-optional-parameter lookup with no output schema, the description covers the essentials of when to call it, but it leaves the enum semantics largely implicit and never resolves the overlap with siblings of the same name. That ambiguity is the main thing an agent needs and does not get.

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% and the single parameter is a 12-value enum with no per-value documentation in the schema. The description salvages some of this by assigning meaning to 'inicio' and to the family of modes used 'antes de dar una clase, repasar, simular, practicar plazos', but values like 'discriminacion', 'material', 'preguntas', 'mi_examen' and 'metodologia' remain unexplained and several collide with sibling tool names.

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?

It states the tool returns the tutor's pedagogical method ('qué hacer y cómo enseñar en cada modo'), which is a recognizable resource, but the framing is abstract and it never distinguishes itself from siblings whose names collide with its own enum values (diagnostico, simulacro/registrar_simulacro, plazos/practicar_plazos, exposicion/preparar_exposicion). An agent cannot tell from this text why it would call guia_del_tutor with modo 'diagnostico' instead of the standalone diagnostico tool.

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 concrete trigger conditions: call with modo 'inicio' at the start of a conversation, and with the matching mode before teaching, reviewing, simulating or practising deadlines. It also supplies an explicit negative condition ('con la skill cargada no hace falta'), which is genuine when-not guidance. What it lacks is any routing rule mapping its modes to the similarly named sibling tools.

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