aya_evidencia_listar
Retrieve evidence records registered for a specific task to verify submitted proof and audit progress.
Instructions
Lista evidencias reais registradas por tarefa.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| tarefa | No |
Retrieve evidence records registered for a specific task to verify submitted proof and audit progress.
Lista evidencias reais registradas por tarefa.
| Name | Required | Description | Default |
|---|---|---|---|
| tarefa | No |
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.
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.
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.
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.
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.
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.
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