Server Quality Checklist

Tool Scores

• nexus_consultaA
  3.7/5.0
  Behavior3/5

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

  With no annotations, the description carries full burden. It mentions returning certainty locks and references, supporting conversational history, and cost. But lacks details on rate limits, auth, or edge cases. Decent but not comprehensive.

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

  Conciseness3/5

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

  Description is a single paragraph that front-loads purpose but includes some redundancy (e.g., 'con o sin documento de referencia' and subsequent param mentions). Could be more concise.

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

  Completeness3/5

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

  Given 6 parameters, no output schema, and no annotations, description covers usage context and basic behavior but omits return format, error handling, and limitations. Adequate but incomplete.

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

  Parameters3/5

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

  Schema coverage is 83%, so baseline is 3. Description adds minor context for the history parameter but otherwise doesn't extend beyond schema.

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

  Purpose5/5

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

  The description clearly defines the tool as a free legal Q&A (Nodo A) answering concrete legal questions in natural language, with examples. It distinguishes from siblings by specifying when NOT to use (full document analysis).

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

  Usage Guidelines4/5

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

  Provides explicit when-to-use condition (concrete legal question, no full document analysis) and mentions cost (1 crédito). However, it doesn't explicitly name sibling tools that should be used instead.

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

• nexus_auditA
  3.8/5.0
  Behavior3/5

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

  With no annotations provided, the description carries the full burden. It explains the tool performs an audit that generates a verification block and confidence score, mentions cost (1-2 credits), and describes the adversarial nature (Nodo B). However, it does not clarify if the tool is read-only or modifies any data, nor does it detail authentication or rate limits. The basic behavioral context is present but incomplete.

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

  Conciseness4/5

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

  The description is a single dense paragraph that front-loads the main purpose and then provides usage conditions and output details. It is efficient with no wasted words, though structuring with bullet points could improve scanability. For the amount of information conveyed, it is appropriately concise.

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

  Completeness3/5

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

  Given 7 parameters (2 required), no output schema, and no annotations, the description covers the tool's purpose, prerequisite, output (confidence score and V-XX block), and cost. It lacks details on the exact format of the verification block output, which would help the agent process results. While adequate for basic decision-making, it leaves some gaps in expected output structure.

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

  Parameters3/5

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

  Schema description coverage is 57% (4 of 7 parameters have descriptions). The tool description adds context that the 'analysis' parameter should come from `nexus_analyze`, which is valuable beyond the schema. However, parameters like 'jurisdiction' and 'jurisdictionB' lack descriptions in both schema and description, leaving their purpose ambiguous. The description does not fully compensate for the missing schema descriptions.

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

  Purpose5/5

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

  The description clearly states the tool performs a cross-audit of a previous analysis (Nodo A) using adversarial control (Nodo B), specifying it detects unsupported claims, misassigned locks, omissions, and contradictions, and generates a verification block with a confidence score. This distinguishes it from siblings like nexus_analyze (initial analysis) and nexus_adversarial (likely separate adversarial function).

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

  Usage Guidelines4/5

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

  The description provides explicit usage guidance: 'USE WHEN: user wants a second validation layer before presenting to client or court' and states the prerequisite of having run `nexus_analyze` first. It implies when not to use (if previous analysis not performed) but does not explicitly compare against sibling alternatives like nexus_adversarial or nexus_redteam, which could also be used for validation.

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

• nexus_monte_carloA
  3.8/5.0
  Behavior3/5

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

  No annotations are provided, so the description bears full responsibility for behavioral disclosure. It explains the process (simulate variables, requalify risks, compute IRC) and outputs (impact tables, recommendations), but omits side effects, auth requirements, or rate limits. Without annotations, more detail on behavioral traits would be beneficial.

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

  Conciseness4/5

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

  The description is a single paragraph that efficiently conveys purpose, process, and usage cues. It front-loads the key information and avoids fluff, though slightly longer than necessary.

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

  Completeness4/5

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

  Given the tool's complexity (5 parameters, no output schema), the description covers inputs, process, outputs (tables and recommendations), and usage context. It lacks return format details, but the mention of output types is sufficient for most agents.

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

  Parameters2/5

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

  Schema description coverage is 60%, yet the tool description adds minimal value beyond what the input schema already provides. Parameters like 'text' and 'analysis' are not elaborated beyond the schema descriptions. The description does not compensate for the missing schema coverage, leaving some parameters under-explained.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: Monte Carlo simulation for stress-testing contract risk profiles under user-defined variables, with specific outputs like IRC and shielding recommendations. It distinguishes from sibling tools by explicitly naming the simulation and scenario analysis functionality.

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

  Usage Guidelines4/5

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

  The description includes explicit usage guidance: 'USAR CUANDO: el cliente quiere saber cómo aguanta el contrato shocks externos'. It also mentions cost (4 créditos). However, it does not specify when not to use or provide alternative tools, which slightly diminishes clarity.

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

• nexus_opinionA
  3.8/5.0
  Behavior3/5

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

  No annotations exist, so the description must carry full weight. It discloses the use of a different model and the cost (2 credits), but lacks details on side effects, data handling, 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.

  Conciseness4/5

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

  The description is front-loaded with the core function, followed by specific criteria and usage recommendation. It is concise but thorough, wasting no words.

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

  Completeness4/5

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

  Given the lack of output schema and 5 parameters, the description covers the essential purpose, usage context, and cost. It does not explain return values, but that is acceptable without an output schema.

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

  Parameters2/5

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

  The description only implicitly refers to 'nodaAResponse' and does not explain other parameters like jurisdiction, language, or analysisContext. With 60% schema coverage, the description adds minimal value beyond the schema.

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

  Purpose5/5

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

  The description clearly identifies the tool as providing a second legal opinion by reexamining a Node A response with a different LLM, specifying the search for omissions, biases, and errors. This distinguishes it from siblings like nexus_adversarial which likely focuses on adversarial testing.

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

  Usage Guidelines4/5

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

  Explicitly states when to use: when the client demands double validation on a legal position. It does not cover when not to use or alternatives, but the guidance is clear and actionable.

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

• nexus_doctrinaA
  4/5.0
  Behavior4/5

  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 key behavioral traits: it differentiates between 'Doctrina consolidada' (≥2 sources) and 'Criterio orientativo', indicates binding nature and conflicts with Supreme Court jurisprudence, and mentions cost. It does not cover rate limits or authentication, but for a search tool these are less critical.

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

  Conciseness4/5

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

  The description is a single dense paragraph but front-loads the core purpose. Every sentence provides useful information (corpus, distinctions, usage, cost). It is concise with no redundancy, though it could benefit from bullet points for readability.

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

  Completeness3/5

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

  With 4 parameters (1 required) and no output schema, the description adequately explains the search scope and output features (distinguishes doctrinal types, indicates binding). It does not specify the return format (text, citations, etc.), which might leave an agent guessing. Given the complexity of doctrinal search, a bit more detail on output structure would improve completeness.

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

  Parameters3/5

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

  Schema coverage is 50%, and the description adds some value for the query parameter (example in natural language) but does not elaborate on jurisdiction, language, or history beyond what the schema already provides. The description's example helps clarify usage, but it does not compensate fully for the missing schema descriptions.

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

  Purpose5/5

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

  The description clearly states the tool's purpose: 'BÚSQUEDA DE DOCTRINA ADMINISTRATIVA' (search of administrative doctrine). It specifies the resource (corpus de doctrina admin/tributaria including DGT, TEAC, Consejo de Estado) and distinguishes it from sibling tools like nexus_jurisprudencia_search which focuses on court rulings. The use of 'RAG + LLM' and examples of queries further clarifies its scope.

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

  Usage Guidelines4/5

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

  The description explicitly says 'USAR CUANDO: el usuario pregunta por el criterio administrativo en un tema fiscal/regulatorio concreto', providing clear context for when to use. It also mentions cost (1 crédito) and distinguishes between doctrinal types. However, it does not explicitly state when not to use or name alternative tools, though sibling tool names imply alternatives for legal search.

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

• nexus_draftA
  4/5.0
  Behavior4/5

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

  Given no annotations, the description carries the transparency burden. It discloses that output follows 'formato y candados obligatorios de MODULE-DRAFT' and degrades to L3-NV if notification date is uncertain. This is good but could specify more about side effects or authentication needs.

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

  Conciseness4/5

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

  The description is a single focused paragraph in Spanish, conveying purpose, behavior, and usage context without redundancy. It could be more structured (e.g., bullet points) but is efficient.

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

  Completeness3/5

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

  With 8 parameters, no output schema, and no annotations, the description should cover return format and error handling. It mentions cost and degradation but not what the tool returns (presumably generated text). This gap reduces completeness.

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

  Parameters3/5

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

  Schema coverage is 50%, meaning half of parameters lack descriptions. The description does not elaborate on parameter meanings beyond what the schema provides. It briefly mentions 'instructions' but doesn't compensate for under-documented parameters.

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

  Purpose5/5

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

  The description clearly states it generates a first draft of a legal document (recurso, demanda, etc.) following mandatory format. It specifies the resource (legal brief) and action (drafting), and distinguishes from sibling tools that are analytical or search-based.

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

  Usage Guidelines4/5

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

  The description explicitly says 'USAR CUANDO: el usuario pide redactar un escrito concreto' (use when user requests a specific document). It also notes typical context (after analysis) and degradation behavior. However, it lacks explicit contraindications or when to avoid.

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

• nexus_adversarialA
  4.2/5.0
  Behavior3/5

  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 mentions a credit cost (2-3 credits) which hints at resource usage but does not disclose whether the tool is read-only, whether it modifies any state, or what authentication is required. The generative nature suggests no side effects, but this is not made explicit.

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

  Conciseness5/5

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

  The description is concise (3-4 sentences) with no redundancy. It front-loads the core purpose, provides a sibling distinction, a usage guideline, and ends with cost. Every sentence adds value.

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

  Completeness4/5

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

  The description covers purpose, usage, sibling distinction, and cost. However, it lacks details about the output format (prose text is implied but not explicit). Since there is no output schema, the description should more clearly describe what the agent can expect as a result.

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

  Parameters3/5

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

  Schema coverage is 33% (only `text` and `analysis` have descriptions). The description adds context for `analysis` (causes argumentation against each conclusion). For other parameters (`jurisdiction`, `legalBranch`, `professionalRole`, `language`), no additional meaning beyond enum/defaults is provided. The description does not fully compensate for the low schema coverage.

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

  Purpose5/5

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

  The description clearly identifies the tool's purpose: adversarial argumentation (Nodo C — modo contraparte). It specifies it constructs the strongest counter-arguments against conclusions from Nodo A. It also distinguishes from sibling `nexus_redteam` by contrasting their outputs (prose vs. structured JSON).

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

  Usage Guidelines5/5

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

  The description explicitly states when to use the tool: prepare litigation or anticipate objections in negotiations. It provides a direct WHEN-TO-USE clause: 'USAR CUANDO: el cliente necesita anticipar objeciones de la otra parte.' It also differentiates from `nexus_redteam` clearly.

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

• nexus_cross_border_compareA
  4.2/5.0
  Behavior4/5

  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 discloses the output format (JSON with structured table), key identified elements, and cost (2-4 credits). It does not mention side effects or auth needs, but as an analysis tool 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.

  Conciseness5/5

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

  The description is a single paragraph with all key information front-loaded. Each sentence adds value: purpose, items identified, output format, usage scenario, cost. No redundant or filler content.

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

  Completeness4/5

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

  Given 4 parameters, no output schema, and no annotations, the description covers the tool's purpose, input, output format, and usage context well. It could explicitly mention the default legalBranch and language values, but the schema covers those. The description is largely complete for an agent to understand invocation.

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

  Parameters3/5

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

  Schema description coverage is 50% (text and jurisdictions have descriptions). The description adds context for text ('hechos/contrato') and jurisdictions ('2-15 países'), but does not mention legalBranch or language, leaving their purpose inferred from the schema. Baseline 3 is appropriate as the schema already covers half the parameters.

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

  Purpose5/5

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

  The description clearly states it performs a multi-jurisdictional comparison of legal treatment, listing specific aspects (applicable law, forum, tax risks, etc.). It differentiates itself from siblings like nexus_analyze (single-jurisdiction) by explicitly focusing on cross-border scenarios.

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

  Usage Guidelines4/5

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

  The description includes 'USAR CUANDO' with a clear scenario (client operates in multiple countries). It implies when not to use (single jurisdiction) but does not explicitly name alternative tools. The guidance is clear but lacks exclusion criteria.

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

• nexus_analyzeA
  4.3/5.0
  Behavior4/5

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

  With no annotations, description carries full burden. It details the analysis process (extraction, jurisdiction application, certainty locks, blocking signals), mentions cost (~1-3 credits), and describes output structure. Lacks explicit statement about non-destructive nature, but overall provides substantial behavioral context.

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

  Conciseness4/5

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

  Description is well-structured: title, summary, output specifics, cost, and usage guidance. Front-loaded with purpose. Some verbosity in Spanish, but every sentence serves a purpose. Could be slightly more concise.

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

  Completeness4/5

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

  Given complexity (9 params, 1 required, no output schema), description covers purpose, usage, behavioral details, and output format. Includes cost and audit trail. Does not detail error handling or limitations, but is sufficient for an AI agent to select and invoke correctly.

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

  Parameters4/5

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

  Schema coverage is 100% with descriptions for all 9 parameters. Description adds context beyond schema, e.g., that 'jurisdictionB' activates MODULE-BILATERAL, and explains how 'mode' and 'professionalRole' affect analysis. This adds meaning for effective parameter use.

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

  Purpose5/5

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

  Description starts with 'ANÁLISIS PRIMARIO JURÍDICO (Nodo A — ISO 31000)' and explicitly states it examines documents to extract parts, risks, clauses, deadlines, applicable norms, and relevant jurisprudence. It provides a clear verb and resource, and distinguishes from siblings by positioning itself as the primary legal analysis tool ('Nodo A').

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

  Usage Guidelines4/5

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

  Includes explicit usage guidance: 'USAR CUANDO: el usuario aporta un documento jurídico y pide análisis de riesgos, viabilidad, cláusulas críticas, o defensa en juicio.' While it does not specify when not to use or list alternatives, the context from sibling tool names (e.g., nexus_adversarial, nexus_audit) implies differentiation.

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

• nexus_jurisprudencia_searchA
  4.4/5.0
  Behavior4/5

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

  Description discloses use of vector model (voyage-law-2), character limit for excerpt (2000 chars), and that it returns permanent URLs. No annotations provided, so description carries full burden; for a read-only search, this is adequate. No contradictions.

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

  Conciseness4/5

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

  Description is information-dense but could be slightly more concise. However, every sentence adds value: purpose, technology, jurisdictions, return format, usage guidance, cost. Front-loaded with purpose in Spanish, making it scannable.

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

  Completeness5/5

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

  Despite no output schema, the description explains return fields (title, source, excerpt, URL). It covers corpus sizes (ES ~141k, CO ~106k), expansion plans, and cost. For a search tool with three parameters, this is comprehensive.

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

  Parameters4/5

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

  Input schema has 100% coverage with detailed descriptions for all three parameters (query, jurisdiction, top_k). The description adds context on corpus sizes and example queries, adding value beyond the schema. Baseline 3 is exceeded due to helpful examples.

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

  Purpose5/5

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

  The description clearly states it is a semantic search for jurisprudence using vector query. It specifies the source (Nexus corpus, CENDOJ, TS/AN/TSJ/AP, etc.) and exactly what is returned (top-K results with title, source, excerpt, URL). This distinguishes it from sibling tools even without seeing their descriptions.

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

  Usage Guidelines4/5

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

  Explicit 'USAR CUANDO' section provides clear use cases: locating sentences on a topic, contrasting an argument, or building a citation dossier. It also mentions the cost is free. No explicit when-not or alternatives, but the use cases are sufficient for selection.

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

• nexus_redteamA
  4.4/5.0
  Behavior4/5

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

  With no annotations provided, the description bears full responsibility. It discloses the destructive mode, adversarial nature, and output structure (vulnerabilities with severity, risk score 1-100). It also mentions cost (5 credits). It does not cover every edge case (e.g., document size limits) but provides substantial behavioral context.

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

  Conciseness5/5

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

  The description is highly concise: three sentences covering purpose, output, usage scenarios, and cost. Information is front-loaded and each sentence adds value without redundancy.

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

  Completeness4/5

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

  Given the simple input (one string parameter) and no output schema, the description adequately explains the tool's function, output fields, and appropriate use cases. Minor omissions (e.g., error handling, limits) are not critical for this straightforward tool.

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

  Parameters4/5

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

  Schema coverage is 100% (one parameter with description). The tool description reinforces the parameter's purpose ('texto íntegro del documento a atacar adversarialmente') and adds context about typical use (contracts). This adds meaning beyond the schema alone.

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

  Purpose5/5

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

  The description clearly states the tool performs adversarial analysis of documents, listing specific elements like legal loopholes, trap clauses, and catastrophic risks. It uses a strong verb ('análisis hostil') and identifies the resource (document), and distinguishes from sibling tools like 'nexus_adversarial' by specifying a destructive mode and unique output fields.

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

  Usage Guidelines4/5

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

  The description explicitly provides usage scenarios with 'USAR CUANDO:' including pre-signing strategic contracts, M&A audit, and aggressive due diligence. It does not explicitly state when not to use or name alternatives, but the positive guidance is clear and context-rich.

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