AyA-MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.2.0
Disambiguation2/5
The tools are grouped by domain, but there are large overlapping clusters of context/validation/audit tools, such as montar_contexto vs montar_contexto_completo vs contexto_empresa_planejar, and validacao_gates vs validacao_aprovar_saida vs evidencia_validar_tarefa. An agent would need to read many descriptions carefully to avoid selecting the wrong gate/audit/context tool.
Naming Consistency3/5
All names share the aya_ prefix, snake_case, and a domain segment, which makes them recognizable and searchable. However, word order is inconsistent (verb_object vs object_verb) and several tools are noun phrases rather than verb actions, such as aya_codigo_outline, aya_games_checklist, and aya_mcps_catalogo_referencia.
Tool Count1/5
Exposing 88 tools in a single MCP is an extreme count and will heavily impact context usage and tool-selection accuracy. Even with the toolset-reduction mechanisms mentioned, the full surface is far beyond a well-scoped 3-15 tool set.
Completeness3/5
The set is very thorough for validation, memory, evidence, and framework governance, with both read and mutation operations for memory, code, and files. However, there are notable gaps: no general project file read, no create/update/delete lifecycle for requirements/rules/tasks, and MCP policy tools stop at classification/recommendation without applying permissions.
Average 3.2/5 across 88 of 88 tools scored. Lowest: 1.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 19 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/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 of behavioral disclosure. The one claim — that the LLM does not provide aprovado=true — hints at the tool's role but never states what the tool does, returns, or mutates. A cryptic fragment is not an adequate behavioral contract.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but it is under-specified rather than concise — two cryptic sentence fragments that fail to state what the tool does. The brevity does not earn its place because the content is essentially uninformative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the schema is trivial (0 params, no output schema), the description is completely inadequate: it never explains what the 'final seal' means, what action the tool performs, or where it fits in the validation flow. An agent cannot decide to call this tool correctly based on this definition.
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?
The tool has 0 parameters with 100% schema coverage, so there is nothing for the description to document and the baseline is 4. The mention of 'aprovado=true' is the only semantic hint and is not tied to any parameter, but no parameter information is required here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description ('Selo final calculado. A LLM nao fornece aprovado=true.') contains no verb-resource statement of what the tool does; it reads as an internal workflow note about a state, not an action. Despite the name suggesting an approve-exit validation step, an agent cannot determine the tool's function from this text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to call this tool, no preconditions, and no mention of alternatives such as the sibling aya_validacao_gates. Among a large family of validation-related tools, the agent receives zero routing information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish that the tool is read-only and idempotent, and the description does not contradict them. However, the description adds little behavioral context beyond 'opens', failing to disclose what the operation returns, how relationships are included, or any 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no redundant wording. It front-loads the core operation and resource, making it easy to scan, though it could use a second sentence to resolve ambiguity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large set of graph-related sibling tools and no output schema, the description is too sparse to fully support correct selection and invocation. It does not differentiate this tool from read, search, or observe variants, nor does it specify what an agent should expect after calling it.
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?
With 0% schema description coverage, the description must compensate for the bare 'ids' parameter. It does clarify that the ids refer to entities and the relationships between them, but it does not explain expected formats, whether both entity and relationship ids are mixed, or how many are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('abre') and a resource ('entidades especificas e relacoes'), so it is not a tautology. However, 'abrir' is ambiguous: it does not state whether the tool returns, loads, or presents the data, nor how it differs from sibling tools like aya_memoria_grafo_ler or aya_memoria_grafo_buscar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus the many graph-related siblings. It provides no conditions, exclusions, or alternative suggestions, leaving the agent to infer the appropriate context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the full behavioral burden. It implies a read-only listing action, but it does not disclose whether the tool scans directories, filters, caches, writes anything, or how it behaves when no RNs are found. The output format is only partially hinted at.
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?
The description is a single front-loaded sentence with no filler, which is structurally efficient. However, it is so sparse that it omits important contextual and parameter information, so it is concise more by omission than by design.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but without annotations or an output schema the description should supply more. It states the main output but does not explain what 'RNs encontrados' depends on, how 'pasta' affects results, or what an agent should expect regarding empty results or return formatting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description never mentions the 'pasta' parameter. The non-trivial default '#Saida' is left unexplained, so the description adds no meaning beyond the parameter name and default already visible in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and a concrete resource: it lists RNs found and the files where they appear. This is enough to recognize the tool as a read/list operation and to distinguish it from detection-oriented siblings, though the acronym RN is not expanded and no sibling is explicitly contrasted.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus similar listing or detection tools. No prerequisites, no expected workflow, and no mention of when the default 'pasta' would or would not fit are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry all behavioral disclosure. It does not state whether the gate is read-only, what happens on failure, whether it returns a report or exception, or any side effects. Merely listing covered areas is insufficient.
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 concise sentence with no fluff, effectively front-loading the scope. However, it lacks any structured usage or behavioral guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As an aggregate tool, it likely orchestrates multiple sub-audits, yet the description gives no indication of what the gate returns, how pass/fail is determined, or how the expected version parameter interacts with the checks. With no output schema, this is a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional parameter 'versaoEsperada' but the description does not mention it or explain its purpose. Schema description coverage is 0%, so the description must compensate, and it fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as an aggregate gate covering multiple framework aspects (integrity, version drift, harnesses, specs, skills, mirrors). It distinguishes itself from the individual validators among siblings by being an aggregate, which gives purpose clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this aggregate gate versus the individual validators like aya_framework_integridade_validar or aya_framework_drift_validar. No mention of prerequisites, conditions, or recommended scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It only states that the tool 'detecta' certain packs, without disclosing side effects, return shape, input expectations, or whether it is read-only. The verb implies a non-mutating analysis, but that is left implicit.
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 concise sentence with the key action front-loaded and examples adding useful specificity. It has no wasted words, though it is structured as one sentence with no additional guidance or parameter clarification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one required parameter and no annotations or output schema, the description is too thin to fully support correct invocation. It does not specify what to provide in 'consulta', what the detection output looks like, or when this tool is preferred over the many sibling pack-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the only required parameter 'consulta' is completely undocumented in both the schema and the description. The description mentions domain examples but never explains what the agent should pass as 'consulta', leaving the required input ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb ('Detecta') with a specific resource ('packs obrigatorios/especializados') and gives concrete examples (Termo de Uso, WAHA, NFS-e Gov, fiscal, Freebuff, Evolution API). It is easy to understand the tool's focus, though it does not explicitly differentiate it from sibling pack tools like aya_framework_packs_listar or aya_framework_packs_selecionar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many sibling tools, such as aya_framework_packs_listar or aya_framework_packs_selecionar. No conditions, exclusions, or alternative routing are provided, so an agent must infer usage solely from the name and examples.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. 'De forma sanitizada' hints at validation but doesn't specify whether the write overwrites or merges, whether locking is required, or what safety guarantees exist. For a mutating write to a central state file, this is a significant gap that leaves critical behavior undisclosed.
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?
The description is a single efficient sentence, which is structurally sound. However, the brevity comes at the cost of substance — the one sentence does almost no work beyond the tool name. It reads as under-specification rather than disciplined conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a state-mutating tool with 10 parameters, no output schema, and no annotations, a one-sentence description is severely inadequate. The risk profile — writing to estado-execucao.json — demands at minimum clarity on merge-vs-overwrite behavior and sequencing constraints relative to lock tools. This leaves an agent without enough information to call it safely.
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 0%, so the description must compensate, but it says nothing about any of the 10 parameters. It doesn't clarify whether the write is a wholesale replacement or a field-level merge, nor how defaults interact with existing state. Parameter names are self-descriptive, but the update semantics are completely undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Atualiza), a specific resource (estado-execucao.json), and a manner ('de forma sanitizada'). This is clear about what the tool does. However, it doesn't distinguish from siblings like aya_memoria_criar_checkpoint, aya_arquivo_escrever_seguro, or aya_memoria_gerar_handoff, and the meaning of 'sanitizada' is left ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. With multiple memory and file-writing siblings (aya_arquivo_escrever_seguro, aya_arquivo_substituir_literal, aya_memoria_criar_checkpoint), the description offers no context for selection, no prerequisites, and no exclusions. The agent must guess when this is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says the tool 'gera' a handoff; it does not clarify whether the output is returned, persisted, or appended to memory, nor does it describe side effects, ordering constraints, or failure behavior. This is too thin for a 10-parameter memory-related tool.
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?
The description is concise and front-loaded with the main action, but it is under-specified rather than efficiently complete. One short sentence does not provide enough structural guidance for a tool with this many parameters and no annotation support.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, no annotations, no output schema, and a 0% schema coverage rate, a single sentence is not nearly enough context. The agent lacks information about required field semantics, optional field usage, expected output format, side effects, and how this relates to sibling memory tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the ten undocumented parameters. It does not mention any of them—neither required fields like projeto/fase/resumo nor optional fields like bloqueios or proxima_tarefa—leaving the agent to guess what each value should contain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Gera') and resource ('handoff/contexto de retomada curto para outra LLM'), so an agent can tell this creates a short resumption summary rather than a full report. However, it does not explicitly contrast itself with closely related siblings like aya_memoria_obter_contexto_retomada or aya_memoria_criar_checkpoint, so differentiation is only implicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'para outra LLM' implies the use case: when a short handoff context needs to be produced for another model. But there is no explicit guidance about when to prefer this tool over alternatives, when not to use it, or what prerequisites might apply.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the whole burden and only states the operation, not its consequences. It does not disclose whether release is idempotent, whether an invalid/stale token fails or is ignored, or whether the lock is owned by the calling agent. For a mutating shared-state operation this is insufficient.
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?
One short sentence with no filler; the key action is front-loaded. It is concise but arguably under-sized for a tool with two required parameters and no annotations, so it does not quite earn top marks.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating operation with no output schema and no annotations, the description does not explain the lock lifecycle, the relation to each 'tarefa', return values, or prerequisites. An agent cannot know from this text when it is safe to call the tool. The information provided is insufficient for reliable invocation.
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 coverage is 0%, and the description only references 'token', giving the token a clear role as the release credential. The required 'tarefa' parameter is never mentioned, and there is no explanation that the token should come from a prior lock acquisition. It adds too little to compensate for the undocumented schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The phrase 'Libera lock usando token' clearly states the action (release lock) and the instrument (token), and the sibling set includes aya_agentes_adquirir_lock, making the release-vs-acquire opposition visible. However, it does not define what 'lock' refers to or mention the required 'tarefa' context. This is clear but not as rich as a fully self-contained definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No sentence tells the agent when to call this tool, e.g., after aya_agentes_adquirir_lock, at task completion, or on failure. There is no exclusion or comparison with siblings, so the agent must infer from the name alone. This is at best implicit usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only reveals that the tool writes a sanitized checkpoint to a specific path. It does not disclose whether files are overwritten, what 'sanitized' entails, any permission requirements, side effects, or return behavior.
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 front-loaded sentence with no filler words. It is efficient, though its brevity comes at the cost of operational detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 6 parameters, 3 required, no schema descriptions, no annotations, and no output schema. A one-line description providing only the action and destination is far from enough for an agent to reliably construct a valid call.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description mentions no parameters at all. The agent is left to infer the meaning of tarefa, agente, resumo, testes, arquivos, and proxima_tarefa solely from their names, which is insufficient for correct invocation.
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 states a specific verb ('Cria'), a clear resource ('checkpoint sanitizado'), and an explicit destination ('#Saida/tmp/checkpoints'). It distinguishes this tool from memory siblings like aya_memoria_gerar_handoff and aya_memoria_atualizar_estado by naming the checkpoint resource uniquely.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool versus alternatives such as handoff generation, state updates, or graph persistence. It only states what the tool does, not when it should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals only that the tool compares, but not whether it is read-only, what it returns on match/mismatch, what 'indicios' are, or any side effects or error conditions. This is insufficient for safe invocation.
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?
The description is short and contains no filler, but it is under-specified rather than efficiently complete. It front-loads the comparison action but omits essential definitions of key terms, so the brevity borders on incompleteness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no input schema, no output schema, and no annotations, the description should provide enough context to replace those missing structured details. It does not explain what CONFIG and manifesto are, where they come from, what 'indicios de stack' means, or what happens after the comparison. Sibling tools do not resolve this ambiguity.
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?
The tool has zero parameters and an empty input schema, so the baseline is 4. The description does not need to document parameters that do not exist; there is no schema ambiguity to resolve.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Compara') and a resource ('indicios de stack entre CONFIG e manifesto'), so an agent can roughly infer this is a comparison/validation tool. However, 'indicios de stack' is ambiguous (stack traces vs technology stack) and 'CONFIG'/'manifesto' are undefined, which prevents a precise understanding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus sibling validators like aya_framework_drift_validar, aya_framework_integridade_validar, or aya_validacao_gates. The description does not mention prerequisites, context, or exclusions, leaving all usage decisions to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It implies a read-only computation, but it does not state side effects, return format, what a 'gate' is, or how '#Saida' is resolved. There is no contradiction with annotations because none exist.
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?
The description is a single front-loaded sentence with no filler, so it is structurally concise. However, it is under-specified rather than efficiently complete, relying on unexplained jargon and leaving too much unsaid.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and no parameter definitions, the description alone is insufficient for an agent to understand what the tool consumes, produces, or how it fits into the validation workflow. The mention of '#Saida' hints at context but does not explain it.
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?
The input schema has zero parameters and schema description coverage is vacuously 100%, so the baseline for this dimension is 4. The description adds slight semantic context by naming '#Saida' as the implicit subject of the calculation, which is the only meaningful information available.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('calcula') and a named resource ('gates reais da #Saida'), which gives some surface-level clarity. However, 'gates' is unexplained domain jargon and there is no explicit contrast with sibling tools like aya_validacao_aprovar_saida, leaving the operational scope ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus the many validation-related siblings, nor any mention of preconditions, context, or alternatives. The agent must infer usage entirely from the terse description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states the action but not what happens if the lock is already held, whether the call blocks or fails, lock ownership semantics, or the need to release it later. These are important behavioral traits for a lock tool.
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?
A single, direct sentence with no filler or redundancy. The core verb-object-scope information is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a lock-acquisition tool with no annotations and no output schema, the description omits crucial context: contention behavior, blocking vs. failure, ownership, and the counterpart release operation. It is too sparse for safe autonomous invocation.
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 0% and the description does not explain 'tarefa' or 'agente'. The names and the tarefa pattern give some self-evident meaning, but the description adds no parameter-level semantics beyond the schema, which is a clear gap at this coverage level.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Adquire lock lógico exclusivo') on a clear resource ('de uma tarefa'), distinguishing it from the sibling 'aya_agentes_liberar_lock' by framing this as acquisition. It could be stronger by explicitly contrasting with release or veto tools, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to acquire the lock, preconditions, or when to prefer this over siblings. The agent must infer from the name and siblings that this pairs with aya_agentes_liberar_lock; the description itself gives no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. The verbs 'detecta' and 'aponta' imply a read-only analysis, but the description never states whether it reads the filesystem, whether it is side-effect free, or what the returned routing information looks like. The arquivosAlvo parameter hints at file access, but this is never disclosed.
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?
A single front-loaded sentence with the main verb first and zero filler words. Every word contributes to the core meaning, and the output components (runtime, agent, routers) are listed compactly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, no annotations, and 0% schema description coverage, the description is too thin. It omits the meaning of both parameters, the return format, and the distinction from overlapping siblings. An agent cannot reliably determine what to pass in 'consulta' or what to expect back.
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 0%, so the description must compensate for the schema's silence on 'consulta' and 'arquivosAlvo'. It does not: nothing explains what a 'consulta' should contain (a question, a path, a code snippet?) or what 'arquivosAlvo' targets. The domain/stack wording loosely maps to 'consulta', but this is inference, not explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Detecta'), a resource ('stack/dominio'), and the output it produces ('aponta runtime, agente e routers minimos do framework'). This gives an agent a concrete idea of what the tool does. However, it does not differentiate from closely related siblings like aya_dominio_detectar or aya_projeto_verificar_stack, which likely overlap on the detection aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no exclusions, and no named siblings. With at least three plausible overlapping tools in the sibling list (aya_dominio_detectar, aya_projeto_verificar_stack, aya_framework_inventariar), an agent has no basis to select this one over them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full burden of behavioral disclosure. It does reveal selection heuristics — respecting stack, skills, LLM level, and character budget — but says nothing about whether the tool reads project files, whether it is read-only, what it returns, how it behaves when the budget cannot be met, or any side effects.
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?
A single tight sentence with a front-loaded verb ('Monta') and no filler. Every word earns its place by specifying the object, the addressee, and the four constraints. There is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a 5-parameter tool with no annotations and no output schema, so a one-sentence description is insufficient. An agent cannot determine the return format, the meaning of arquivosAlvo and permitirPesado, the boundary between this tool and montar_contexto_completo, or what happens when limiteChars is too low for the requested context.
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 0%, so the description must compensate. It does connect 'nivel da LLM' to nivelModelo and 'budget de caracteres' to limiteChars, and implies consulta is the task being packaged. However, arquivosAlvo and permitirPesado are completely unexplained, and no meaning is added beyond the raw enum/default values already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Monta pacote minimo de contexto para uma tarefa' (builds a minimal context package for a task), with further qualifiers on stack, skills, LLM level, and character budget. The word 'minimo' implicitly contrasts with the sibling aya_framework_montar_contexto_completo, but the differentiation is implicit rather than explicit, so it loses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus closely related siblings such as aya_framework_montar_contexto_completo, aya_framework_buscar_conteudo, or aya_framework_pack_montar. The 'minimo' qualifier hints at a lightweight-context use case, but there is no explicit when-to-use, when-not-to-use, or alternative-routing information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Como não há anotações, a descrição carrega todo o peso comportamental. Ela dize que converte gatilhos em gates/skills/tools obrigatorios, mas não dize se a operação é somene de planejamento, se grava ou modifica algo, nem cual é o resultado produido.
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?
Uma únca frasse, sem ruído, com a transformação núcleo e o benefício declarados. O tamanho é adequado ao nível de detahe oferecido, sem repeições desnece ssárias.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Para uma ferramenta com 2 parâmetros, sem anotações e sem esquema de saída, a descrição é incompleta: não dize o formate esperado de 'consulta', o significado dos níveis de modelo, o retorno, efeitos colaterais ou relação com outras ferramentas de planejamento.
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?
A cobertura de descrição do esquema é 0% ea descrição não explica 'consulta' nem 'nivelModelo'. Os nomes e o enum são parciamente autoevidentes, mas não há valor adicionado além do esquema, então a descrição não compen sa a lacuna.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
A descrição usa um verbo específico ('Converte') e um recurso concreto ('gatilhos do Agents') transformados em 'gates/skills/tools obrigatorios'. Isso deixa clara a função principal, embora não diferencie explicitamente de irmãos como aya_toolsets_sugerir ou aya_framework_montar_contexto.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Não há orientação explícita de quando uar a ferramenta nem exclusões. A menção a 'tarefa' e 'reduzir dependencia da memoria da LLM' sugere contexto e benefício, mas não é suficient para o agente decidir entre esta e as muitas ferramentas irmãs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. It implies a read-only listing operation but does not explicitly state side effects, whether it searches recursively, what 'encontrados' means, or what the output format is. For a tool with no annotation safety hints, this is a significant gap.
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 front-loaded sentence with no filler; every word contributes meaning. It is concise without being a bare tautology, though it could be expanded with parameter and usage details without becoming bloated.
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?
For a simple listing tool with one optional parameter, the description conveys the core return value: CTs and the files where they appear. However, it omits the meaning of the 'pasta' parameter, the source of 'encontrados', and there is no output schema to fill that gap. It is minimally viable but not complete.
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 schema exposes a single optional parameter 'pasta' with default '#Saida' and 0% schema description coverage. The description never mentions 'pasta', how it influences the search, or what '#Saida' represents. The parameter name is somewhat self-explanatory, but no real semantic detail is added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Lista'), resource ('CTs encontrados'), and associated result ('arquivos onde aparecem'). It is distinguishable from the sibling 'aya_testes_detectar_genericos' because 'listar' implies enumeration rather than detection. However, the acronym 'CTs' is undefined and the phrase 'encontrados' does not specify where or how they are found.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool instead of alternatives such as 'aya_testes_detectar_genericos'. The description does not state preconditions, use cases, or when another test-related tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It does reveal a useful conditional behavior and the 'sem abrir a biblioteca pesada inteira' detail, but it does not clarify whether the tool writes files, mutates state, requires permissions, or what the output of 'planeja contexto' is. For a tool with no annotation safety profile, this leaves important behavioral traits undisclosed.
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 efficient sentence with the primary purpose front-loaded and the conditional behavior placed second. It contains no filler or repetition. Slight jargon such as 'framework Agents' and 'biblioteca pesada' could be clearer, but the structure is compact and readable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With five parameters, no annotations, no output schema, and zero schema description coverage, this tool needs a more complete description. It does not explain what a 'contexto seletivo' consists of, how the parameters shape the result, or what the tool returns. An agent would struggle to invoke it correctly purely from this text.
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 0%, so the description needed to compensate for the five parameters, but it mentions none of them. Param names like 'consulta', 'limiteChars', and 'arquivosAlvo' hint at meaning, yet the description never explains how they relate to 'planejar contexto seletivo'. The parameter semantics are therefore mostly left to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'Planeja', and resource, 'contexto seletivo', and adds scope 'para qualquer area atendida pela empresa'. It also outlines a secondary action, assembling a relevant package when the Agents framework is available, which helps distinguish it from heavier context tools. However, it does not explicitly name sibling tools, so differentiation is implicit rather than direct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides one clear condition: when the Agents framework is available, it mounts the package without opening the heavy library. This implies a selective-context use case versus a full-context tool, but it does not state when not to use it or name a preferred alternative among the many sibling tools. The guidance is therefore contextual but lacks explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, but it only states the validation criteria. It does not disclose whether the operation is read-only, what it returns (boolean, list of missing evidence, error), whether it has side effects, or what happens when validation fails.
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 direct sentence with no filler and the main validation criterion is front-loaded. It is concise and readable, though it sacrifices useful parameter detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema and no annotations, the description is incomplete for a caller: it lacks the result format, parameter semantics, and behavioral guarantees. The core criteria are present, but an agent cannot reliably know how to invoke this correctly or interpret the response.
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 0%, so the description must compensate, but it only loosely relates to 'tiposObrigatorios'. It does not explain what 'tarefa' should contain (ID, name, object), how the optional list interacts with the default [], or whether omitting 'tiposObrigatorios' changes validation behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Valida se') and the resource ('a tarefa') with specific criteria: approved evidence and all required mandatory types. It differentiates this as a validation-style tool from evidence registration/list siblings, though it does not explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrasing 'Valida se a tarefa possui evidencias aprovadas' implies this is used to check task evidence readiness before approval or next steps, but it gives no explicit when-to-use or when-not-to-use guidance. There are no named alternatives or exclusions, leaving the agent to infer context from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. 'Detectar' implies a read-only analysis, but the description does not state what happens when divergence is found, whether anything is modified, whether it returns a report or throws an error, or if VERSION/CHANGELOG must exist. This is a significant gap for a tool with no annotation support.
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?
A single, well-formed sentence that is concise, front-loaded with the action verb, and contains no filler. Every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is too thin. It identifies what is compared but fails to explain the expected behavior, return value, side effects, or failure modes. An agent would not know what to do with the result or what conditions trigger the tool.
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?
The only parameter, 'versaoEsperada', has 0% schema description coverage, but the description mentions 'versao esperada do pacote', which maps directly to the parameter and gives it semantic meaning. However, it does not clarify the expected format (e.g., semver), whether it is mandatory despite being optional in the schema, or what happens when omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Detecta' and a specific resource ('divergencia entre VERSION, CHANGELOG e versao esperada do pacote'), clearly indicating the tool's purpose. While it doesn't explicitly distinguish itself from sibling validation tools like aya_framework_integridade_validar, the named comparison targets make its scope clear enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given about when to use this tool versus the many sibling validation/audit tools. The use case is only implied by the description (detect version drift), but there is no mention of prerequisites, when not to use it, or how it differs from similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without any annotations, the description carries the full behavioral burden. It adds useful behavioral nuance beyond the name: mandatory special packs, budget handling, and heavy-library protection. However, it does not disclose side effects, prerequisites, read-only status, or potential impacts on state or memory.
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 sentence with no filler; it front-loads the primary action and adds key constraints. While it could benefit from clearer separation or more detail, it is appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters, no output schema, no annotations, and many closely related siblings, this description is insufficient. It omits return values, parameter handling, failure behavior, and relationships to alternative context-building tools, leaving an agent without enough information to invoke it confidently.
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 0%, so the description must compensate, but it does not explain the parameters 'consulta', 'limiteChars', 'nivelModelo', or 'arquivosAlvo'. The term 'budget' may loosely hint at limiteChars, but it is not explicit, and the required 'consulta' parameter is not described at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'Monta' and names a specific resource: 'contexto minimo + packs especiais obrigatorios', which differentiates it from simpler siblings like aya_framework_montar_contexto. It does not explicitly reference an alternative, but the functional scope is reasonably clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance exists on when to use this tool versus alternatives such as aya_framework_montar_contexto or aya_framework_pack_montar. The description implies it is for a complete context with mandatory packs, but leaves the selection decision to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Como não há annotations, a descrição carrega o ônus de explicar o comportamento. 'Lista' indica leitura e informa o que a ferramenta retorna, mas não detalha como os REQs são encontrados nem se há qualquer efeito colateral. Para uma ferramenta de listagem simples, isso é minimamente aceitável.
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?
A descrição é uma frase curta, direta e sem redundância, com verbo e objeto claramente posicionados. Poderia ser um pouco mais rica sem deixar de ser concisa.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Para uma ferramenta sem output schema e sem annotations, a descrição fornece apenas o comportamento básico, mas não explica o papel de 'pasta' nem o formato esperado do resultado. A ausência de orientação de uso e de detalhes sobre o retorno deixa lacunas relevantes.
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?
A cobertura do schema é 0% e a descrição não menciona o parâmetro 'pasta'. O agente precisa inferir pelo nome e pelo default '#Saida' se o parâmetro é o diretório de entrada, saída ou varredura, o que é uma lacuna significativa.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
A descrição usa verbo específico 'Lista' e recurso claro 'REQs encontrados e arquivos onde aparecem', o que a diferencia de outros listadores como aya_regras_listar ou aya_testes_listar. Apesar de não definir 'REQs', o contexto do nome e dos irmãos torna o propósito compreensível.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Não há orientação sobre quando usar esta ferramenta em relação às alternativas de listagem nem sobre pré-condições, como a necessidade de uma pasta #Saida existir ou de uma varredura prévia. O uso precisa ser inferido apenas pelo nome e descrição.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It only states that a team is assembled; it does not say whether this modifies state, overwrites an existing team, requires prior context, or returns a plan versus persisting anything.
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 focused sentence that front-loads the action and resource, then adds useful domain examples. There is no redundant wording or unnecessary filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should clarify what the agent should expect as a result and how to provide the 'consulta' input. Neither is addressed, leaving an important gap for an agent deciding whether and how to invoke this tool.
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 single parameter 'consulta' has 0% schema description coverage and is not mentioned in the description at all. Since the schema provides no meaning and the description does not compensate, an agent cannot infer what input this tool expects or how to supply it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Monta') and resource ('equipe multiagente universal'), and explains that it is driven by the project's real domains with concrete specialist examples. This makes the tool's purpose clear, but it does not explicitly contrast it with sibling planning tools, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is implied: use this tool when you need to assemble a multiagent team based on project domains. However, there are no explicit instructions about when to use it versus alternatives like aya_contexto_empresa_planejar or aya_template_primeiro_planejar, and no exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It usefully states that the operation does not alter code, but it does not disclose persistence, idempotency, permissions, or response behavior, so transparency is only partial.
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?
A single sentence that front-loads the action, object, and the key non-mutation guarantee. There is no filler, redundancy, or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with four parameters, no annotations, and no output schema, this one-line description is too thin. It omits parameter semantics, side effects, expected return, and how vetoes relate to other workflow records, leaving an agent to guess.
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 schema has no per-property descriptions, and the description only clarifies that the agent is a reviewer/tester/critic. It does not define 'alvo', 'motivo', or 'evidencias' beyond their names and schema constraints, so the description only partially compensates for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Registra') and resource ('veto de agente revisor/tester/critico'), and the qualifier 'sem alterar codigo' makes the non-code-modifying intent clear. It is distinguishable from code-editing tools, though it does not explicitly name a sibling alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage conditions, prerequisites, or comparisons to alternative tools are provided. The phrase 'sem alterar codigo' hints at a non-mutating registration action, but the description does not explain when to prefer this over related registration/logging tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden and does contribute meaningful behavior: the write is immediate and the log is append-only, which implies entries are never overwritten or deleted. However, it does not disclose whether the file is created if missing, what permissions are required, the entry format produced, or any error behavior.
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?
A single front-loaded sentence with zero waste: verb first, immediate action, target file. Every word earns its place, and the key behavioral trait (append-only) is included without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, 0% schema coverage, and no annotations, the description is too thin: the agent cannot infer how to populate verbo/modelo/objeto/arquivo, when to prefer this over sibling logging tools, or what the call returns. The core purpose is clear, but the surrounding operational details an agent needs to invoke it correctly are missing.
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 0%, so the description must compensate, but it only loosely maps to parameters via "acao" (hinting at verbo+objeto). The meanings of verbo, objeto, modelo, and arquivo, their relationship to the append-only log entry, and how defaults behave are entirely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ("Registra"), a concrete resource ("log append-only tmp/LLM_EXECUTION_LOG.md"), and a temporal qualifier ("imediatamente"), making the core function unmistakable. It is distinguishable from sibling logging tools like aya_loop_falha_registrar and aya_evidencia_registrar by naming the exact target file, though it does not explicitly contrast itself against them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus the several sibling logging/registration tools (aya_loop_falha_registrar, aya_evidencia_registrar, aya_memoria_grafo_upsert). Usage context is only implied by the description itself; there are no exclusions, prerequisites, or alternative-selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure, and it only reveals that the tool reads memory. It does not state the output format, what happens when no memory/checkpoint exists, whether the operation is idempotent and safe, or whether it depends on prior state. For a tool whose sole job is resuming context, this is a significant gap.
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 front-loaded sentence with zero filler — every word carries meaning. It is efficient and clean, though so terse that it sacrifices behavioral context that could have been conveyed in the same space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low schema complexity, this tool has no output schema and no annotations, so the description is the only source of operational detail. It fails to explain what the returned context looks like, whether it can be called before any checkpoint exists, or how it relates to the checkpoint/initialization siblings in the same family. An agent has enough to guess the intent but not enough to trust the call.
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?
The input schema is empty (0 parameters), so the rubric baseline is 4. No parameter explanation is needed and the description omits none, since there is nothing to document. It adds no parameter meaning, but none is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Le' = Reads) and resource ('memoria minima' = minimal memory), and adds the purpose clause 'para outra LLM continuar' (for another LLM to continue), which goes beyond a pure restatement of the name. However, it does not differentiate from siblings such as aya_framework_montar_contexto or aya_memoria_criar_checkpoint, and 'memoria minima' is left vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention that a checkpoint or agent initialization (aya_memoria_criar_checkpoint, aya_memoria_agents_inicializar) may be a prerequisite, nor does it contrast with context-building siblings like aya_framework_montar_contexto_completo. The agent must infer usage entirely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It only states what is listed, without revealing whether the operation is read-only, whether external template sources trigger network or filesystem access, or what side effects (if any) might occur. The term 'frozen' is not explained, leaving the behavior unclear.
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 sentence with no wasted words, making it efficient and front-loaded. However, the phrasing 'fontes de template externas e template visual congelado' is slightly cryptic and could be structured for easier parsing, though it remains appropriately brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description should clarify what the tool returns and what key terms mean. It does not state whether it returns a list, a count, or an object, and it leaves 'external template sources' and 'frozen visual template' undefined. An agent calling this tool would still be uncertain about the expected output shape and the semantic scope of the listed items.
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?
The tool has zero parameters, so the baseline is 4. The description needs to explain no parameter semantics, and the empty input schema confirms there is nothing to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'Lista' (lists), and names concrete resources: external template sources and a frozen visual template. It distinguishes itself from mutating siblings like aya_templates_congelar or validation-focused aya_templates_validar_hash, though the phrase 'template visual congelado' is somewhat domain-specific and could be clearer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives, nor any mention of exclusions or conditions. The description only implies that the tool is for listing, but provides no context about when it should be preferred over other listing tools like aya_toolsets_listar or aya_mcps_listar_permitidos.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=true. The description adds significant behavioral details: it requires a SHA-256 precondition (hash match before editing), performs backup, handles encoding, and includes auditing. These go beyond the annotations, though it does not explain the failure behavior when the hash does not match or what the backup/audit entails.
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, compact sentence that front-loads the key features (interval editing, hash precondition, backup, encoding, audit). It is efficient and avoids fluff, though its brevity sacrifices essential detail. This is a reasonable trade-off for a tagline but insufficient as a full functional description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is destructive, has no output schema, and lacks parameter documentation. The description gives only a high-level summary and omits return values, error handling, or the consequences of a hash mismatch. For a file-editing operation with these precautions, the context is incomplete and the agent cannot confidently anticipate outcomes.
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 schema has 7 parameters with zero description coverage, and the description does not explicitly explain any of them. It only indirectly hints at 'intervalo' (matching inicio/fim) and 'SHA-256' (matching hashEsperado), but critical parameters like caminho, novoTexto, and the optional ones remain undocumented. With 0% coverage, the description fails to compensate for the missing parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Edicao cirurgica por intervalo' (surgical editing by interval), clearly indicating a line-range edit operation, and lists distinct features (SHA-256 precondition, backup, encoding, audit). It differentiates from siblings like aya_arquivo_substituir_literal (literal replace) and aya_arquivo_escrever_seguro (safe write) through its focus on interval-based editing. However, it does not explicitly name the file resource except in the tool name, and the phrasing is terse.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus its alternatives, no conditions for choosing it, and no exclusions. For a mutating tool with many siblings, this is a notable gap. The agent is left to infer context from the name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral transparency burden. It does disclose that the operation is detection-oriented and that it deliberately surfaces multiple domains rather than assuming one stack. It does not mention return format, failure behavior, or any side-effect/permission considerations, but for a read-style detection tool this is a moderate gap.
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 concise sentence with the core action front-loaded. The second clause adds relevant context without excess wording. Minor deduction because the background statement about AyA-MCP's assumption is not directly actionable invocation guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description leaves important gaps: what 'domains' means in this codebase, how the optional 'consulta' parameter works, what the return value contains, and how it compares to stack-related siblings. It is minimally functional but not fully complete.
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 input schema has one parameter, 'consulta', with no description and 0% schema description coverage. The main description never mentions 'consulta' or explains how it influences domain detection, so it adds no parameter meaning beyond the parameter name itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete action: 'Detecta multiplos dominios do projeto' and adds a meaningful distinction by saying the MCP does not assume a workspace belongs to a single stack. This helps separate it from single-stack-oriented siblings, though the term 'dominios' is somewhat vague and 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.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second clause provides useful context: the tool should be used when multiple domains/stacks may exist and one should not assume a single stack. However, it does not explicitly state when to use this tool instead of related siblings such as aya_projeto_verificar_stack or aya_framework_detectar_rota, so usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It states what is audited but not whether the operation is read-only, whether it can modify files, what failure conditions exist, or what output/report is returned. The verb 'audita' implies inspection, but that is inference rather than explicit disclosure.
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?
A single sentence with an efficient list structure: verb, resource, and concrete checks are all front-loaded. Every word adds meaning and there is no redundant phrasing.
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?
For a tool with one optional parameter and no output schema, a one-line description can be nearly sufficient, and this one clearly names the audit scope. It remains incomplete because it does not explain the behavioral contract (read-only vs mutation), the difference between 'boot' and 'execucao', or what the tool returns, which matters for correct invocation.
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 0%, and the description does not explain the 'fase' parameter. The phrase 'durante execucao' hints at the 'execucao' enum value, but it does not define the 'boot' phase, how each phase alters the audit, or the meaning of the default. This is only partial compensation for the missing schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly opens with a specific verb ('Auditar') and a specific resource: operational rules inherited from Agents. It enumerates concrete checks (UTF-8 without BOM, mojibake signs, mandatory memory in tmp during execution), which distinguishes it from sibling audit/validaton tools by content area. It lacks an explicit contrast with other audit siblings, so it is not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: when auditing the inherited operational rules of Agents against the listed criteria. However, it provides no explicit when/ when-not guidance and does not differentiate from alternatives like aya_framework_harnesses_auditar or aya_framework_governanca_auditar, leaving routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description does not need to restate safety traits. It adds the source file path and the existence condition, which are useful behavioral details, but it does not disclose what happens if the file is missing, how the content is parsed, or what the output shape is.
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?
The description is a single, short sentence with no waste, but it is arguably too terse and omits important context such as return values or failure behavior. It is not a tautology, but it borders on under-specification rather than being optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description must explain what the agent should expect when calling the tool. It only says reads the file when it exists, leaving unclear whether it returns the parsed JSON list, a summary, or any indication when the file is absent. For a zero-parameter read tool, this is incomplete.
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?
The tool accepts zero parameters, so the description does not need to elaborate on parameter meanings. With no params, the baseline is 4, and the description correctly focus on the tool's behavior rather than input fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Le' / reads) and a specific resource ('#MCP/permitidos.json'), which together with the tool name 'aya_mcps_listar_permitidos' conveys the purpose of reading/listing allowed MCPs. It distinguishes itself from sibling tools like aya_mcps_classificar and aya_mcps_recomendar_capacidade by referencing the permitidos.json file, but it does not explicitly state what the tool returns after reading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only hint is the conditional 'quando existir' (when it exists), which is a behavioral condition, not guidance on when to use this tool versus alternatives. No sibling exclusions or contextual cues are provided to help an agent decide between this and other MCP-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds the useful scope detail that it searches entities, observations, and relations in persistent memory, but it does not describe matching semantics, result format, limits, or pagination.
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 sentence with no redundant words, and the action verb is front-loaded. For a one-parameter read-only search tool, this length 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?
The tool is relatively simple and annotations cover its read-only/idempotent behavior, but the description leaves out return-value shape, query formulation details, and any distinction from graph 'ler'/'abrir' siblings. It is minimally viable but has clear gaps.
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 0%; the only parameter, 'consulta', is an undocumented required string. The description and parameter name imply it is the search query, but no detail is given about query syntax, language, exact vs semantic matching, or supported formats, so the description does not compensate for the missing schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete action ('Busca') and a clear target ('entidades/observacoes/relacoes na memória persistente'), so the core purpose is identifiable. However, it does not explicitly differentiate from siblings like aya_memoria_grafo_ler or aya_memoria_grafo_abrir, whose names also suggest reading graph memory.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this search tool instead of other graph-memory tools. The use case must be inferred from the name and the verb 'Busca'; there are no exclusions, conditions, or alternative tool mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It mentions the authorized root constraint, which is a useful scoping detail, but it does not describe error behavior (e.g., file not found, unauthorized path), whether the operation is read-only, or what the return value looks like. No contradiction with annotations since none exist.
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, front-loaded sentence with no superfluous words. It states the action and the scope in a clear, concise manner. Every word contributes meaning.
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?
For a simple one-parameter tool with no output schema, the description is minimal. It doesn't specify the return format (e.g., hash string, hex, base64) or error handling. While the task is straightforward, an agent would be uncertain about the output structure and failure modes. The scope constraint is helpful but not sufficient.
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 0%, so the description must compensate. It adds meaning to 'caminho' by specifying it must be a file within the authorized root, but it doesn't clarify the path format (absolute/relative), whether directories are allowed, or any other constraints. Partial compensation but leaves gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Calcula SHA-256 de arquivo' (calculates SHA-256 of a file), and adds a scope constraint 'dentro da raiz autorizada' (within authorized root). This clearly conveys what the tool does and distinguishes it from hash validation tools, though it doesn't name any siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. It does not mention any conditions or exclusions, such as when to use a hashtag validation tool instead. The description is purely declarative without context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Validates' implies a check but doesn't state whether it has side effects, what constitutes success/failure, or what output is produced. The agent cannot predict the tool's behavior beyond a generic validation action.
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, concise sentence with no redundant information. It is appropriately sized for a tool without parameters and an output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool has no parameters and no output schema, it is a validation operation. The description lacks any indication of what the tool returns (e.g., boolean, errors, report) or how the result is communicated. An agent cannot fully understand the outcome of calling this tool, making the context incomplete.
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?
The tool has zero parameters, so schema description coverage is trivially 100%. There is nothing for the description to add about parameter semantics. The baseline for 0 params is 4, and there are no gaps to penalize.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action 'validates' on the resource 'traceability' with a scope of 'minimal structural coverage'. It is clear and distinct from the sibling 'aya_rastreabilidade_calcular_cobertura' (calculate coverage) because 'validate' vs 'calculate' implies different operations. However, it doesn't explicitly name the alternative, so it's a 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like calculating coverage. There is no mention of prerequisites, context, or when not to use it. The description provides no decision criteria for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the validation scope but does not reveal what happens when invalid paths are found, whether the operation is read-only, or what the return value looks like.
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?
A single front-loaded sentence with zero filler. Every word contributes to the meaning, and the verb and target resource are stated immediately.
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?
For a zero-parameter validator, the core function is adequately stated. However, with no annotations and no output schema, the behavior on validation failure and the overall role in the output-validation flow remain undisclosed.
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?
The tool has 0 parameters with 100% schema coverage, so the baseline of 4 applies. The description adds useful context about what the tool operates on (#Saida, backtick-cited paths) even though no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Verifica') and a precise resource ('caminhos relativos citados em backticks na #Saida'), making the tool's function clear. It does not explicitly name or distinguish itself from sibling validation tools, 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus siblings like aya_validacao_aprovar_saida or aya_codigo_referencias. Context is merely implied by the description, with no exclusions or alternative tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full behavioral burden. It only states that it lists evidence, implying a read-only operation, but provides no details about possible side effects, required permissions, return shape, or behavior when the parameter is omitted. Minimal behavioral disclosure.
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?
A single, short sentence that is front-loaded with the core action and scope. There is no redundancy or filler; every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and any parameter descriptions, the description is too minimal to be fully complete. It does not explain the parameter format, the expected output structure, or what happens if the optional parameter is omitted. An agent would have to infer these details from the name and siblings, leaving gaps for correct 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?
The schema has one parameter 'tarefa' with no description (0% coverage). The description adds some meaning by indicating evidence is listed per task, suggesting the parameter is used as a filter. However, it does not clarify the expected value format, whether it is an ID or name, or the effect of omitting it, leaving ambiguity for the agent.
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 states a clear verb ('Lista' - lists) and resource ('evidencias reais' - real evidence) with a scoping qualifier ('por tarefa' - by task). It distinguishes from sibling aya_evidencia_registrar (register) and aya_evidencia_validar_tarefa (validate) by describing the listing action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There is no mention of conditions, exclusions, or when it is preferable to list evidence instead of registering or validating it. The purpose is implied but no explicit usage context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description must carry the full behavioral disclosure. It does disclose the key trait 'append-only' and warns about gate violations, which is useful. But it does not mention permissions, error behavior, irreversibility beyond append-only, or what happens on duplicate registrations.
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?
Two short sentences, front-loaded with the core action and the append-only trait, followed by a meaningful warning. Every word earns its place; no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with five required parameters, no annotations, and no output schema, the description is incomplete. It conveys the operation and a key constraint but leaves the agent guessing about parameter meaning, return value, failure modes, and how this tool interacts with the broader evidence workflow.
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 coverage of parameters in the description is effectively 0% — it says nothing about 'tarefa', 'tipo', 'descricao', 'aprovado', 'resultado', or 'comando'. The schema itself defines types and the enum for 'tipo', but the required fields 'descricao' and 'resultado' are not even listed as properties in the given schema snippet, and the description provides no compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Registra evidencia') and the resource (evidence), with the added trait 'append-only' distinguishing it from modification or deletion tools. The second sentence adds context about the inherited gate, reinforcing what this tool is for, though it does not explicitly differentiate it from sibling evidence tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The gate warning ('Decarar pronto sem evidencia observada viola o gate herdado do Agents') implies that this tool should be used before declaring a task as ready, and that it is required to avoid violating the gate. However, it does not explicitly state when to use this tool versus alternatives like aya_evidencia_listar or aya_evidencia_validar_tarefa.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It says 'pesquisa seletivamente' (selectively searches) but does not disclose whether the search is read-only, whether it follows symlinks, whether it indexes binary files, performance implications of 'incluirPesados', or what happens with large packages. It does not state the return format or whether results are sorted/relevance-ranked.
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 sentence that front-loads the verb and resource, then enumerates the searched content types. It is compact and readable, though it could have used the saved space to explain parameters or usage distinctions.
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?
The tool is a search operation with 3 parameters, no output schema, and a 0% schema-description coverage. For an agent to call it effectively, it would need to know what the returned results look like, how 'incluirPesados' affects performance/results, and how it differs from aya_framework_skills_buscar. The description covers the core purpose but leaves these operational details undocumented.
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 0%, so the description must compensate for parameter meaning, but it only explains 'consulta' implicitly via 'pesquisa... conteudo' and says nothing about 'limite' or 'incluirPesados'. The parameter names are reasonably self-explanatory in Portuguese ('limite' = limit, 'incluirPesados' = include heavy items), and defaults are present in the schema, so the description adds minimal but some value over a 0%-coverage schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('buscar' = search) and a precise resource ('conteudo textual do pacote de agentes', including .aya, routers, runtimes, configs and skills). This clearly distinguishes it as a content-search tool within the AYA framework, though it doesn't explicitly contrast it with siblings such as aya_framework_skills_buscar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for selective text search across agent package content, which gives a clear context. However, it does not explicitly state when to use this over the similar sibling tools like aya_framework_skills_buscar or aya_memoria_grafo_buscar, nor does it provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Não há annotations, então a descrição carrega todo o peso. 'Audita' sugere uma operação de leitura/análise, mas não declara explicitamente se é não-destrutiva, se exige permissões, se produz relatório, ou se possui efeitos colaterais. Faltam detalhes comportamentais essenciais para um agente saber o que esperar.
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?
Uma única frase objetiva, sem excessos, com a ação no início e a lista de alvos logo em seguida. Cada elemento da frase contribui para o entendimento do escopo.
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?
Para uma ferramenta sem parâmetros, a descrição identifica o alvo da auditoria de forma razoável. Porém, faltam informações sobre o significado de 'cobertura', o formato do resultado e o contexto de uso em relação às ferramentas irmãs de auditoria. É funcional, mas deixa lacunas que o agente precisaria resolver com uma chamada exploratória.
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?
A ferramenta não possui parâmetros, então o baseline é 4. A descrição acrescenta contexto útil ao listar os harnesses cobertos, o que ajuda o agente a entender o escopo da auditoria mesmo sem schema de entrada.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
O verbo 'Audita' indica claramente a ação e o recurso é 'cobertura do pacote' para oito harnesses específicos (Claude, Codex, OpenCode, etc.). A descrição é específica o suficiente para diferenciar de muitos irmãos, mas não esclarece o que exatamente significa 'cobertura' nem diferencia explicitamente de outros auditores como aya_framework_workspace_auditar ou aya_framework_governanca_auditar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Não há orientação sobre quando usar esta ferramenta em vez das alternativas. Entre vários siblings de auditoria, não há nenhuma condição de uso, exceção ou referência a outra ferramenta. O agente precisa inferir o contexto apenas pelo nome e pela descrição.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It conveys what is checked but not whether the tool is read-only, what it returns on success versus failure, whether it raises errors or produces a report, or anything about side effects. 'Audita' implies a non-destructive audit, but that is an inference, not a stated guarantee, and the absence of an output schema makes the return behavior entirely opaque.
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?
A single sentence with no filler; the resource being audited is front-loaded and the check being performed is stated compactly. Every part of the sentence earns its place.
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?
For a zero-parameter tool the description is minimally viable: the agent knows what is being audited. But with no output schema and no annotations, the agent is left without knowing what the result looks like or what remediation to trigger if a mirror lacks the minimum blocks. Some guidance on interpreting or acting on the audit outcome is missing.
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?
The tool has zero parameters and schema description coverage is trivially 100%, so the no-parameter baseline of 4 applies. There is nothing for the description to clarify about inputs, and it correctly does not invent any.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Audita' - audits) on a specific resource (the Claude/Codex/Gemini/Cline/Windsurf/Cursor/Copilot mirrors) checking for 'blocos operacionais minimos' (minimum operational blocks). This goes beyond a tautology and gives concrete scope. However, it does not explicitly distinguish itself from the many overlapping sibling audit/validation tools (aya_framework_integridade_validar, aya_framework_drift_validar, aya_framework_workspace_auditar), so the agent must still infer what makes mirrors validation unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus the many sibling validation and audit tools. There are no named alternatives, no exclusions, and no conditions like 'when mirrors may have drifted' or 'before assembling context'. The word 'continuam' weakly implies periodic re-auditing, but that is indirect and does not help an agent route correctly among roughly a dozen aya_framework_* validation siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure. It only says 'Valida', which implies a validation/check operation, but it does not state whether the validation is read-only, what happens on invalid contracts, or what the tool returns. This is a material gap for a tool with no output schema.
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?
A single sentence with a front-loaded verb and a compact list of contract types; no filler or repetition. It is appropriately sized for the tool's simplicity.
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?
For a zero-parameter tool, the listed scope is useful and the agent can invoke it without input preparation. However, with no annotations and no output schema, the description should at least hint at the outcome/return behavior of the validation, which it does not. It is minimally viable but not fully complete.
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?
The input schema has zero parameters, so there is no parameter burden for the description to carry. The description focuses on scope rather than parameter details, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Valida') and a specific resource ('contratos machine-readable herdados do Agents'), enumerating the contract types covered (boot, encoding, log, mirrors, skill frontmatter, error contract, fiscal). It is clear about what it validates, but it does not distinguish itself from sibling validators such as aya_arquivo_encoding_valiar or aya_framework_mirrors_valiar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to choose this tool instead of the many sibling validation tools. The scope list implies it is for validating those contract types, but the description does not state alternatives, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It does reveal an important behavior: on the second identical failure it creates a BLOQUEIO-DE-LOOP instead of repeating the same strategy. However, it does not mention side effects like whether the loop block stops execution, how the agent is notified, or whether the tool returns anything.
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, compact sentence that delivers the key behavior efficiently. It is front-loaded with the main action and includes the trigger condition and the resulting state change. There is no waste, though a little more detail on parameters would not hurt.
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?
For a simple two-parameter tool with no output schema, the description captures the fundamental purpose and the loop-blocking rule. However, it omits what 'detalhe' should contain and what output or side effects the agent should expect, leaving some ambiguity about how to invoke it correctly in practice.
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 0%, so the description must compensate for both parameters. It only implicitly explains 'assinatura' as the failure signature and says nothing about 'detalhe', leaving the agent to guess what detail information should be provided. This is a significant gap for a required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: count repeated failures and create a BLOQUEIO-DE-LOOP on the second identical signature. It clearly conveys the tool's core mechanism, though it doesn't explicitly name the sibling tool that clears loop blocks (aya_loop_falha_limpar) to distinguish itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when a strategy fails repeatedly, to avoid wasting tokens. However, it provides no explicit when-to-use/when-not-to-use guidance and does not name the alternative tool for clearing loop blocks. The usage context is inferred rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does disclose meaningful logic: it is provider-agnostic and considers local/remote model, data training, and context sensitivity. However, it does not state whether the tool is read-only, whether it produces a decision/recommendation, or whether it has side effects.
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?
A single sentence that front-loads the core purpose, adds the key provider-agnostic nuance, and lists the decision criteria without waste. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and no output schema, the description is incomplete: it does not explain what the tool returns, how the rule is applied in practice, whether it can block/allow, or what happens with missing inputs. The logic criteria are helpful but not sufficient for confident 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 0%, so the description must compensate. It partially does by mapping its concepts to parameters: local/remote to 'local', training with data to 'treinaDados', and context sensitivity to 'dadosSensiveis'. It does not clarify the 'modelo' string format or explain defaults/required behavior beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Aplica a regra de privacidade') and names the relevant resource/scope (model privacy evaluation, provider-agnostic). It is clear enough to differentiate from the broader sibling set, though it does not explicitly name or contrast a sibling alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives such as aya_modelo_perfil_execucao or aya_politicas_planejar. The description implies a privacy-evaluation context but provides no exclusions, prerequisites, or routing conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It reveals that coverage is recalculated, suggesting a mutating operation, but does not state side effects, persistence behavior, required context, or whether any output is produced.
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 sentence with no filler, front-loads the actionable verb, and is appropriately sized for a parameterless tool. Every word earns its place.
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?
For a zero-parameter tool, invocation is unambiguous and the description identifies the domain and action. However, it does not mention expected outcomes, side effects, or how it relates to the validation sibling, making it only minimally complete.
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?
The tool has zero parameters and the schema fully covers this, so the baseline is 4. The description adds domain context (REQ/RN/CT, traceability, queue) but no parameter details are necessary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the operation ('Recalcula') and the resource ('cobertura de REQ/RN/CT na rastreabilidade e fila'). It is specific enough to convey what the tool does, though it does not explicitly differentiate from the similar sibling aya_rastreabilidade_validar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool vs alternatives, no trigger conditions, and no mention of prerequisites. The verb 'Recalcula' implies it should be used when coverage is stale, but that is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It adds one useful scoping trait — the tool returns only detected tasks matching the T-XXXX pattern — but says nothing about what the list contains, whether it reflects current workspace state, or how 'detected' tasks are identified. For a read-ony listing operation the risk is low, but the disclosure is minimal.
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?
A single front-loaded sentence with the verb first and no filler; 'T-XXXX detectadas' adds specificity without verbosity. It is appropriately sized for a zero-parameter tool, though the phrasing is terse and slightly cryptic.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should clarify what the call returns and what 'T-XXXX detectadas' means as a detection source, but it does neither. An agent invoking this tool is left unsure about return format, scope, and how the task list is produced.
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?
The tool has zero parameters with 100% schema coverage, so there is nothing the description needs to add about inputs. The T-XXXX mention relates to the content of the result, not to parameter semantics, and no parameter explanation is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Lista tarefas T-XXXX detectadas' (lists detected T-XXXX tasks). The T-XXXX pattern gives an agent useful scoping information and helps distinguish this from other list tools like aya_testes_listar or aya_requisitos_listar, though it does not explicitly contrast with task-centric siblings such as aya_tarefas_proxima.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No when-to-use or when-not-to-use guidance is provided. An agent must infer from the name alone when to pick this over related task tools like aya_tarefas_proxima, aya_tarefas_validar_dependencias, or aya_tarefas_detectar_ciclos; there are no exclusions, prerequisites, or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It reveals only the surface behavior, detecting dependencies for nonexistent tasks, and does not say whether the tool is read-only, what it returns, whether it reports violations, or whether it modifies anything.
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?
A single, front-loaded sentence with no filler or repetition. It communicates the exact purpose concisely and earns its place.
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?
For a zero-parameter detection tool, this is minimally viable, but with no output schema and no annotations it does not say what the agent should expect after execution, such as a list of violations, an error, or a success signal. The missing return/error/behavior detail keeps it from being complete.
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?
The tool has zero parameters and 100% schema description coverage, so there are no inputs the description needs to explain. The zero-parameter baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action, 'Detecta', and a precise resource: dependências for nonexistent tasks. This is enough to distinguish it from sibling aya_tarefas_detectar_ciclos, which targets cycles rather than missing tasks, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to invoke this tool versus alternatives such as aya_tarefas_detectar_ciclos or aya_caminhos_validar_referências. The intended workflow context is left entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It states only that the tool detects short, generic, or copied CTs, but does not disclose whether it is read-only, whether it modifies anything, what its output shape is, or any side effects.
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, compact sentence with no filler. The verb and object are front-loaded, and every word contributes to conveying the tool's core purpose.
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?
For a zero-parameter detection tool, invocation is trivially simple, but the description does not state what kind of result is returned (e.g., list, report, boolean) nor does it define the ambiguous term 'CTs'. Given the absence of an output schema, the description should provide at least a little more completion around expected outcomes.
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?
The tool has zero parameters, and the schema covers all of them vacuously. Per the baseline for zero-parameter tools, the description need not add parameter-level detail; there is nothing for it to explain.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Detecta') and a specific resource ('CTs excessivamente curtos, genericos ou copiados'), clearly pointing to identifying problematic test cases. It does not, however, expand the acronym 'CTs' or explicitly contrast with sibling tools like aya_testes_listar, so it is clear but not fully differentiating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as aya_testes_listar or aya_regras_detectar_genericas. The description implies a detection use case but provides no context about selection criteria or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds some behavioral context beyond the annotations by stating the tool optimizes for a minimal set and reduces token load. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, efficient sentence that front-loads the verb and core purpose. Every phrase earns its place; no filler or redundancy.
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?
For a one-parameter recommendation tool this is nearly adequate, but gaps remain: the input format of 'consulta' is unspecified and, with no output schema, the description does not state what the suggested toolset set looks like in the response. The core behavior is clear enough for basic use.
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 0%, so the description carries the burden of explaining the 'consulta' parameter, and it never mentions it. The parameter name is mildly self-explanatory, but the description does not clarify what form the query should take (e.g., a natural-language task description) or how it maps to toolset selection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Sugere' / suggests), a clear resource (toolsets), and a distinctive objective: the minimum toolset set for a task while reducing schemas/tokens. This differentiates it conceptually from sibling 'listar' tools like aya_toolsets_listar, though it never names a sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is implied ('para uma tarefa', aiming to reduce tokens/schemas) but there is no explicit when-to-use vs. when-not-to-use guidance, nor any mention of alternatives such as aya_toolsets_listar or aya_mcps_recomendar_capacidade. An agent can infer the purpose but must guess about trade-offs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 does disclose meaningful behavioral traits: the gate is executed without relying on the LLM and the tool returns a universal checklist for gates lacking automatic proof. However, it does not mention side effects, whether the operation is read-only, or what exactly the checklist contains.
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 entire description is one compact sentence with no filler or repetition. It front-loads the action, then adds the key qualifier and expected output in an efficient order.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description is the only source of operational detail, but it fails to explain the checklist's format, prerequisites, or how this tool fits into the larger validation workflow. The sibling list contains several overlapping tools, and the description does not resolve that ambiguity or describe expected result structure.
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?
The input schema is empty with zero parameters and 100% schema description coverage, so there are no parameter semantics for the description to explain. The baseline for zero-parameter tools is 4, and the description adds no misleading information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Executa gate estrutural de game') and a non-LLM, deterministic qualifier ('sem depender da LLM'), which distinguishes it from LLM-based validations. It also names the output ('checklist universal'), so an agent understands the tool's core function. However, it does not explicitly differentiate from siblings like aya_games_checklist or aya_validacao_gates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (structural game gates, no LLM dependency) but gives no explicit guidance on when to choose this tool over alternative validation/gate siblings. With many similar tools in the sibling list, an agent could easily pick the wrong one without more direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and only states the basic clearing behavior. It does not disclose whether the counter reset is irreversible, whether evidence is validated before clearing, what happens if the falha does not exist, or any side effects.
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?
One short sentence with no filler; the action and the precondition are both present and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool mutates state, has one undocumented required parameter, and no output schema or annotations, yet the description adds no detail about the parameter or the consequences of clearing. It is not complete enough for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description never mentions 'assinatura', the single required parameter. An agent has no way to know what signature format is expected or how to obtain it.
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 names a specific action ('Limpa o contador'), a precise resource ('de uma falha'), and a condition ('depois de evidencia real de correcao'). This clearly differentiates it from the sibling aya_loop_falha_registrar, which registers rather than clears a failure.
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?
It provides explicit context for use: only after real evidence of correction. It does not name the alternative aya_loop_falha_registrar or state explicit exclusions, so it misses the full when/when-not/alternatives set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this is non-read-only, non-destructive, and idempotent. The description adds modest context by noting observations are 'atomicas' and by requiring an existing entity, which hints at failure cases and data-shape expectations, but it doesn't explain duplicate handling, return behavior, or side effects beyond adding observations.
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, front-loaded, information-dense sentence with no filler or repetition. Every word contributes meaning, making it easy for an agent to parse quickly.
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?
For a simple two-parameter mutation with useful annotations, the description is minimally adequate. Gaps remain: it doesn't state what happens when the entity is missing, whether duplicate observations are ignored, or what the tool returns, and no output schema is provided to fill those gaps.
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 0%, so the description should compensate for unclear parameters. It vaguely maps 'id' to an existing entity and 'observacoes' to atomic observations, but it doesn't explain id format, observation content guidelines, or relationship to other graph operations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Acrescenta') and a clear resource ('observacoes atomicas a uma entidade existente'), so an agent can tell it adds atomic observations to an existing graph entity. It doesn't explicitly contrast with siblings like upsert, relacionar, or remover, but the intended action is still distinct and understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'a uma entidade existente' implies a prerequisite: the target entity must already exist, so this tool is for enriching existing entities rather than creating them. However, it doesn't explicitly say when to prefer this over sibling operations like upsert or relacionar, leaving usage routing mostly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal readOnlyHint=false, destructiveHint=false, and idempotentHint=true, so the description correctly aligns with an upsert write operation. The description adds useful behavioral context beyond the annotations by mentioning 'observacoes atomicas' and 'sanitizacao de segredos', which indicates how observations are handled. No contradiction with the annotations is present.
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 one concise, front-loaded sentence with no filler words. It communicates the action and two important behavioral characteristics efficiently. It is slightly too terse to fully support correct invocation, but as a description it is well-sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameter descriptions, no output schema, and many sibling memory-graph tools, this single sentence is not enough for reliable invocation. It does not explain what id and tipo should be, how the graph entity is interpreted, or how it differs from adjacent tools like grafo_observar, grafo_relacionar, or memoria_atualizar_estado. The annotations cover safety and idempotency, but not selection or invocation details.
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 0%, so the description carries the full burden for explaining parameters. It adds only partial meaning for 'observacoes' via the phrases 'observacoes atomicas' and 'sanitizacao de segredos', but id and tipo are completely unexplained despite being required. An agent cannot determine what values id or tipo should take from the description or schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Cria/atualiza') and a clear resource ('entidade de memoria'), so an agent can tell this is an upsert operation. It adds meaningful qualifiers about atomic observations and secret sanitization, which helps separate it from read/query siblings like aya_memoria_grafo_ler or buscar. It does not explicitly name a sibling alternative, but the core purpose is clear and non-tautological.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when creating or updating a memory entity with observations. However, it gives no explicit guidance about when NOT to use it or which sibling memory-graph tools should be preferred for related operations. With many sibling tools such as grafo_observar, grafo_relacionar, and grafo_remover, clearer routing would have been valuable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the only source of behavioral disclosure. It states only that the tool detects problematic RNs; it does not say whether the operation is read-only, what scope it scans, whether it has side effects, or what the response looks like. This is a meaningful gap for a zero-parameter analysis tool.
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, directly front-loaded sentence with no filler: it opens with the verb and immediately gives the object. This is appropriate for the simple, parameterless interface and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description needs to explain what the tool scans, what it returns, and how it compares to related tools like aya_regas_detectar_duplacadas or aya_testes_detectar_genéricos. None of that is present. The zero-parameter interface makes invocation easy, but selection and interpretation of results remain under-specified.
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?
The tool has zero parameters and the schema description coverage is 100%, so the schema fully handles arguments. There is nothing for the description to add about parameters, matching the baseline for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Detecta') and a specific object ('RNs excessivament cortas, genericas ou copiadas'), making it clear the tool finds short, generic, or copied business rules. However, 'RNs' is left unexplained and the description does not explicitly differentiate it from the sibling aya_regas_detectar_duplacadas, with which there is some overlap.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied: call this when you need to detect problematic business rules in the project. There is no explicit guidance about when not to use it or which alternative tools to choose, so the agent has to infer context from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden and does add value by revealing that the tool avoids opening/copying all templates and instead searches candidates efficiently. It also discloses the priority order between the external template and the Agents library, which is useful behavioral context beyond the schema.
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?
A single dense sentence that front-loads the primary action and includes the key behavioral distinction without wasted words. It is concise, focused, and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the strategy but omits important operational details: what the tool returns, how consulta and limite affect execution, and what the agent should do with the candidates found. With no output schema and no annotations, this leaves significant gaps for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the consulta or limite parameters at all. The description fails to compensate for the lack of parameter documentation, leaving the agent to infer what consulta means and how limite affects behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool applies a template-first strategy, prioritizing an external #Template and falling back to searching the Agents library. It is specific about the resource and action, though it does not explicitly differentiate itself from sibling tools by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: use this when you need to plan by applying template-first logic. However, it does not explicitly state when to prefer this over related tools like aya_templates_listar or aya_agentes_planejar_equipe, nor does it provide exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does a solid job: it discloses that it blocks specific paths, validates UTF-8, requires write mode, creates backups, uses an optimistic hash, writes, and logs/audits. It omits failure handling and conflict resolution details, but the declared behaviors are substantial and specific.
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?
A single dense sentence packs several important behaviors without fluff. It is front-loaded with the core purpose (controlled writing) and sequentially lists safety measures, making it efficient and scannable.
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?
The description covers the main operations and safety features, but lacks details on failure modes (e.g., what happens on hash mismatch or invalid UTF-8), expected return/errors, and how it should be selected over sibling tools like aya_arquivo_substituir_literal. Given the absence of output schema and annotations, these gaps leave the agent with partial guidance.
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 0%, so the description must compensate. It explains the purpose of hashEsperado via 'uses optimistic hash' and hints at write-mode requirements, but it does not clarify the semantics of 'modelo' (model) or 'motivo' (reason) parameters. Caminho and conteudo are self-explanatory from their names, but the obscure optional parameters remain underdocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool performs controlled textual file writing, listing specific safety behaviors (blocks vendor/.git, validates UTF-8, creates backups, optimistic hash, logs). This distinguishes it from generic write tools, though it does not explicitly name a sibling alternative, so it stops short of a clear differentiator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by listing preconditions like 'requires write mode' and path restrictions (blocks vendor/.git), hinting at safe write scenarios. However, it never states when not to use this tool or points to alternatives such as aya_arquivo_substituir_literal, leaving routing to the agent's inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral disclosure burden. It does reveal a key safety behavior—no content is sent—and indicates that only size and hash are gathered, which is useful. However, it does not state whether the operation is read-only, what it returns, whether it scans subfolders, or whether any local state is modified.
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 focused sentence that front-loads the action, resource, computed fields, and a critical exclusion. It contains no filler and every phrase contributes information.
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?
For a simple one-parameter metadata inventory tool, this is minimally viable: it states what is inventoried, what is computed, and that content is not sent. But without an output schema or annotations, it could be more complete by describing the parameter, the return format or location of results, and whether the operation is safe and read-only.
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 0%, so the description needed to explain the 'pasta' parameter, but it only mentions '#Documentos', which is the default value. The role of 'pasta' as the target folder to inventory is implied by its name and default, but not explicitly described, leaving an agent without clear parameter semantics.
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 uses a specific verb ('Inventaria'), names the resource ('#Documentos'), and specifies what is computed ('tamanho e hash') while explicitly stating what it does not do ('sem enviar conteudo'). This clearly distinguishes it from sibling inventory tools like aya_framework_inventariar and aya_games_assets_inventariar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives, nor does it state exclusions or preconditions. The phrase 'sem enviar conteudo' implies a safe metadata-only use case, but this is not developed into actionable selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Não há annotations, então a descrição carrega o peso de explicar o comportamento. Ela acrescenta duas informações além do schema: a restrição de raiz autorizada e a exigência de caminho explícito para bibliotecas pesadas. No entanto, não informa o que acontece com arquivos inexistentes, permissões negadas, encoding, nem o efeito real de limiteBytes.
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?
A descrição é curta e direta, com a ação principal logo no início e sem palavras desnecessárias. A segunda frase é relevante, mas levemente ambígua ('Bibliotecas pesadas exigem escolha explícita do caminho'), o que impede a nota máxima.
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?
Para uma ferramenta simples de leitura, a descrição cobre o essencial: o que é lido e dentro de qual escopo. Contudo, não há output schema e a descrição não explica o formato de retorno, comportamento em erros, limites de tamanho ou o papel do parâmetro opcional, deixando lacunas relevantes para o agente.
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?
A descrição agrega significado ao parâmetro 'caminho': deve ser um arquivo específico dentro da raiz autorizada e, para bibliotecas pesadas, a escolha do caminho precisa ser explícita. Porém, não menciona 'limiteBytes', deixando esse parâmetro sem explicação descritiva além do que o nome e as restrições do schema permitem inferir.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
A descrição usa verbo específico ('Le'), recurso claro ('um arquivo específico do framework') e informa o escopo ('dentro da raiz autorizada'), o que deixa evidente a operação de leitura. Não diferencia explicitamente de alternativas como aya_framework_buscar_conteudo, mas a finalidade é clara e não é tautológica.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
A descrição define o contexto de uso: ler um arquivo específico do framework na raiz autorizada, e acrescenta uma condição relevante para bibliotecas pesadas (caminho explícito). Porém, não diz quando não usar a ferramenta nem compara com alternativas de leitura/busca entre os irmãos listados.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. It usefully reveals that templates/examples/vendor require explicit permission because they are heavy, which signals the role of the 'permitirPesado' parameter. However, it does not clarify side effects, return behavior, or what 'carregar' means in terms of state changes.
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?
Two short sentences with no filler. The main action is front-loaded and the warning about heavy components directly follows, making the structure efficient and easy to scan.
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?
The description covers the core purpose and the main constraint, but lacks output format, return behavior, and usage context relative to sibling pack tools. With no output schema and no annotations, those gaps matter more than for an annotation-rich 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 description coverege is 0%, so the description must compensate. It maps all three important ideas: 'pack específico' suggests the id parameter, 'budget' suggests limiteChars, and 'permissão explícita' suggests permitirPesado. The mapping is semantically useful though not as precise as a schema-backed description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: it loads a specific pack with a budget. It identifies the resource ('pack específico') and adds the budget concept, but it does not explicitly distinguish itself from sibling tools like aya_framework_packs_selecionar or aya_framework_packs_listar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The sentence implies loading a pack, but it does not mention prerequisites, exclusions, or relations to sibling tools that also deal with packs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It says the tool 'selects' packs but does not state whether this is read-only, whether it persists or locks anything, or what the return value looks like. This is a significant gap for an unannotated tool.
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 front-loaded sentence with no filler. Every word adds meaning, and it is appropriately sized for a tool with one parameter and a straightforward selection behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations, no output schema, and no parameter coverage, the description is too thin. It does not explain expected output, side effects, or how 'consulta' should be constructed, leaving an agent without enough information to invoke the tool confidently beyond guessing.
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?
The single parameter 'consulta' has 0% schema coverage. The description hints that the query relates to task triggers, but it does not explain the expected format, content, or examples. It adds some meaning beyond the bare schema, but not enough to fully compensate for the lack of parameter documentation.
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 states a specific verb ('seleciona') and resource ('packs Agents') with a mechanism ('por gatilhos da tarefa'). It naturally distinguishes itself from siblings like aya_framework_packs_listar (listing) and aya_framework_pack_montar (assembling), so an agent can tell it apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'por gatilhos da tarefa' implies the tool is for automatic selection based on task triggers, but there is no explicit when-to-use guidance or contrast with sibling tools. Usage context is only implied, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. 'Sem tocar em vendor' hints at a non-destructive scope, but the description never states whether validation is read-only, whether it modifies files, requires write access, or what it returns on pass/fail.
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?
A single efficient sentence with zero waste: it front-loads the verb and target, then narrows scope with the vendor exclusion. Nothing is redundant with the schema.
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?
For a zero-parameter validation tool the description conveys the core scope adequately. But with no output schema and no annotations, an agent is left guessing about the return format (e.g., pass/fail boolean, report of violations, exit code), which is relevant for a validation gate.
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?
The tool takes zero parameters, so there are no parameter semantics to convey and the schema coverage is trivially complete. Per calibration, 0 params earns the baseline 4 — the description has nothing to add here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Valida'), resource ('frontmatter/H1 das skills autorais na raiz .skills/') and scope ('sem tocar em vendor'). This clearly differentiates from search-type siblings like aya_framework_skills_buscar, though it doesn't name the sibling explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on what it covers (root .skills/, excluding vendor), which implies when it applies. However, it doesn't explicitly exclude alternatives like aya_framework_integridade_validar or aya_validacao_gates, nor state when a different validation tool should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the behavioral burden. 'Retorna' makes clear this is a read-only operation, and 'universais' suggests a stable/fixed list. However, the description does not disclose potential side effects, whether the list varies by project context, or what the output format looks like.
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, front-loaded sentence with no filler. Every word adds information about what the tool returns and for which domains.
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?
For a zero-parameter query with no output schema, the description is sufficient to invoke the tool, but it leaves important context unclear: the precise nature of the 'gates', the structure of the returned checklist, and how this relates to generic validation gates. An agent may need additional probing to fully interpret the result.
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?
The input schema has zero properties, so there are no parameters to explain. Per the baseline for zero-parameter tools, a score of 4 is appropriate; the description does not need to add parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'returns AYA's universal gates' for game development domains, with a specific verb and resource. The listed categories (architecture, assets, input, savegame, performance, network, QA, distribution) make the scope concrete. However, it does not explicitly differentiate itself from sibling tools like aya_validacao_gates, and the term 'gate' is used without definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives such as aya_games_validar or aya_validacao_gates. The description only states what the tool returns, leaving the choice entirely implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description's 'reads' aligns with that. It adds the resource (persistent graph) but nothing further about behavior, such as whether the graph is guaranteed to exist or how it is returned.
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?
One concise sentence in Portuguese, front-loaded with the core action and resource. No wasted words.
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?
For a zero-parameter read operation with annotations covering safety, the description is adequate but incomplete: it lacks any differentiation from similarly named graph tools and says nothing about the return value (no output schema). More context would help the agent decide between 'ler' and 'abrir'.
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?
The tool has zero parameters, and schema description coverage is 100%, so the baseline of 4 applies. The description adds no param explanation because none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it reads the project's persistent graph, providing a specific verb and resource. However, it does not differentiate from sibling tools like aya_memoria_grafo_abrir or aya_memoria_grafo_buscar, leaving the agent uncertain which read-like tool to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus named alternatives. With several graph-related siblings (abrir, buscar, upsert), the absence of any context for selection is a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
As anotações já informam que não é somente leitura, não é destrutiva e é idempotente. A descrição acrescenta que a relação é dirigida e que as entidades devem existir, o que é útil. Porém, não detalha o comportamento em caso de relação já existente, falha por entidade inexistente ou efeito de chamadas repetidas, embora a anotação de idempotência cubra parcialmente isso.
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?
Uma única frase direta e sem redundância. A informação essencial — criar relação dirigida entre entidades existentes — é apresentada primeiro e não há palavras ou cláusulas desnecessárias.
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?
A operação é simples e as anotações cobrem aspectos importantes como idempotência e não-destrutividade. No entanto, a descrição não define o significado dos três parâmetros obrigatórios nem apresenta possíveis tipos de relação. Para um agente que precisa invocar corretamente, falta um pouco mais de contexto semântico sobre os argumentos.
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?
A cobertura do schema é 0% e a descrição não explica os parâmetros 'de', 'para' e 'tipo'. Os nomes são sugestivos (origem, destino, tipo da relação), mas não há definição formal, valores aceitos ou distinção entre eles; a descrição não compensa a ausência de documentação no 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?
A descrição é específica: verbo 'cria', recurso 'relação dirigida entre duas entidades existentes'. Isso a distingue claramente das ferramentas irmãs de grafo, como upsert (criar/atualizar entidade), remover, ler e buscar, ao estabelecer que a operação é exclusivamente sobre relacionamentos direcionados entre entidades já presentes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Não há nenhuma orientação sobre quando usar esta ferramenta versus alternativas como aya_memoria_grafo_upsert, aya_memoria_grafo_observar ou aya_memoria_grafo_remover. Também não há condições, pré-requisitos ou exclusões explícitas; o contexto de uso precisa ser inferido pelo nome e pela breve descrição.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the burden of explaining behavior, and it does disclose meaningful traits: enforcing micro-steps, file limits, budget, and blocking after two equal failures. It does not mention persistence or return behavior, but the core behavioral consequences are clearly stated.
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 sentence with a front-loaded action and a colon-separated list of specifics. It is concise and free of filler, though the slash-joined 'fraca/media/forte' is slightly compact.
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?
For a one-parameter tool with no output schema, the description provides a workable mental model of what applying the profile does. However, it does not clarify what the tool returns, whether it persists state, or what happens when 'nivel' is 'desconhecido'.
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 0%, so the description must compensate for the single 'nivel' parameter. It maps the enum values roughly to weak/medium/strong discipline and gives behavioral meaning, but it omits the fourth possible value 'desconhecido' and does not explain how each level changes the discipline details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Aplica disciplina de LLM') and names the resource and concrete constraints (micro-steps, file limit, budget, blocking after two identical failures), so an agent can identify it as an execution-profile enforcement tool. It does not explicitly contrast itself with a sibling tool, but its function is reasonably distinct among the listed siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus an alternative, and no prerequisites or exclusions are mentioned. The only usage context is implied by the action description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the one-line description carries the full behavioral burden. It does not state the return format, whether the graph is modified, or how cycle detection relates to task dependency validation.
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?
A single, front-loaded sentence with no filler or redundancy. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no annotations, the description omits the result shape and side-effect profile. An agent must infer what 'detect cycles' returns and whether the operation is read-only.
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?
The input schema is empty and there are zero parameters, matching the 0-parameter baseline of 4. Nothing further is needed to clarify input semantics.
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 names a specific verb ('Detecta') and a concrete resource ('ciclos no grafo de tarefas'), which clearly differentiates it from task-management siblings like aya_tarefas_listar, aya_tarefas_validar_dependencias, and aya_tarefas_proxima. Even without a title, the agent knows the operation is a task-graph cycle analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives or what preconditions apply. The description neither names sibling tools nor notes typical usage contexts such as running before dependency validation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the useful fact that data comes from persistent memory and that the tool returns the current agent/task, which goes slightly beyond the tool name. However, with no annotations present, the description carries the full burden and does not mention read-only behavior, missing-data behavior, or possible side effects.
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 entire description is a single, front-loaded, information-dense sentence. Every word contributes to explaining what the tool does and where it reads from, with no 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?
For a simple parameterless getter, the description is mostly sufficient: it names the source and the object returned. It does not describe the output shape or what happens when no current agent/task exists, but this is a minor gap given the tool's simplicity.
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?
The tool has zero parameters, so the schema is already complete and there is nothing for the description to clarify. This matches the baseline of 4 for parameterless tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving ('Retorna') the current agent/task from persistent memory. It names a specific resource and gives a concrete action, though it does not explicitly distinguish itself from related siblings such as aya_memoria_obter_contexto_retomada or aya_agentes_adquirir_lock.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool instead of the many related memory, agent, or checkpoint tools. No conditions, exclusions, or alternative recommendations are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint and idempotentHint annotations, the description discloses a meaningful behavioral trait: the tool avoids loading the entire file into context, which has resource/performance implications. The statement that it does not replace LSP also sets appropriate expectations about scope. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short, front-loaded sentences with zero filler. Every phrase adds value: 'outline leve', 'sem carregar o arquivo inteiro no contexto', and 'Nao substitui LSP' all convey distinct and useful information.
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?
For a simple one-parameter, read-only tool, the description covers the core purpose and an important limitation. However, with no output schema and no mention of what the outline contains or which file types are supported, an agent still faces ambiguity about the exact return value and applicability.
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 0% and the description does not explain the 'caminho' parameter at all. The word 'arquivo' hints that it refers to a source file path, but the description fails to compensate for the missing schema semantics, leaving the agent to infer the expected path type or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('extrai outline leve de simbolos') and the resource (symbols in a file), and it adds the meaningful constraint of not loading the full file into context. However, it does not differentiate from sibling code tools such as aya_codigo_referencias or aya_codigo_editar_linhas, aside from an external LSP comparison.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when a lightweight symbol outline is needed without pulling the entire file into context. It explicitly notes that it does not replace LSP, which is a useful exclusion, but it does not name any sibling tool as an alternative or provide explicit when-not-to-use guidance beyond the LSP caveat.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden — and it only partially delivers. It discloses the core checks but leaves mutation ambiguity ('Recalcula' could mean it rewrites the manifest or merely compares hashes), does not state prerequisites (must INTEGRITY_MANIFEST exist?), and does not describe failure behavior or side effects.
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?
A single sentence with zero filler: the action (recalculate SHA-256) is front-loaded and the detection outcomes follow immediately. Every clause carries information; no wasted words.
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?
For a parameterless tool, the intent is largely captured, but with no output schema and no annotations, the agent cannot infer the result format (report? boolean? exit code?) nor whether the manifest gets updated. The mutation ambiguity and missing return contract are the main gaps.
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?
The input schema has zero parameters, so per baseline there is nothing the description must compensate for. Schema coverage is vacuously 100% and no parameter semantics are needed.
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 uses specific verbs ('Recalcula SHA-256', 'detecta') tied to a named resource (INTEGRITY_MANIFEST) and enumerates exact detection outcomes (arquivos ausentes, alterados ou nao manifestados). This level of specificity distinguishes it from similar siblings like aya_framework_drift_validar or aya_templates_validar_hash without needing to open any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to invoke this tool, when not to, or which alternative to prefer. Given ~80 siblings with overlapping validation semantics (drift_validar, workspace_auditar, governanca__auditar, mirrors_validar), an agent has no signal to choose between them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It does disclose a meaningful behavioral trait: it lists knowledge families without exposing proprietary content, implying redaction or abstraction. However, it does not state whether the operation is read-only, what the output structure looks like, or any side effects.
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?
A single concise sentence that states the action, the resource, and a key constraint without any filler or redundancy. Every word contributes meaning.
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?
For a parameterless listing tool without an output schema, the description is nearly complete: it names what is listed and the redaction boundary. The main gaps are the ambiguity of 'Agents' and the absence of any indication of the return format or how the listed families relate to sibling framework tools.
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?
The tool has zero parameters, so the baseline is 4. There is no parameter semantics burden on the description, and no contradictions or missing parameter explanations exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Lista') and names the resource ('famílias de conhecimento aproveitadas do Agents'), plus a differentiator ('sem expor o conteúdo proprietário'). It is clear enough as a listing operation, though the meaning of 'Agents' and 'famílias de conhecimento' is somewhat domain-specific and not fully disambiguated from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus alternatives like aya_framework_packs_selecionar, aya_framework_inventariar, or aya_framework_buscar_conteudo. The description implies a high-level listing use case but never states exclusions or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds a meaningful semantic warning: 'Registry nao implica confianca.' This clarifies that a registry entry is not an endorsement, which is useful behavioral context beyond the structured hints. No contradiction with annotations exists.
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 definition is two short sentences with no filler. The first sentence front-loads the core action and classification scheme, and the second sentence earns its place by adding an important semantic caveat about trust.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, yet the description does not say what the tool returns or how the A/B/C/D classification is represented. It also does not describe the relevance of the input parameters. Given the tool has 4 parameters and no output schema, the description is too sparse for an agent to invoke it confidently without additional assumptions.
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 does not explain any of the four parameters. Schema coverage is effectively zero for parameter descriptions: 'nome' is required but its format is unspecified, and the boolean flags 'aya', 'referencia_mcp', and 'publisher_verificado' are not linked to the A/B/C/D policy criteria. The description leaves parameter semantics almost entirely to the agent's inference.
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 uses a specific verb ('Classifica'), a clear resource ('MCP'), and a concrete classification scheme ('por politica A/B/C/D'). It is distinct from sibling tools like listar_permitidos, catalogo_referencia, and recomendar_capacidade, which clearly involve listing, cataloging, and recommending rather than classifying.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is given. The description does not state when to use this tool versus the sibling MCP tools, nor does it mention any exclusions or conditions such as 'use listar_permitidos when...' or 'use recomendar_capacidade for capabilities.' The intended selection context is left entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It clearly indicates a read operation via 'Le', which implies non-destructive behavior, but it does not disclose authentication requirements, error conditions, or what happens when the project is not authorized.
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 concise sentence that communicates the essential action and resource without redundancy. It is appropriately sized for a zero-parameter tool.
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?
For a zero-parameter read tool, the description is largely complete: it names the source data and implies the identity-obtaining purpose. It does not explicitly state the return value or intended use case, but the low complexity and absence of parameters make this a minor gap.
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?
The input schema has zero parameters, so the baseline is 4. The description doesn't need to explain parameter meanings, and it adds useful context by naming the concrete resources being read.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Le') and resource ('manifesto e CONFIG do projeto autorizado'), making the tool's purpose clear. It does not explicitly distinguish it from sibling read-oriented tools, but the name and described scope are sufficient for basic orientation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance about when to use this tool versus alternatives such as aya_framework_arquivo_ler or aya_projeto_calcular_hash. It does not mention exclusions, prerequisites, or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden, and it does so meaningfully: it discloses the acceptance rule, explicit rejection cases, and the mojibake-signaling behavior. It does not state the exact return shape or whether rejection is an exception versus a result, but the core behavioral contract is clear.
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 one short, front-loaded sentence that packs the essential validation rules into every word. There is no padding, repetition, or irrelevant context.
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?
For a single-parameter validation tool with no output schema, the core purpose and rules are present. However, the agent is left without information about what a rejection or success looks like (boolean, error, report), and there is no usage or alternative guidance. The description is workable but not fully complete.
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 0%, and the description never mentions the 'caminho' parameter. The parameter name and tool name imply it is a file path, but the description adds no concrete meaning about path format, file existence, or whether the path must point to a file versus content.
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 states a specific verb and resource: it validates a file encoding. It is precise about the acceptance criterion (UTF-8 without BOM), rejection criteria (UTF-16 and U+FFFD), and an additional outcome (flagging possible mojibake). This clearly distinguishes it from the many other validation tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives, nor are any prerequisites or exclusions mentioned. The intended use can be inferred from the verb 'Valida', but an agent gets no explicit help choosing among the many validation-oriented siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 of behavioral disclosure. It usefully reveals that the tool does not open the entire pack, but it does not state read-only status, whether 'pesadas' are excluded by default, or what happens when no skills match.
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 front-loaded sentence with no filler: verb, target, criteria, and key constraint are all present. Every clause contributes actionable information.
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?
The core search behavior is clear, but with no output schema and no annotations, the agent still has to guess the return shape, the semantics of the optional parameters, and how this tool differs from content-oriented siblings. It is minimally adequate for a simple search tool, but not fully complete.
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?
With 0% schema description coverage, the description needed to explain consulta, limite, and incluirPesadas, but only weakly implies that consulta is the search query. It never clarifies what 'pesadas' means or how incluirPesadas changes the search, leaving a material gap.
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 names a specific verb ('Busca' = searches), a resource ('skills relevantes'), and explicit search criteria ('por metadados, gatilhos e caminho'). The closing phrase 'sem abrir todo o pack' distinguishes it from heavier pack-level tools, so an agent can tell it apart from siblings like aya_framework_pack_montar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the right moment to use it: a lightweight search over skill metadata when you want to avoid opening the whole pack. It does not name alternatives such as aya_framework_buscar_conteudo or state when not to use it, so the routing guidance is inferred rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds a useful behavioral guarantee by stating the operation does not copy or alter the template. However, it does not clarify whether freezing persists any state, whether it is reversible, or what side effects occur beyond that guarantee.
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?
Two short sentences with no filler: the first states the core action, the second eliminates ambiguity about copy/alter behavior. Every word earns its place.
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?
This is a simple tool with three string parameters and no output schema, so the description covers the essential selection context and a key behavioral exclusion. Still, it omits what happens on success, what the response contains, and whether the freeze is persistent, leaving moderate gaps for an agent.
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 0%, so the description should compensate by explaining the parameters. It only refers to the 'template selecionado' without defining how 'pasta', 'categoria', and 'nome' select the template, their expected formats, or their relationship to each other.
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 names a specific verb ('Congela') and resource ('metadados/hash do template selecionado'), and explicitly clarifies what it does not do ('Nao copia nem altera o template'). This makes it clearly distinguishable from sibling tools like aya_templates_listar and aya_templates_validar_hash.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the use case: freeze the metadata/hash of a selected template without copying or altering it. However, it never explicitly states when to choose this tool over alternatives or names any sibling, so the guidance remains implicit rather than directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, and the description's explanatory verb aligns with those. The description adds that the tool compares specific semantic-layer approaches, which is useful context. It does not disclose what kind of response to expect (e.g., prose guidance, decision matrix, or plan), but for a zero-parameter informational tool this is 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, immediately naming the subject and the alternatives being compared. It is front-loaded and earns its place.
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?
For a read-only, zero-parameter explanatory tool, the description provides enough context: the decision it supports and the specific alternatives involved. The main missing piece is an indication of the output format, since there is no output schema, but this is not critical for such a simple advisory 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?
The tool has no parameters and schema description coverage is 100%, so there is nothing for the description to add about parameter meaning. Per the baseline for zero-parameter tools, this dimension is well satisfied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific explanatory purpose: it explains when to use a lightweight native semantic layer versus LSP/Serena/mcp-language-server for full semantics. This clearly distinguishes it from the many code and memory sibling tools. It could be stronger by explicitly saying it produces a plan or recommendation, but the resource and scope are clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context about the decision being supported and names the relevant alternatives, so an agent can infer when this advisory tool is useful. However, it does not explicitly say when to invoke this tool versus other planning or MCP-classification tools, nor does it state any exclusions or ordering prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, so the safety profile is covered. The description adds behavioral clarity by stating the tool does not install anything, which is valuable non-obvious behavior. It does not describe output format or detail, but for a zero-parameter read-only catalog tool, this is a reasonable level of transparency.
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?
Two short sentences in Portuguese convey the scope, the reference to v0.2, and the critical non-installation behavior with zero filler. It is appropriately front-loaded: the main action comes first, and the exclusionary note immediately follows.
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?
For a zero-parameter read-only listing tool with annotations that establish safety and idempotence, the description is largely complete. It clearly names the content domain (researched MCPs and patterns) and the non-installation guarantee. The only minor gap is that it does not mention what the returned list will contain structurally, but with no output schema and a simple catalog purpose, this is not a serious omission.
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?
The tool has zero parameters, so there is no schema burden to compensate for. The description could not add parameter-level meaning; a baseline 4 is appropriate. The text clarifies the subject ('MCPs abertos pesquisados' and 'padroes') without needing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb-resource pair and scope: it lists open researched MCPs and the patterns that inspire/integrate v0.2. It also distinguishes itself from sibling tools by clarifying it installs nothing. It is not a tautology and an agent can tell it apart from sibling MCP tools like aya_mcps_classificar or aya_mcps_listar_permitidos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for browsing/inspecting MCP research and patterns, and explicitly says it does not install anything, which is useful exclusionary guidance. However, it does not provide explicit when-to-use versus alternatives, such as when to prefer aya_mcps_listar_permitidos or aya_mcps_recomendar_capacidade.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and idempotentHint=true, and the description reinforces this by stating 'sem instalar ou conceder permissoes,' which adds useful context about the tool's non-destructive nature. However, it does not describe the return format, the source of recommendations, or any other runtime behavior, so behavioral transparency is only partially addressed.
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 efficient sentence with no filler. It front-loads the main action and immediately adds a relevant safety qualifier, making it easy to scan and understand.
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?
For a simple one-parameter, read-only tool, the description provides a clear purpose and safety profile. However, with no output schema and no mention of what the recommendation response looks like, the agent may not know what to expect from the call, and it does not provide guidance on how this tool fits with the sibling MCP tools.
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?
The input schema only defines 'consulta' as a string with no description, so the description's reference to 'capacidade solicitada' clarifies that the query parameter should contain a requested capability. This adds meaning beyond the schema, but it remains minimal and does not provide examples, expected phrasing, or format guidance.
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 uses a specific verb ('Recomenda'), a clear resource ('MCPs'), and a scope ('pesquisados por capacidade solicitada'), making the tool's function immediately understandable. It also distinguishes itself from sibling MCP tools by emphasizing recommendation rather than classification, listing, or cataloging, and by stating it does not install or grant permissions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'pesquisados por capacidade solicitada' implies the tool should be used when a capability-based MCP recommendation is needed. However, it does not explicitly mention alternatives or exclusions among the sibling MCP tools, leaving the agent to infer when to pick this tool over aya_mcps_classificar, aya_mcps_listar_permitidos, or aya_mcps_catalogo_referencia.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotaions already mark destructiveHint=true, but the description adds valuable context by stating that the operation also removes the entity's relationships, not just the entity itself. This clarifies the blast radius beyond what the annotations provide and does not contradict readOnlyHint=false or idempotentHint=true.
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?
A single sentence with zero filler: it states the operation and its scope in a frontloaded way. Every word adds value and the description does not repeat the tool name or schema data.
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?
For a one-parameter deletion tool with destructive and idempotent hints already provided by annotations, the description covers the essential effect: removing the entity and its relationships. It lacks usage guidance and explicit id semantics, but the core context needed to invoke the operation is present.
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 schema has one required 'id' parameter with zero description coverage, and the description does not clarify what 'id' refers to, its format, or its significance beyond naming the entity. The agent can guess that 'id' identifies the entity from context, but the description itself adds almost no parameter semantics.
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 is precise: it names a specific verb ('Remove') and an explicit resource ('entidade e suas relacoes'), distinguishing this tool from sibling graph operations such as upsert, observar, and relacionar. The scope is immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool instead of nearby alternatives like aya_memoria_grafo_upsert or aya_memoria_grafo_relacionar. The agent must infer context from the tool name and sibling list rather than from an explicit recommendation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full behavioral disclosure burden. It does reveal a relevant behavioral property by specifying that the hash is 'deterministico', but it does not state whether the operation is read-only, what the expected return value is, or any failure conditions.
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, tightly written sentence with no filler. The key behavioral attribute 'deterministico' is placed immediately after the verb, making the core function easy to parse at a glance.
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?
For a simple one-parameter tool without an output schema, the description is minimally viable but leaves gaps: it does not clarify whether the tool validates an existing hash or simply computes one, nor does it distinguish its behavior from aya_projeto_calcular_hash explicitly. These ambiguities could lead to incorrect tool selection.
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?
The schema defines 'pasta' only as a non-empty string with 0% description coverage. The description adds essential meaning by clarifying that the parameter is a 'template folder', which helps disambiguate an otherwise generic parameter name.
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 uses the specific verb 'Calcula' and names a precise resource: 'hash deterministico de uma pasta de template'. This clearly states the tool's purpose and distinguishes it from related siblings like aya_projeto_calcular_hash, which operates on project scope rather than template folders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives, no preconditions, and no mention of the related project-hash tool. An agent must infer usage entirely from the function's stated purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Não há annotations, então a descrição precisa informar o comportamento. Ela revela que a varredura é determinística, inicial e superficial em relação a uma auditoria profunda, mas não esclarece efeitos colaterais, formato de saída, permissões necessárias ou se é apenas leitura. 'Varredura' sugere não-destrutividade, mas não é explícito.
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?
A descrição é curta, direta e economiza palavras. As informações essenciais aparecem primeiro (varredura inicial, categorias) e a ressalva sobre auditoria profunda é adicionada sem encher o texto.
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?
Para uma ferramenta sem parâmetros, a descrição cobre bem o escopo da varredura, mas não explica o que a ferramenta retorna, como o resultado é apresentado ou como o agente deve interpretá-lo. Como não há output schema, essa informação faria falta para uso correto.
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?
A ferramenta não possui parâmetros, então o baseline é 4. A descrição não precisa documentar entradas e não há lacunas causadas por parâmetros ausentes ou mal explicados.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
A descrição afirma claramente que a ferramenta executa uma 'varredura deterministica inicial' e enumera categorias concretas (segredos hardcoded, sinks perigosos, shell, TLS inseguro, CORS, lockfiles). O verbo/escopo é específico e o diferencia de uma auditoria profunda, embora 'derivada dos gates do Agents' seja um pouco vago.
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?
A frase 'Varredura deterministica inicial' indica quando usar a ferramenta (passo inicial de auditoria), e 'Nao substitui auditoria profunda' explicitamente exclui seu uso como auditoria completa. Porém, não nomeia alternativas concretas entre os muitos irmãos, deixando parte da orientação implícita.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and discloses two important side effects: it automatically creates a backup and a log, and it refuses to substitute unless the count matches exactly. It stops short of saying what happens on mismatch, where the backup/log are written, or whether the substitution is atomic, but the main safety behavior is clear.
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?
A single well-organized sentence front-loads the operation and guard, then states the automatic side effects. Every clause earns its place; there is no filler, repetition, or buried detail.
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?
For a 6-parameter mutation tool with no annotations, no output schema, and zero parameter descriptions, the description is adequate but not complete. It covers the core safety behavior, but an agent still does not know the mismatch behavior, the return/confirmation format, or the meaning of optional fields such as modelo and motivo.
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 0%, so the description must compensate. It adds meaning to the core parameters by connecting 'substitui texto' and 'contagem de ocorrencias' to procurar, substituir, and ocorrenciasEsperadas, but it leaves caminho, modelo, and motivo unexplained and does not clarify the 'literal' semantics of the search.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete operation — replacing text only when the occurrence count is exactly the expected one — and advertises automatic backup and logging, making it clear this is a guarded literal replacement on a file. It is specific enough to be distinguished from broader write/edit siblings by its guard, though it does not explicitly name an alternative or mention 'literal' in the prose.
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 phrase 'somente quando a contagem de ocorrencias e exatamente a esperada' gives the agent a concrete decision rule: use this tool when an exact expected occurrence count is known, because it will not substitute otherwise. It provides clear context, but it does not explicitly route to alternatives or say when to prefer a sibling like aya_arquivo_escrever_seguro.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the tool is known to be a safe, read-only operation. The description adds the key behavioral trait that it is 'lexical limited by identifier', which goes beyond annotations by clarifying the search is not semantic and is constrained to identifier-based lookup. This adds valuable context without contradicting the annotations.
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 extremely concise—two sentences, with the core capability front-loaded and the alternative direction in the second sentence. Every word earns its place, and the structure is optimal for quick scanning by an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two parameters, no output schema, and no nested objects, the description should at least explain the return format or the meaning of 'limite'. It does not mention what the search returns, how many results may come back, or any error scenarios. Given the existence of siblings like aya_codigo_outline and aya_codigo_semantico_planejar, an agent lacks critical context to decide if this tool meets its needs beyond the basic lexical search capabily.
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 0%, so the description must explain parameters. It hints that 'simbolo' is the identifier (via 'por identificador'), but does not explain the 'limite' parameter at all. The schema provides minimal field names and types but no descriptive text, leaving agents without clarity on how to set limits or what the output might look like. The description fails to compensate for the lack of schema documentation.
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 lexical search by identifier in code files, using a specific verb ('Busca') and resource ('identificador em arquivos de codigo'). It explicitly distinguishes itself from semantic alternatives by advising LSP/Serena for real semantics, which also separates it from sibling tools like aya_codigo_semantico_planejar. This is a precise and unambiguous purpose.
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 gives explicit guidance on when NOT to use this tool (for real semantics, prefer LSP/Serena) and implies it is for lexical searches by identifier. While it doesn't enumerate all alternative tools or edge cases, the clear directive about preferring a different approach for semantic needs provides solid usage orientation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It does add useful behavioral context beyond a bare statement — it reveals the optional hash-computation behavior and the duplicate-detection intent, and 'Inventaria' implies a non-destructive cataloging operation. However, it does not explicitly state whether the tool has side effects, what its output/return looks like, or what scope of assets it scans.
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?
A single, front-loaded sentence with zero filler. The main action and resource lead, the scope qualifier follows, and the optional capability closes the sentence. Every word contributes.
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?
The tool is simple (one optional boolean parameter), which lowers the burden, but with no output schema and no annotations the description should explain what the tool returns and what scope it covers. It does not state the return format, the asset source location, or define 'tipo/tamanho' concretely, leaving moderate gaps an agent must resolve elsewhere.
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 description coverage is 0%, so the description must compensate — and it does. 'Opcionalmente calcula hashes para detectar duplicados' directly explains the meaning of the sole parameter comHashes (set true to compute hashes for duplicate detection). Since there is only one parameter and the description maps to it clearly, it adds meaningful semantics beyond the bare boolean schema entry.
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 names a specific verb ('Inventaria'), a precise resource ('assets de game'), and the scope of the action ('por tipo/tamanho'), plus a secondary capability (hash calculation for duplicate detection). This clearly differentiates it from sibling inventory tools like aya_framework_inventariar and aya_documentos_inventariar, which target different resource domains.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: an agent would call this when it needs to catalog game assets by type/size or detect duplicates via hashes. However, there is no explicit guidance on when to prefer this over related siblings such as aya_games_detectar_engine, aya_games_validar, aya_regras_detectar_duplicadas, or aya_projeto_calcular_hash — no exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It clearly conveys a read-only detection operation, but it does not disclose whether the tool returns a list, a boolean, or a report, nor what happens when duplicates are or are not found.
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?
A single short sentence with no filler; the key scoping information ('em multiplos arquivos') is present and front-loaded.
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?
For a zero-parameter detection tool, the description provides enough to understand its basic purpose. However, since there is no output schema and no annotations, the missing return-value or result-format information leaves a notable gap for an agent deciding whether the output will satisfy its need.
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?
The tool has zero parameters, so the empty schema already fully documents the input contract. The description correctly adds no parameter information, and the zero-parameter baseline of 4 applies.
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 uses a specific verb ('Detecta') and a precise resource ('IDs RN definidos em multiplos arquivos'), making the tool's scope clear. It is distinguishable from siblings like aya_regras_detectar_genericas and aya_regras_listar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied rather than explicit: an agent can infer this tool is for finding RN IDs defined in more than one file. However, it does not name alternatives or state when not to use it, so explicit guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the selection criteria: incomplete status, completed dependencies, and 'first' ordering. It does not describe no-result behavior, the return format, or explicitly confirm this is a read-only suggestion, leaving some ambiguity.
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?
One concise sentence with no filler or redundant information. The core behavior is front-loaded and immediately understandable.
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?
For a simple zero-parameter tool, the description is mostly adequate, but it lacks edge-case guidance such as what happens when no eligible task exists or how 'first' is ordered. With no output schema or annotations, a bit more context would improve completeness.
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?
The tool has zero parameters, so the empty input schema fully covers parameter semantics. The description correctly avoids adding unnecessary parameter details. Baseline 4 is appropriate for a zero-parameter tool.
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 states a specific verb ('sugere') and a specific resource/selection rule: the first incomplete task whose dependencies are complete. This clearly differentiates it from sibling tools like aya_tarefas_listar and aya_tarefas_validar_dependencias.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied: an agent would use this when it needs to pick the next actionable task. However, it does not explicitly say when to prefer this over sibling task tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 behavioral burden. It does add one meaningful trait: detection is 'por evidencias reais do workspace', indicating real file inspection rather than declared config. However, it omits whether the operation is read-only, what happens when no engine is detected, and what the return payload looks like (single engine vs. ranked list, confidence, version).
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?
A single sentence with the verb and resource front-loaded, followed by a comma-separated engine enumeration. Every element earns its place; the engine list is high-value routing information and there is zero filler or repetition.
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?
For a zero-parameter tool with no annotations and no output schema, the description covers the essential selection criteria: what it detects, the detection basis, and the full supported engine set. The main gap is the missing return contract — no output schema exists to explain the result shape, and the description never mentions no-match behavior or whether results include confidence/versions.
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?
The tool takes zero parameters (empty input schema, 0 required), so there is nothing for the description to document. Per the 0-parameter baseline, this is a 4; the description correctly focuses on behavior rather than nonexistent 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 states a specific verb and resource: 'Detecta projeto/engine de game por evidencias reais do workspace'. It enumerates the exact supported engines (Godot, Unity, Unreal, Phaser, Three.js, Flame, libGDX, GameMaker, Defold, RenPy, LÖVE), which distinguishes it from sibling tools like aya_games_validar (validation), aya_games_checklist, and other 'detectar' tools (aya_framework_detectar_rota, aya_dominio_detectar).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The engine list implies when the tool applies (workspace shows evidence of any listed engine), but the description never states explicit when/when-not conditions and does not name alternatives to exclude, such as aya_games_validar or aya_games_assets_inventariar. Usage context is inferable from the name and engine list, not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden and it does disclose meaningful behavior: inventorying is dynamic and avoids loading the entire library into context. It does not detail return shape or side effects, but the verb 'inventariar' clearly indicates a non-mutating cataloging operation.
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?
A single front-loaded sentence states the action, target, and key behavioral constraint with no filler. Every word contributes to selection and invocation.
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?
For a zero-parameter tool, the description covers what is inventoried and how the inventory is performed. It does not explicitly state the return format and there is no output schema, but the inventory semantics make the expected result reasonably inferable.
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?
The tool has zero parameters and 100% schema description coverage, so the baseline is 4. The description correctly needs to explain no parameter details because none exist.
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 uses a specific action ('Inventaria dinamicamente') and a precise resource ('o pacote AGENTS/.agents/.skills'), so an agent knows exactly what the tool targets. The qualifier about not loading the whole library further defines scope and separates it from broader context-loading sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies the use case: inventory the AGENTS/.agents/.skills package when the full library should not be loaded into context. However, it does not explicitly state when to prefer this over nearby alternatives like aya_framework_skills_buscar or aya_framework_packs_listar, nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It clearly discloses the key safety behavior: files are created only if absent, meaning existing files are not overwritten. It does not describe return values or partial-failure behavior, but for a zero-parameter idempotent initializer this is strong transparency.
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 compact sentence that front-loads the action, resource, condition, and location. Every piece of information earns its place, and there is no filler or repetition of the tool name.
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?
For a zero-parameter, no-output-schema initialization tool, the description covers the essential facts: what is created, how many files, the condition, and the target directory. It could be slightly more complete by specifying the actual file names or mentioning what the tool returns, but nothing required to invoke it correctly is missing.
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?
The input schema has zero parameters and schema description coverage is 100%, so the baseline for parameter semantics is 4. The description adds context about what is created and where, which is useful even though no parameters exist to explain.
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 states a specific verb ('Cria'), a concrete resource ('os quatro arquivos de continuidade herdados do Agents'), a location ('em tmp/'), and an idempotence condition ('somente se ausentes'). This is clear and distinguishes the tool from the many sibling memory tools as a one-time initializer rather than a read/update/checkpoint operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it should be used during initialization when the continuity files do not yet exist, but it does not explicitly state when to prefer it over alternatives such as aya_memoria_criar_checkpoint or aya_memoria_atualizar_estado. No exclusions or comparisons are provided, so the usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is covered. The description adds behavioral context by specifying that the result is tied to the current initialization, implying that active toolsets may vary between sessions. This is useful beyond the annotations.
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 compact sentence that conveys both the operation and the key nuance about active status. There is no redundancy or filler.
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?
For a 0-parameter, read-only, idempotent listing tool, the description fully specifies what the tool returns conceptually: the toolsets and their active state. No output schema exists, but the described outcome is sufficient for an agent to understand the tool's purpose and invoke it 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?
The tool has zero parameters, so the input schema is trivially complete with 100% coverage. The description needs to convey no parameter meaning, and the baseline of 4 is appropriate.
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 uses a specific verb ('Lista') and a precise resource ('toolsets do AyA-MCP'), and adds the exact scope: which toolsets are active in this initialization. This clearly distinguishes it from sibling tools like aya_toolsets_sugerir, which suggests rather than lists.
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 makes its usage context clear: an agent should call this when it needs to know available toolsets and their active status for the current initialization. It does not explicitly compare against alternatives, but the resource and action are specific enough that no exclusion is necessary for this simple 0-parameter read tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![AyA-MCP MCP server](https://glama.ai/mcp/servers/testesvibecodeing/AyA-MCP/badges/card.svg)](https://glama.ai/mcp/servers/testesvibecodeing/AyA-MCP)

Score Badge

Copy to your README.md:

[![AyA-MCP MCP server](https://glama.ai/mcp/servers/testesvibecodeing/AyA-MCP/badges/score.svg)](https://glama.ai/mcp/servers/testesvibecodeing/AyA-MCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/testesvibecodeing/AyA-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server