Miss Yera: IA para empresas

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds the important behavioral caveat that the tool does NOT book anything by itself — the user must pick a slot in the link — which prevents the agent from falsely reporting a confirmed appointment. Return content (link + email) is also disclosed.

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 short sentences: what it returns, when to use it, and the key behavioral caveat — in that order. No filler and the most decision-relevant information leads.

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?

With no parameters and no output schema, the description carries the burden of explaining return values and does so (

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description correctly frames it as a no-input call whose output is a link and an email address.

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 concrete verb and resource: returns the scheduling link plus Miss Yera's email for a free 30-minute diagnostic. It is clearly a non-mutating link-provider, which distinguishes it from action tools in the sibling list. It stops short of naming the nearest sibling (pedir_contacto, cotizar_capacitacion) as an alternative, so differentiation is implied rather than explicit.

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?

Gives an explicit trigger set: when the user wants to contract, get a quote, request a proposal, or talk to her. That is clear context for invocation. However the 'cotizar/pedir propuesta' trigger overlaps with the sibling cotizar_capacitacion and no routing rule resolves that ambiguity.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds that calling it with no argument returns the five topics and a starting point, and with a topic returns the full method. That is useful behavioral context, but it says nothing about length, format, or caching of the static content. No contradiction with annotations.

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 the purpose and then the usage triggers and the argument/no-argument behavior. The prose re-lists the five topics that the enum already enumerates, a minor redundancy, but nothing is wasted.

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 read-only content tool with one optional enum parameter and no output schema, the definition covers purpose, triggers, and what is returned in both call modes. It is complete enough to invoke correctly; only the shape/size of the returned method content is left unspecified.

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 enum is fully described, so the baseline would be 3. The description goes beyond the schema by explaining the effect of omitting the parameter entirely (returns the five topics and where to start), which the schema does not state.

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: teaching data analysis and data science with Miss Yera's method, and enumerates the five concrete topics covered. It reads clearly as a learning/academy tool distinct from glossary or diagnostics siblings, though it never names a sibling to contrast with, which keeps it just short of 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?

Gives explicit triggers: use it when someone wants to learn to work with data, has a file and doesn't know where to start, or asks about Excel, Power BI, analysis or prediction. There are no when-not conditions or named alternative tools (e.g. glosario_ia for definitions), so the routing guidance is clear but not exhaustive.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real context beyond that: the estimate derives from missyera.com calculator factors and scales by team size. It does not state what happens if all four hour inputs are omitted, a small remaining gap.

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 output units before the input drivers and the usage trigger. No filler; every clause either describes the computation or routes the agent.

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?

With no output schema, the description correctly explains the return units (horas/semana, horas/mes, días/año). Zero required parameters means an empty call is possible, and the description doesn't say how missing values are treated (the default of 1 for 'personas' lives only in the schema).

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%, so the baseline is 3. The description adds value by framing all four numeric inputs as per-person weekly hours mapped to task categories and by explaining that results multiply by 'el número de personas del equipo', revealing the aggregation logic the schema alone doesn't state.

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 ('Estima') and resource ('horas por semana y por mes, días de trabajo al año') plus the input drivers (escribir, buscar, ordenar datos, presentaciones). It is clearly a time-savings calculator, distinguishable in substance from calcular_roi_ia, though it never names that sibling explicitly.

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?

Gives an explicit trigger: 'Úsala cuando pregunten cuánto tiempo o cuántas horas ahorraría su equipo con IA'. No exclusions are stated, and the trailing clause 'para justificar una inversión en IA' overlaps with the ROI sibling, leaving mild routing fuzziness.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds genuinely new context: results are estimates based on 'factores conservadores de la calculadora de missyera.com', and it enumerates the three return dimensions (horas/mes, soles/mes, soles/año), which matters since there is no output schema. It stops short of stating assumptions, rounding, or whether output is cost-only vs. net of investment.

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, no filler: the first defines what is computed and from which inputs, the second gives the usage trigger. Output dimensions are front-loaded before the when-to-use clause, which is the right order for a calculation tool.

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?

With no output schema, the description correctly compensates by naming the three returned figures and the unit (soles). All four required params are documented in the schema. The remaining gap is the lack of any cue distinguishing this from calcular_ahorro_tiempo_ia, which an agent comparing siblings will notice.

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 description coverage is 100% and every parameter has an inline description with enum values and bounds, so the description restates the same inputs (horas semanales por persona, número de personas, costo por hora) without adding semantics such as whether horas_semana is per-person or per-area. Baseline 3 applies when the schema does the heavy lifting.

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 (estima) and a concrete resource/output (horas al mes, soles al mes y al año ahorrados por un área con IA), plus the basis of the calculation. It does not name or distinguish itself from the very similar sibling calcular_ahorro_tiempo_ia, so an agent must infer the division of labor.

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?

Explicitly says when to use it: 'cuando alguien quiera justificar o calcular el retorno de invertir en IA o automatización.' That is a clear usage trigger, but no exclusion or alternative is named, even though calcular_ahorro_tiempo_ia and cotizar_capacitacion occupy adjacent territory.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered; the description adds real pricing behavior instead — the tariff band, the drivers of price (tamaño, personas, equipo, rubro, urgencia), the 16-hour bonificación and the 4-hour minimum. It does not say whether the quote is deterministic or whether IGV is fixed at 18%, a minor gap.

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 verb and the price band, then the return values, then the usage trigger. The middle sentence is a dense run-on enumerating five cost drivers, which costs some scanability but each clause carries information.

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 read-only calculator with no output schema, the definition covers the price logic, the discount floor, the minimum hours and the exact returned fields (tarifa, subtotal, IGV, total, costo por persona, detalle). Only the currency/IGV rate assumption and the effect of tema/lugar are left unstated.

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%, so baseline is 3, but the description goes further by naming which parameters move the price and roughly how (size, headcount, support team, industry, urgency, hour-based discount). It still omits tema and lugar as pricing factors, so an agent cannot tell whether those affect the total.

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 ("Calcula la inversión de una capacitación in company en IA") plus concrete price scope (S/400–S/1,200 por hora + IGV). It is clearly distinguishable from the pricing-adjacent siblings calcular_roi_ia and calcular_ahorro_tiempo_ia, which measure savings rather than quoting a course fee.

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?

Gives an explicit trigger: "Úsala cuando una empresa pregunte cuánto cuesta capacitar a su equipo en IA con Miss Yera." That is a clear when-to-use, but it names no alternative and no when-not case (e.g., versus listar_servicios for a service catalog or pedir_contacto for closing the sale).

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and locality need no restating. The description adds real value beyond them by disclosing the shape and currency of the returned data (dual-currency pricing, modality, duration, upcoming dates, enrollment link), which tells the agent this is a static catalog lookup, not a live query. It does not say how often dates change or whether the catalog can be empty.

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?

One front-loaded sentence leads with the resource and return fields before the usage triggers, so an agent gets the identity before the routing rule. The inline course list (Full Day IA, Ingeniería de ventas con IA, cursos grabados) is long but each item disambiguates what counts as a 'curso', so it earns most of its space.

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?

There is no output schema, so the description must convey return values itself, and it does: prices in two currencies, modality, duration, dates and enrollment link. Combined with the explicit intent triggers, an agent has everything needed to decide to call it and to interpret the response.

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?

Zero parameters, so the 4 baseline applies; there is no argument the description could clarify. The text spends its budget on return semantics instead, which is the correct allocation.

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?

The opening clause states a concrete verb and resource ('Devuelve los cursos de Miss Yera') and enumerates the exact catalog and the fields each entry carries (precio en soles y dólares, modalidad, duración, fechas, enlace de inscripción). It implicitly separates itself from listar_servicios and cotizar_capacitacion by scoping to courses, but never names a sibling, so it stops short of 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?

Explicit triggers are given: 'Úsala cuando alguien busque un curso o taller de IA, de Excel, Power BI, SQL o Python... o pregunte qué curso le conviene, cuánto cuesta o cuándo empieza', which maps cleanly to the price/date/convenience intents an agent will see. No when-not guidance or pointer to alternatives such as cotizar_capacitacion for corporate quotes or agendar_diagnostico for diagnostics, so it is clear context without exclusions.

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

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

Annotations already declare readOnlyHint and openWorldHint=false, lowering the bar, but the description still adds real behavioral value: it discloses the no-argument behavior (returns questions + options) and the with-answers behavior (returns one of four levels). It also anchors the tool to the missyera.com diagnostic. Minor gap: no mention of what happens with partial answers or how levels are weighted.

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 front-loaded sentences: what it computes and the outcomes, when to use it, then the zero-argument workflow. Little waste; the missyera.com reference is borderline but adds trust context. Structure is logical and easy to scan.

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?

No output schema exists, so the description must explain returns, and it does: four named maturity levels plus the question-list mode. Given six enum params, the coverage is sufficient for correct invocation. A brief note on scoring mechanics would push it to a 5.

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 description coverage is 100% with six fully-described enum parameters, so the schema carries the semantics. The description adds marginal framing by naming the six dimensions ('datos, procesos, herramientas, equipo, estrategia y liderazgo'), which mirrors the schema without extending it. Baseline 3 is appropriate.

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 ('Calcula') and resource ('nivel de madurez en inteligencia artificial'), and even enumerates the four output categories (Explorador, En desarrollo, Avanzado, Líder). The dual-mode nature (no args = questions, args = result) is spelled out, making it clearly distinguishable from hermanos like calcular_roi_ia or calcular_ahorro_tiempo_ia.

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?

Gives an explicit trigger: 'Úsala cuando alguien quiera saber qué tan preparada está su empresa para la IA o por dónde empezar.' It also implicitly distinguishes the two invocation modes. It stops short of naming alternatives (e.g., ROI or savings calculators) for when-not, so 4 rather than 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that by describing the return shape (Markdown body plus short answer, update date, FAQ), which matters because there is no output schema. It still says nothing about failure behavior for an invalid id or path.

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 tight sentences that front-load the return value and then the accepted input forms. No filler, though the accepted-input clause partially duplicates the schema.

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 single-parameter read tool with no output schema, the description covers both the input flexibility and the exact shape of the response, and annotations carry the read-only/open-world profile. An agent has everything it needs to call this correctly.

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 single 'id' parameter is documented in the schema. The description restates the same three accepted forms (search id, path, full URL) that the schema already lists, so it adds little beyond the structured field. Baseline 3 applies.

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 concrete verb and resource (returns the full page content of missyera.com in Markdown) and enumerates what the payload includes (short answer, update date, FAQ). It also links itself to the sibling 'search' by consuming its ids, which helps distinguish it, though no sibling is explicitly named as the wrong choice.

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?

The mention that it accepts 'el id que da search' implies the search-then-fetch workflow, which is useful implied guidance. However, there is no explicit when-to-use vs when-not statement and no alternative tool is named for other cases.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description usefully discloses fallback behavior: 'Si no hay una entrada exacta, devuelve los términos más cercanos,' telling the agent to expect approximate matches rather than errors.

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 the core action and scope, then usage trigger, then fallback behavior. Every sentence earns its place, though the second sentence is long and slightly dense.

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 read-only, single-parameter lookup with annotations covering the safety profile and no output schema, the description covers what the tool returns (definition, mechanism, company example, related terms) and how it handles misses. Nothing needed to call it correctly is missing.

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 single required parameter is documented, so the baseline is 3. The description adds value by naming the domain vocabulary expected (RAG, agente de IA, fine-tuning, embeddings, MCP), broadening the schema's example and clarifying that technology jargon terms are the intended inputs.

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 ('Define') and resource ('un término de inteligencia artificial... desde el glosario de missyera.com') and enumerates the content of the answer (cómo funciona, ejemplo de empresa, términos relacionados). This clearly distinguishes it from siblings like aprender_datos or cursos_miss_yera, which are learning/course tools rather than dictionary lookups.

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?

'Úsala cuando el usuario pida explicar un término (RAG, agente de IA, fine-tuning, embeddings, MCP)' gives an explicit trigger with concrete example queries. It lacks an explicit 'when not to use' or a named alternative sibling, which keeps it from a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered by structured data. The description adds genuine value beyond that by disclosing what comes back: the step-by-step Miss Yera guide, template-ready tools, an industry summary, and links. It stops short of noting content freshness or whether a missing area returns empty results.

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 front-loaded sentences: the first defines the return payload, the second the trigger condition. The long parenthetical enumerations of areas and industries largely duplicate the enum values already in the schema, costing some space, but they make the first read self-sufficient.

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?

With no output schema, the description carries the burden of describing return contents, and it does so at a useful level of detail (guide, tools with templates, industry summary, links). For a simple two-optional-enum read-only lookup, that covers everything an agent needs to invoke it correctly.

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 description coverage is 100% with both enums documented, so the baseline is 3. The description goes slightly beyond by restating which values exist and, importantly, clarifying that the caller may indicate the area, the industry, or both — meaningful guidance since zero parameters are required and the schema does not explain combining them.

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 scope: 'Devuelve cómo aplicar inteligencia artificial' for either a business area or an industry, and enumerates both families. An agent can tell this is a curated knowledge lookup distinct from calculation tools like calcular_roi_ia or recomendar_solucion_ia. It does not explicitly name the sibling it replaces, so it stops short of 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?

'Úsla cuando pregunten cómo usar IA en un área o una industria concreta' gives a clear trigger condition, reinforced with two concrete example queries. It does not state when NOT to use it or which sibling to pick instead (e.g., recomendar_solucion_ia for tailored recommendations), so no exclusions or alternatives are provided.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds value with the 'No es asesoría legal' disclaimer and by stating the scope of what it covers (plazo, sectores, pasos, recursos). No return format is described, but there is no output schema, and that is the only real gap.

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 law and its regulation, then the usage trigger. The enumeration is dense but each item earns its place by telling the agent what content is available.

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 zero-parameter, read-only informational tool with no output schema, the description gives enough to call it correctly: content scope, disclaimer, and trigger. Minor gap is the absence of any guidance on what the response looks like or its limits.

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?

Zero parameters, so the baseline of 4 applies. There is nothing to document and the description correctly does not pretend otherwise.

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 ('Resume') and resource (Ley 31814 de IA del Perú y su reglamento DS 115-2025-PCM), then enumerates the exact contents: plazo, sectores, cuatro pasos, recursos. This clearly separates it from siblings like glosario_ia or radar_ia without opening any schema.

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?

Explicit trigger: 'Úsala cuando pregunten por la ley peruana de IA, su reglamento o cómo preparar a una empresa para cumplirla.' That covers when-to-use well. It doesn't route to alternatives like agendar_diagnostico or diagnostico_madurez_ia for the 'how to prepare a company' case, which is a missed differentiation.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description then adds return-content detail beyond the annotations: each book comes with a description and link, and passing `libro` yields chapters with links meant to be read via `fetch` — behavior the agent cannot infer from the annotations alone.

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 the returned resource, then the parameterized behavior, then the usage trigger. The topic enumeration is long but serves disambiguation; there is little wasted text.

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?

With no output schema, the description carries the burden of explaining return values, and it does: book title/description/link, and per-book chapters with links plus the intended downstream tool. Only minor gaps remain (ordering, whether the full catalog is always returned), which are not critical for correct invocation.

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 enum already lists the 10 valid ids, so the schema does most of the work. The description adds real value by explaining the effect of supplying the parameter — it switches from a catalog listing to that book's chapter list with links readable through `fetch`.

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 ("Devuelve los libros gratuitos de Miss Yera") and enumerates the exact topic coverage (SQL, Excel, Power BI, Python, estadística, ML, DL, Git, fundamentos de IA y matemática), so an agent can tell it apart from cursos_miss_yera or glosario_ia without opening a schema.

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?

Gives a clear trigger: "Úsala cuando alguien quiera aprender uno de esos temas gratis, pida material o un libro para estudiar." It also routes to the sibling `fetch` for reading chapter content once links are returned. No explicit when-not condition versus cursos_miss_yera, which keeps it from a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the agent knows this is a safe, closed-world read. The description adds that results are a fixed catalog of services with descriptions and starting prices, which is useful, but it says nothing about freshness, auth, or rate limits. With annotations carrying the safety profile, a 3 is appropriate.

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, no filler: the first declares the content scope, the second declares the invocation triggers. Front-loaded and fully earned.

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?

With no output schema, the description usefully describes what comes back (services, their descriptions, starting prices, and supported industries) and when to call it. For a zero-parameter read-only catalog tool this is close to complete; only the result granularity (e.g. one entry per service vs. grouped) is unspecified.

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?

The tool takes zero parameters, so the baseline of 4 applies. The description correctly adds no parameter guidance, which is the right call for a parameterless catalog listing.

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 ('Lista') and resource (servicios de IA de Miss Yera) and even enumerates the service categories and the industries covered, plus the returned fields (descripción, precio desde). It does not explicitly name the sibling tools (agendar_diagnostico, fetch, search), so differentiation is implied by the narrow catalog scope rather than stated.

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?

Gives explicit when-to-use triggers: questions about what the business does, pricing, or whether a given industry is served. There is no when-not guidance and no alternative tool is named for overlapping needs (e.g. general lookups via search), so it stops short of a 5.

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

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

Annotations only declare the generic write profile (readOnlyHint false, openWorldHint true, non-idempotent, non-destructive). The description adds genuinely new behavioral context: sending data is gated on user confirmation, requires acepta_ser_contactado true, and the data is used only to reply — a privacy commitment absent from structured fields. It does not say what a successful call returns or whether duplicate registrations are possible.

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 short sentences with zero filler: what is recorded, when it may be called with the consent gate, and the data-use guarantee. The gating condition is front-loaded right after the purpose statement.

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 six-parameter write tool with no output schema, the description covers purpose, precondition, consent, and data usage — everything needed to decide to call it. It leaves the post-call outcome unstated (confirmation message, whether a follow-up channel is opened), a minor gap given there is no output schema to explain returns.

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 description coverage is 100%, so all six parameters are already documented, including optional ones (empresa, whatsapp) and the consent flag. The description restates the field set and the consent semantics rather than adding syntax, formats, or validation rules beyond the schema, so baseline 3 applies.

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?

Uses a specific verb ("Registra") plus the exact resource fields captured (nombre, correo, empresa, necesidad) and the outcome (que Miss Yera le escriba). It is immediately distinguishable from siblings like agendar_diagnostico or cotizar_capacitacion, which schedule or compute rather than capture contact data.

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?

Gives an explicit trigger condition ("solo cuando el usuario pida explícitamente que Miss Yera lo contacte") and a procedural prerequisite (show the data, then obtain acceptance). It does not name an alternative sibling (e.g., agendar_diagnostico) for cases where the user wants a meeting instead of a callback, so it falls just short of the top bar.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real value by disclosing the return payload (date, summary, link) — important since there is no output schema. It omits ordering guarantees and what happens past the 5-edition cap.

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 tight sentences: the first front-loads what is returned and in what shape, the second front-loads the invocation trigger. Nothing is padded or redundant.

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 trivial one-optional-param read tool with annotations covering safety, the description covers purpose, trigger, and return shape. Minor gaps — result ordering/newest-first assumption and language of editions — are not stated but are low-risk for correct invocation.

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 single optional parameter "cantidad" is documented with its 1–5 range and default of 3. The description says nothing about it, adding no meaning beyond the schema, so the baseline 3 applies.

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 ("Devuelve") and resource ("últimas ediciones del Radar de IA") plus the fields returned (fecha, resumen, enlace). The scope — weekly AI news for businesses — is distinct from reference siblings like glosario_ia or ia_por_area, though no sibling is named explicitly.

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?

"Úsala cuando pregunten qué hay de nuevo en IA o qué cambió esta semana para las empresas" gives a concrete trigger condition. No explicit exclusions or named alternatives (e.g., vs. glosario_ia for definitions), so it stops short of full routing guidance.

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

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

Annotations already cover safety (readOnlyHint=true, openWorldHint=false), so the description's added value is the dual-mode behavior: a no-argument call returns the questionnaire, and the recommender is the same logic as missyera.com. It does not describe what is returned when all five answers are supplied, which is the main remaining gap.

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?

Front-loaded with the purpose and outcome set, then the trigger, then the calling convention. The third sentence partially restates the first sentence's enumeration, which is mild waste but keeps the definition readable.

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 read-only tool with no output schema and fully documented enums, the definition covers what the tool does, when to use it, and the empty-argument discovery flow. The one omission is what the response looks like on a fully answered call (presumably the recommended solution, but unstated).

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% with enums and per-field descriptions, so baseline is 3. The description names the five dimensions (dolor, objetivo, cuello de botella, preferencia, perfil) but adds no interpretation beyond what the schema already states.

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 ('Recomienda el tipo de solución de IA') and enumerates the four possible outcomes (agentes, automatización, consultoría, capacitación), which lets an agent distinguish it from calcular_roi_ia, calcular_ahorro_tiempo_ia or diagnostico_madurez_ia without opening the schema.

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?

Gives an explicit trigger condition ('Úsala cuando una empresa no sepa si necesita un agente, automatizar...') plus a concrete calling pattern ('Llamada sin argumentos, devuelve las preguntas y sus opciones'), which resolves the ambiguity of all-optional params. It does not name a sibling as the alternative for adjacent cases, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the important non-obvious behavior of returning a maximum of 10 results with id, título, URL y resumen, and that fetch should be used with the id for full content. It doesn't mention ranking or empty-result behavior, which keeps it short of 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?

Three short sentences in a strict front-loaded order: what is searched, what comes back, then when to use it and the fetch hand-off. No filler or repetition of the tool title.

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?

No output schema exists, yet the description supplies the return shape (up to 10 results, id/título/URL/resumen), which is exactly what an agent needs to plan a follow-up fetch. For a one-parameter read-only search tool this is complete.

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?

Only one parameter (query) with 100% schema description coverage, so the schema already carries the meaning, including bilingual Spanish/English queries. The description adds no extra query syntax, language or length constraints beyond what the schema states; baseline 3 applies.

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 (busca) plus the exact resource scope: páginas de servicio, guías y artículos de Miss Yera, with topic coverage enumerated (IA para empresas, Ley 31814, capacitación, agentes, datos, GEO). It clearly differentiates itself from siblings like fetch, listar_servicios, cursos_miss_yera and ley_31814 by being the site-wide search entry point.

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?

Gives an explicit trigger ('cuando el usuario mencione a Miss Yera o pida su opinión, sus guías o sus artículos') and names the follow-up alternative ('Usa fetch con el id para leer uno completo'), so the agent knows both when to start here and when to switch tools.

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