el-buen-agente-mcp

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

With no annotations, the description carries the full burden. It explains the tool's behavior: it applies the challenger pattern, receives an agent definition, and returns a structured evaluation brief. It does not explicitly state that it is a read-only operation (no side effects), but the wording 'devuelve un brief' implies a non-destructive evaluation. Still, more explicit behavioral details (e.g., no modification of data) would improve transparency.

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?

The description is extremely concise: two sentences plus a fragment. The first sentence states the purpose and core behavior, the second provides usage context, and the third specifies input and output. No extraneous words, and it is well-structured with key information front-loaded.

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?

Despite the lack of an output schema, the description adequately explains the return value: 'un brief de evaluación estructurado'. Combined with the clear input description, this provides sufficient context for an AI agent to understand what the tool does and what to expect. For a simple tool with two parameters, 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?

Schema coverage is 100%, so the baseline is 3. The description adds minimal value beyond the schema: it reiterates that the tool receives an agent definition but does not elaborate on the 'language' parameter or provide additional constraints. It does not compensate for any missing schema details.

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 description clearly states that the tool applies the challenger/red-team pattern to an agent's definition or decision, providing data-based counterarguments, self-criticism, and a quality gate. It specifies it is useful as a second adversarial pass, and it describes the input (agent definition) and output (structured evaluation brief). This clearly differentiates it from siblings like 'auditar_contexto' or 'challenger_decision'.

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 description provides clear guidance: 'Útil como segunda pasada adversarial' (useful as a second adversarial pass). This tells the agent to use it after an initial definition or decision. However, it does not explicitly state when not to use it or suggest alternative tools, leaving some 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?

No annotations are provided, so the description carries full burden. It characterizes the operation as an audit ('audita') and states it returns an evaluation, implying it is read-only. However, it does not explicitly confirm no side effects or disclose any behavioral traits beyond the audit nature.

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?

The description consists of two sentences: the first enumerates what is audited, the second specifies input and output. No unnecessary words or repetition, making it efficient and well-structured.

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?

While the tool has moderate complexity, the description lacks details about the output format despite having no output schema. It mentions a 'structured evaluation brief' but does not elaborate on its structure or key fields, leaving some ambiguity about return values.

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?

Both parameters are described in the schema with coverage 100%. The description adds value by noting that a more complete agent definition yields a better evaluation ('Cuanto más completa, mejor la evaluación'), which goes beyond the schema's basic descriptions.

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 description clearly states the tool audits the agent's context, listing specific aspects like layer separation, data relevance, integration strategy, and security considerations. This distinguishes it from sibling tools such as 'evaluar_sistema' or 'revisar_rol_y_frontera' by focusing on context as a strategic asset.

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 description implies use when auditing an agent's context, but does not explicitly state when not to use it or mention alternative tools. Sibling tools exist but are not referenced, leaving the agent to infer usage boundaries.

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?

The description discloses that the tool does not block execution but informs the human, which is a key behavioral trait. However, it does not elaborate on data requirements, side effects, or failure modes. With no annotations, more detail would improve clarity.

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?

The description is extremely concise with two sentences, no redundant or filler content. Every word serves a purpose, making it easy to parse quickly.

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?

Despite lacking an output schema, the description explains the output format (a brief with 3 reasons) and the non-blocking behavior. The input schema is fully documented, so the description covers the core user-facing aspects. Minor gap: no details on how data is used, but acceptable.

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?

All three parameters have schema descriptions covering 100% of the fields. The description adds minimal context beyond the schema, implying that 'contexto' provides data for the reasons and 'decision' is the target. This meets the baseline for full schema coverage.

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 description clearly states the tool generates a brief to question a specific decision, providing 3 data-based reasons against it. It uses specific verbs ('Genera', 'cuestionar') and identifies the output scope. The purpose is distinct from sibling tools, which focus on other evaluation or construction tasks.

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?

No usage guidelines are provided. There is no indication of when to use this tool versus alternatives like 'aplicar_challenger' or when not to use it. The description only explains what it does, not the context for invocation.

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?

With no annotations provided, the description carries the full burden. It states the tool executes a checklist and returns verdicts, implying no side effects. However, it does not explicitly confirm it does not modify the agent definition or disclose any other behavioral traits.

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?

The description is three sentences, efficiently conveying purpose, context, and output. Every sentence adds value, and there is no redundancy or filler.

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?

Given the tool's simplicity (2 parameters, no output schema), the description adequately explains its role as a final gate. The return format is described as 'veredicto punto por punto', which is slightly vague but sufficient for an agent to understand the output type.

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 input schema covers both parameters with descriptions. The tool description does not add significant meaning beyond the schema; it only reinforces that a more complete 'agent_definition' yields a better evaluation. 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?

The description clearly states the tool runs a complete 19-point checklist against the agent definition, serves as the final gate before merging, and returns a point-by-point verdict. It distinguishes itself from sibling tools by focusing on a final readiness check.

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 description explicitly identifies this as the 'gate final antes de mergear', indicating it should be used as the last step before merging. It does not explicitly state when not to use it or list alternatives, but the context is clear enough for an AI agent.

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?

Without annotations, the description fully bears the burden. It discloses that the tool produces a final artifact containing identity layer, least-privilege tools, hard limits, output schema, gates, context, and evaluation. This gives the agent a clear picture of what to expect, though it does not cover potential side effects or authorization needs.

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 efficient sentences, front-loaded with the key insight ('closing step'), and no filler. Every word contributes to understanding the tool's purpose and usage condition.

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?

Given the tool has 4 parameters, no output schema, and moderate complexity, the description covers the essential usage context and output components. It lacks a description of the return format, but the 'formato' parameter and the mention of 'final artifact' provide sufficient guidance. Nearly complete for a tool with well-documented parameters.

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 all parameters are well-described in the JSON schema. The description adds a high-level overview (e.g., 'takes the iterated definition') but does not provide additional meaning beyond the schema. Baseline 3 is appropriate since 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?

Description clearly identifies this as the closure step that produces the final artifact. It distinguishes itself from siblings by explicitly referencing a specific prerequisite (checklist_nacimiento) and listing the components it creates (identity layer, tools, etc.), making its role unique.

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 instructs 'Call this when checklist_nacimiento gives APTO', providing a precise condition for use. The context of being the closing step naturally implies not to use earlier, and the description mentions it consumes the 'iterated definition after revisions', reinforcing the correct timing.

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?

No annotations are provided, so the description must fully disclose behavior. It mentions evaluating and helping create the plan, but does not clarify whether the tool mutates anything, requires specific permissions, or has side effects. The read-only or creative nature is ambiguous.

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?

The description is a single dense sentence that front-loads the purpose and lists key elements. It is concise with no extraneous words, though the density might reduce readability slightly.

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?

Given the complexity and lack of output schema, the description should clarify what the tool returns (e.g., a text report, structured data). It mentions dimensions and metrics but does not specify the output format or how the 'help create' aspect works.

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. The description adds no additional semantic value for parameters beyond what the schema already describes (language, agent_definition). No new constraints or format details are introduced.

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 description clearly states the tool evaluates or helps create the agent's evaluation plan, listing specific dimensions and metrics. It distinguishes from sibling tools like evaluar_sistema or evaluar_autonomia by focusing on the evaluation plan itself rather than agent capabilities.

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?

No explicit guidance on when to use this tool versus alternatives. Sibling tools exist (e.g., evaluar_sistema, evaluar_autonomia) but no comparison or exclusion criteria 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?

With no annotations, the description carries full burden. It discloses the tool's purpose (determining autonomy, verifying mechanisms) and indicates it returns a structured brief. However, it does not detail any side effects, permissions, or data mutation; as an evaluation tool, it likely has no destructive behavior, so this is sufficient.

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 wasted words, purpose stated first, structure is efficient and easy to parse.

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?

Given the tool has two simple parameters and no output schema, the description adequately explains the input and overall goal. However, it does not specify the exact structure of the output 'brief' beyond being structured, which could be improved.

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 both parameters have descriptions. The description adds context: language default is 'es', and agent_definition should be as complete as possible for better evaluation. This adds value beyond the schema's basic descriptions.

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?

Description clearly states the tool determines appropriate autonomy level and verifies risk reduction mechanisms, naming specific levels and mechanisms. It provides a specific verb and resource, distinguishing it from sibling evaluation tools like evaluar_necesidad or evaluar_sistema.

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 description implies usage when an agent definition needs autonomy assessment but does not explicitly state when to use this tool vs alternatives among the sibling tools. No 'when to use' or 'when not to use' guidance is 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?

No annotations are provided, so the description carries the full burden. It describes the tool as evaluating and detecting antipatterns, implying a read-only analysis. However, it does not specify whether it modifies any state, what permissions are needed, or what the output format is. A score of 3 is appropriate given the lack of annotations and incomplete behavioral details.

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?

The description is two sentences, front-loaded with the main purpose, and includes usage guidance and detection focus. Every sentence is necessary and no words are 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?

Given no output schema, the description should explain what the tool returns, but it does not. It also lacks information on side effects or safety, though the tool is likely read-only. For a simple evaluation tool with 2 parameters, the description is adequate but incomplete regarding output and behavioral guarantees.

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% for the two parameters. The tool description does not add new meaning beyond what the schema already provides for 'problema' and 'language'. Since the schema already clearly describes them, the description's contribution is minimal, meeting the baseline of 3.

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 description clearly states the tool evaluates whether a problem justifies an agent or can be solved with simpler alternatives like prompts, workflows, or skills. It also mentions detecting antipatterns. This distinguishes it from sibling tools like auditar_contexto or evaluar_autonomia by focusing on the necessity decision.

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 description explicitly says to use the tool 'ANTES de construir' or to question an existing agent. It provides clear context on when to invoke. However, it does not list specific alternative tools or state when not to use it, though the antipattern detection implies exclusion 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?

No annotations are provided, so the description carries the full burden. The description indicates the tool performs evaluation (read-only analysis) without side effects. However, it does not explicitly state that it does not modify any data, nor does it mention any behavioral traits like rate limits or access requirements. For a read-only tool, this is adequate but not explicit.

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?

The description is a single, concise sentence that immediately states the purpose and lists the evaluation dimensions. It is front-loaded and contains zero unnecessary words. Every part of the sentence adds value.

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?

While the description lists the aspects evaluated, it does not mention the output format or return value. Since there is no output schema, the agent needs to know what to expect. The input parameters are well-covered, but the lack of output description reduces completeness for a tool that likely returns an analysis or report.

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 the schema already documents all three parameters well. The description does not add new details about parameters beyond stating the tool evaluates system integration. The baseline score of 3 applies because the schema is sufficient, and the description adds no further semantic value.

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 description clearly states the tool evaluates how the agent fits into the larger system, listing specific aspects like skills catalog, reuse vs specialization, orchestration, etc. The verb 'Evalúa' and resource 'cómo el agente encaja en el sistema mayor' are specific. It is clearly distinguished from sibling tools that focus on autonomy (evaluar_autonomia) or necessity (evaluar_necesidad).

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 description implicitly indicates the tool is for evaluating system integration of an agent. It does not explicitly state when to use it versus alternatives, but the context of the tool (system coherence) and sibling names provide some guidance. No explicit when-not guidance is given, but the purpose is clear enough.

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?

With no annotations, the description carries full burden. It discloses that missing fields become [PENDIENTE], but does not mention other behavioral traits such as side effects, permissions, or whether the contract is saved. This is insufficient for a tool with 10 parameters.

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?

The description is extremely concise with two sentences. It is front-loaded with the purpose and includes critical behavior. No filler.

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?

Given the high complexity (10 parameters) and no output schema, the description is too brief. It doesn't explain the output format, any constraints, or prerequisites. The agent cannot fully understand how to use the tool from this description alone.

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 the schema already documents each parameter. The description adds the note about missing fields being marked [PENDIENTE], which provides context beyond the schema but does not deepen understanding of individual parameters.

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 description clearly states the verb 'Genera' and specifies the resource 'contrato formal del agente (patrón contractor de §8)'. It also explains the behavior for missing fields. It distinguishes well from siblings like 'construir_agente' or 'checklist_nacimiento' that deal with other aspects.

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 description implies usage when a formal agent contract needs to be generated, but it does not explicitly state when to use this tool vs. alternatives. No exclusions or alternative tool names 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?

No annotations provided, so description carries full burden. It discloses it returns a guide in Markdown, but does not mention any additional behavioral traits such as side effects, caching, or performance characteristics. Adequate for a simple retrieval tool but lacks detail.

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 core function, followed by usage guidance. Every word earns its place; no fluff.

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 tool with no parameters, no output schema, and clear sibling differentiation, the description covers all essential aspects: what it returns, when to use, and when to use alternative tools. Context 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?

No parameters exist, so baseline is 4. The description adds no parameter information, which is acceptable since the schema already has 100% coverage. No need for further detail.

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 description clearly states the tool returns a complete guide in Markdown format. It distinguishes from sibling tools by specifying that for operating on a concrete agent, one should use evaluar_*/revisar_*/auditar_* tools.

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 states when to use (for general context) and when not to use (for operating on a concrete agent, alternative tools are listed). Provides clear guidance and alternatives.

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?

No annotations are provided, so the description must disclose behavioral traits. It does so by describing the tool's action (generate plan) and its verification step. It does not mention side effects, authentication needs, or output format, but the core behavior is clear and no contradictions exist.

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?

The description is two sentences, front-loaded with the action, and every word adds value. No redundant phrases.

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?

Given three parameters, no output schema, and no annotations, the description adequately covers the tool's purpose and constraints. It could state the output format or prerequisites, but for a focused tool in a suite, this is sufficient.

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% for all three parameters. The description does not add significant meaning beyond the schema for 'equipo' or 'language'. It provides context for 'problema' by linking to the verification criteria, but this is marginal. Baseline is 3.

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 description clearly states the tool's purpose: generating a startup plan for a new agent with specific constraints (one agent, one problem, human review). It also outlines verification criteria (recurrent, time-costly, accessible data). This distinguishes it from sibling tools like construir_agente or evaluar_necesidad.

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 description provides usage criteria: the task must be recurrent, time-costly, and with accessible data. However, it does not explicitly state when not to use this tool or mention alternative sibling tools. The context is clear enough for an agent to decide when to invoke it.

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?

No annotations provided, so the description carries the burden. It describes the tool as evaluative and planning-oriented, which implies non-destructive behavior. However, it lacks details on side effects or limitations.

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?

The description is a single, moderately concise sentence that front-loads the key action. It could be slightly more structured but avoids unnecessary words.

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?

The description covers the main evaluation dimensions (tool/resource/prompt, UI/API) but does not mention expected output format or return values. Given no output schema, this is a moderate gap.

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 documentation covers both parameters completely. The description adds context about the tool's goal but does not enrich parameter meanings beyond 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?

The description clearly identifies the tool's purpose: evaluating which parts of an agent to expose via MCP and how (tool, resource, prompt, UI vs API). It is specific and distinct from sibling tools which focus on other evaluation aspects.

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?

No explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites, when not to use it, or compare with sibling tools.

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?

No annotations are provided, so the description carries the full burden. It accurately describes the tool as returning a recommendation without side effects. It does not mention permissions or rate limits, but for a simple read-only recommendation tool, the description is sufficiently transparent.

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?

The description is two sentences: the first explains the purpose, the second provides usage guidance. Every word contributes value, and it is front-loaded with the key action. No unnecessary 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?

The description adequately covers the tool's purpose, when to call it, and the two input scenarios. For a simple recommendation tool with one parameter and no output schema, this is sufficient. It could mention the output format, but that is not strictly necessary given the context.

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 input schema already describes the 'situacion' parameter with enum values and a description. The tool's description adds real-world context: 'agente nuevo (diseño desde cero) o agente existente (mejora).' This supplements the schema without contradicting it.

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 description clearly states it returns a recommended tool flow based on the situation (new vs existing agent). It uses a specific verb 'Devuelve' and distinguishes itself from sibling tools by explicitly positioning itself as the first call when unsure where to start.

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 description provides explicit guidance: 'Llamala PRIMERO si no sabés por dónde empezar.' It also defines two clear use cases (nuevo/existente). However, it does not mention when not to use it or suggest alternatives, though the context makes that less critical.

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?

No annotations provided, so the description carries full burden. It describes verification behavior (no modification), taking agent definition and returning a brief. It does not mention side effects or permissions, but 'verifica' clearly indicates a read-only analysis. A minor gap is the lack of explicit statement on non-destructiveness.

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 purpose, no unnecessary words. Each sentence adds value: first defines what the tool does, second describes input/output. Ideal conciseness.

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?

Given the tool's low complexity (2 params, no output schema), the description fully covers what the agent needs: what it checks, what input it needs, and what output it produces. No gaps for a verification tool.

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% (both parameters have descriptions). The tool description adds that the input is a 'definición del agente' and output is a 'brief de evaluación', but this aligns with schema text. No extra semantics beyond what the schema provides, so 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?

The description clearly states the tool's purpose: verifying that the boundary between recommendation and execution is defined in code (status + gates), not discovered in production. It specifies the input (agent definition) and output (structured evaluation brief). This distinguishes it from siblings like 'revisar_rol_y_frontera' by focusing on execution frontier.

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 description implies usage during design or pre-production by contrasting 'no descubierta en producción'. It provides clear context but does not explicitly mention when not to use it or compare with alternatives. Given sibling tools, explicit guidance would improve, but the context is sufficient.

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?

No annotations are provided, so the description carries full burden. It discloses the evaluation criteria but does not mention side effects, authentication needs, rate limits, or whether the tool modifies state. Adequate but not detailed.

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?

The description is concise—two sentences that front-load the main purpose without unnecessary details. Every sentence earns its place.

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?

Given the tool has no output schema and no annotations, the description adequately explains what it does but does not specify the structure of the returned evaluation brief. More details on output format would improve completeness.

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 parameters are already documented. The description adds minimal value beyond the schema, only restating that it receives agent definition and returns evaluation. Baseline score of 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?

The description clearly states the tool's purpose: verifying outputs for actionability, focusing on strict schema, human-readable summary, and gate status. It specifies the input (agent definition) and output (structured evaluation brief), distinguishing it from sibling evaluation tools.

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?

No explicit guidance on when to use this tool versus alternatives (e.g., evaluar_autonomia, evaluar_necesidad). The description lacks usage context, prerequisites, or 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?

No annotations are provided, so the description carries full burden. It discloses that the tool is a verification (non-destructive) that returns a structured evaluation brief. However, it does not detail the evaluation criteria, possible outcomes, or any side effects, making it adequate but not rich.

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 concise sentences: the first declares the tool's function, the second states inputs and output. No filler words; all information is front-loaded and relevant.

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 verification tool with two parameters and no output schema, the description provides essential input-output expectations. It could be improved by hinting at the structure of the evaluation brief, but overall it is sufficient given the tool's simplicity.

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 the baseline is 3. The description adds no additional context about parameters beyond what the schema already provides, such as expected format of 'agent_definition' or behavior of 'language'.

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 description uses specific verbs ('verifica', 'devuelve') and clearly identifies the resource: role clarity, bounded domain, and explicit responsibility frontier. It distinguishes from sibling tools like 'revisar_frontera_ejecucion' by focusing on role and boundary definition rather than execution constraints.

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 description implies usage contexts: when an agent's role and responsibility boundaries need assessment. However, it does not explicitly state when NOT to use it or contrast it with siblings like 'auditar_contexto' or 'evaluar_autonomia', leaving some 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?

No annotations provided, so description carries burden. It states it returns structuredContent with counts and verdict, and closes the cycle with a contract. Lacks details on side effects (e.g., irreversibility) but overall adequate.

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?

Description is concise with 3 sentences, front-loaded with purpose and details. Each sentence adds value, though could be slightly more structured.

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?

Given 1 parameter with high schema coverage and an output schema (implied), the description provides sufficient context for a CI gate use case.

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%, description mirrors schema without adding new meaning. Baseline score of 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?

Description clearly states verb 'cierra el ciclo' and resource 'checklist_nacimiento', specifies input and output, and distinguishes from siblings by stating it is for CI gates and programmatic consumption, not text parsing.

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 it is for CI gates and programmatic consumption, implying when to use it. Does not explicitly list alternatives, but the context is clear.

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