DecisionsSearch

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Tools are grouped by prefix (memory, graph, errors, system) with detailed descriptions including 'Do NOT use for' clauses, which greatly aids disambiguation. However, the sheer number of tools (47) and some overlapping concepts (e.g., multiple ways to create memories) mean careful reading is still required, so a perfect score is not warranted.
Naming Consistency5/5
All tools follow a consistent hierarchical dot notation (prefix.group.action) with imperative verbs and snake_case naming. There is no mixing of conventions, and the pattern is predictable across all 47 tools.
Tool Count3/5
47 tools is on the high side for a single server, potentially overwhelming for an agent. While the domain is complex and each tool appears justified, the count exceeds the typical sweet spot of 3-15 tools. The server would benefit from consolidation or better organization to reduce cognitive load.
Completeness4/5
The tool set covers a wide range of operations: CRUD for memories, graph catalog management, error handling, system jobs, and PR integration. Notable gaps include missing delete operations for projects and categories (only update exists), but the overall surface is comprehensive and supports the stated purpose.
Average 3.1/5 across 47 of 47 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits, but it fails entirely. It does not explain side effects (e.g., whether the memory becomes hidden or unavailable), reversibility, permissions needed, or what "DEPRECATES" refers to. The agent cannot infer the consequences of calling this tool.
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 a single sentence, which is concise, but the unclear language and probable grammatical errors (e.g., "Depreca", "liga DEPRECATES") undermine its effectiveness. Brevity does not excuse lack of clarity.
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 three parameters, no output schema, and no annotations, the description should provide a complete picture, but it omits effects, return values, and behavioral nuances. The tool's purpose is only vaguely conveyed, leaving substantial gaps for an agent to use it correctly.
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%, so the description must compensate, but it only loosely hints that "substituta" relates to the replaced_by parameter. The rationale parameter and memory_id are not elaborated upon. The description adds minimal value beyond the schema field titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses non-standard language ("Depreca", "DEPRECATES") and fails to clearly state that the tool marks a memory as deprecated. The mention of linking to a substitute is vague, and no differentiation from sibling tools like memory.upsert or memory.consolidate is provided.
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, nor when it would be inappropriate. The description does not mention any prerequisites, constraints, or context for deprecation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full behavioral transparency burden. It mentions immediate or deferred but fails to disclose what consolidation entails (e.g., idempotency, blocking behavior, side effects on other memories). The description is insufficient for an agent to predict tool behavior.
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 sentence with no wasted words, but it is under-specified. Conciseness should not sacrifice completeness; here it is too brief to be effective. A 3 reflects acceptable brevity with inadequate content.
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 no output schema, two undocumented parameters, and a large set of sibling tools, the description fails to provide sufficient context. An agent cannot determine what consolidation does, what to expect as output, or how to set parameters correctly. The description is far too incomplete.
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%, so the description must explain parameters. The mention of 'immediate or deferred' partially clarifies the mode parameter, but the scope parameter is entirely unexplained. The description adds marginal value beyond raw schema but does not fully compensate for the coverage gap.
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 it triggers consolidation and mentions immediate or deferred modes, giving a clear verb and resource. However, it does not specify what consolidation means in this context or differentiate it from sibling tools like memory.reconcile or memory.reflect, making its purpose somewhat vague.
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?
No usage guidance is provided. The description does not indicate when to use consolidation vs other memory operations, when to choose immediate vs deferred, or any prerequisites or consequences. This is a critical omission.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility for behavioral disclosure. The single sentence only states the action; it does not mention side effects, required permissions, validation rules, duplicate behavior, or any constraints. For a create operation, this is critically insufficient.
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 a single sentence, which is concise but at the expense of valuable content. It lacks structure and essential information, making it under-specified rather than effectively concise.
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?
With no output schema, the description should explain what the tool returns (e.g., the created category object). It does not. It also provides no context about how categories relate to other graph entities or when to use this tool over similar siblings. The description is incomplete for the complexity of the tool.
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%, meaning no parameter descriptions exist in the schema. The tool description adds no information about any of the 7 parameters (3 required). It fails to compensate for the missing schema 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 states it creates a new category in the graph catalog. The verb 'cria' and resource 'nova categoria no catálogo do grafo' are clear. However, it does not differentiate from sibling tools like graph.category.update or graph.domain.create, but the name and action are sufficiently specific.
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 guidelines are provided. The description does not indicate when to use this tool versus alternatives (e.g., graph.domain.create), nor any prerequisites or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing behavioral traits. It only states 'executes a scheduled job immediately' but does not mention side effects, permissions, destructiveness, or any operational consequences. This is critically insufficient for a tool that likely triggers 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence) and front-loaded with the action. However, it is under-specific: the single sentence could have included more useful information without being verbose. It earns its place by stating the basic purpose, but the minimalism reduces utility.
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 the tool's simplicity (1 param, no output schema, no annotations), the description still fails to be complete. It does not explain return values, success/failure indicators, preconditions, or what executing a job actually triggers. The description is insufficient for an agent to use the tool effectively.
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 input schema has one required parameter (job_name) with zero description coverage. The tool description does not describe or contextualize this parameter at all. Since the schema provides no semantic help, the description needed to compensate but failed entirely.
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 verb 'Executes' and the resource 'scheduled job', making it clear what the tool does. It distinguishes from sibling tools like system.jobs.list and system.jobs.history by indicating immediate execution. However, it lacks any additional context about what 'execution' entails, which keeps it from 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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or any alternative tools. The absence of usage direction leaves the agent without decision-making support.
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 disclosing behavioral traits. It only states the action of creating a relation but does not reveal whether the operation is idempotent, what happens on duplicate attempts, permission requirements, or side effects. This is insufficient for safe usage.
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 a single sentence, which is front-loaded but overly terse. It lacks essential details to earn its place, resulting in under-specification rather than effective conciseness. A more expanded description with parameter hints would be better.
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 5 required parameters, no output schema, no annotations, and zero parameter descriptions, the description is critically incomplete. It does not explain return values, constraints on relation types, or how to interpret results. An agent cannot reliably invoke this tool based solely on this documentation.
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 tool description adds no meaning to the parameters. Neither 'source_kind', 'target_kind', 'relation_type', nor 'rationale' are explained. The agent is left to guess valid values and semantics, which is critical given no enums or constraints 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 clearly states the verb 'creates' and the resource 'relation between two nodes of the graph catalog', distinguishing it from the sibling tool graph.relation.delete. However, it does not clarify the nature or direction of the relation, leaving some ambiguity.
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 guidelines are provided. The description does not specify when to use this tool versus alternatives, nor does it mention prerequisites (e.g., nodes must exist) or scenarios where the tool should not be used. This leaves the agent without important contextual cues.
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 fully disclose behavioral traits. It indicates a read operation ('Recupera'), but fails to mention potential side effects (likely none), authentication requirements, rate limits, or whether the operation is idempotent. The minimal description leaves significant gaps about the tool's behavior.
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 very concise (single sentence, 5 words in Portuguese). While brevity is positive, it lacks structure—no separate sections for purpose, parameters, or usage. The sentence is front-loaded with the verb, which is good, but overall it is under-specified.
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 parameter, no output schema, and no annotations, the description should at minimum clarify what 'detalhes da investigação' entails—i.e., the structure or content of the returned details. It does not, leaving the agent with an incomplete understanding of what the tool provides.
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 by explaining the 'error_id' parameter. It does not mention the parameter at all. The agent receives no guidance on what the parameter represents, how to obtain it, or its format. This is a critical failure for a tool with a single 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 clearly states the action ('Recupera detalhes') and the resource ('investigação de um erro'). It implies a retrieval operation for error investigation details, which distinguishes it from sibling tools like 'errors.list' (listing errors) and 'errors.ingest' (ingesting errors). However, it could be more explicit about what 'investigation' means and how it differs from other error-related 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?
No usage guidance is provided. The description does not specify when to use this tool versus alternatives like 'errors.list' or other memory/graph tools. There is no mention of prerequisites, context, or exclusions, leaving the agent to infer usage solely from the tool name and 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?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only says 'import', implying a write operation, but gives no details about side effects (e.g., does it replace existing data? require prior empty state? handle conflicts?). Security, idempotency, and error behavior are not addressed.
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 sentence, which is concise, but it lacks structuring (e.g., parameters, usage notes, examples). It is not overly verbose, but the brevity sacrifices clarity.
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 5 parameters, no output schema, and no annotations. The description provides none of the needed context: no explanation of the CSV format, required order, or relationship between parameters. For a complex import operation, this is severely incomplete.
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 by explaining parameters. It does not even mention the five parameters (domains_csv, projects_csv, relations_csv, categories_csv, schema_version). The default empty strings and required semantics are left entirely unspecified, making the tool difficult to invoke correctly.
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?
Description clearly states the tool imports a graph catalog from a CSV bundle. It uses a specific verb ('Import') and resource ('catalog do grafo'), making the purpose obvious. However, it does not differentiate from the sibling tool 'graph.catalog.export_csv', which is the inverse operation.
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 alternatives (e.g., individual CRUD tools for domains, projects, etc.). The description does not mention prerequisites, context of use, or scenarios where this import 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 provided, the description carries the full burden of disclosing behavioral traits. It only says 'updates data' but does not specify whether fields are overwritten partially or fully, what happens if the category does not exist, or if there are any side effects. No return value or confirmation is described.
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, which is concise but lacks the detail needed to be useful. It is front-loaded with the action but does not cover necessary information, making it less effective despite its brevity.
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 the tool has 8 parameters, no output schema, and no annotations, the description is severely incomplete. It fails to explain parameter semantics, behavioral outcomes, or any constraints, leaving the agent with insufficient information to use the tool correctly.
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 input schema has 8 parameters with 0% description coverage, and the tool description does not explain any of them. The agent must rely solely on parameter titles like 'Id' or 'Name', which are insufficient to understand required formats, constraints, or how they relate to the update operation.
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 updates an existing category in the catalog. It uses a specific verb ('update') and resource ('category'), and the sibling tool graph.category.create implies the distinction. However, it is somewhat vague by saying 'data' rather than listing specific fields.
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 vs alternatives like graph.category.create. There is no mention of prerequisites, conditions for updates, or when not to use it. The context from sibling tools implies the difference, but explicit guidance is absent.
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 full burden for behavioral traits. It only states 'updates data' without disclosing whether it performs partial updates, overwrites unspecified fields, requires permissions, affects related entities, or returns confirmation. This is insufficient for an agent to predict 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one short sentence). While it states the core purpose, it is under-specified for a tool with 7 parameters and no other documentation. Every sentence earns its place, but the single sentence does not earn its place because it omits essential context, making it more incomplete than concise.
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 the complexity (7 parameters, no annotations, no output schema, 0% parameter documentation), the description is severely incomplete. It fails to explain parameter behavior, update semantics, return values, or usage context. The tool requires far more detail to be usable by an agent.
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 add meaning to the 7 parameters. It does not mention any parameter names, roles, constraints, or relationships. The description adds zero value beyond the raw schema, leaving the agent to guess the purpose of 'id', 'slug', 'tags', 'status', etc.
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 updates an existing project in the catalog. The verb 'atualiza' (updates) and resource 'projeto existente no catálogo' are specific. It distinguishes from sibling 'graph.project.create' (create) and 'graph.project.list' (list). However, it does not specify whether the update is partial or full replacement, which slightly reduces 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 is provided on when to use this tool versus alternatives. Siblings like 'graph.project.create' exist for new projects, but the description does not mention such distinctions or any prerequisites, failure scenarios, 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states that the tool 'gets' a preview, implying a read operation, but does not confirm idempotency, side effects, authentication needs, or error handling (e.g., what happens if the proposal_id does not exist). This is insufficient for an agent to safely invoke the 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 a single short sentence, which is concise but lacks structure. It does not front-load key information like the tool's purpose or usage context. While not verbose, it could be better organized (e.g., specific details about the preview or links to other tools).
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 an output schema, annotations, and the tool's seemingly simple but critical role (preview before approval), the description is incomplete. It does not explain what the preview contains, its format, or how the agent should use the returned data. The agent would need to guess or rely on external knowledge.
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 description coverage is 0%, meaning the description adds no information about the 'proposal_id' parameter beyond its name. The description does not explain what a proposal_id is, how to obtain it, or any constraints (e.g., format, valid values). The tool name and description imply a change proposal context, but the param is left entirely to 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 uses a specific verb 'Obtém' (gets) and identifies the resource as 'preview' linked to approval. It distinguishes from sibling tools like memory.change.propose and memory.change.rollback by implying this retrieves the current state before approval. However, the phrase 'exatamente o preview que será aprovado' is slightly ambiguous—it could be clearer whether this is the preview of a proposed change or the actual approved version.
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 alternatives. There is no mention of prerequisites, related actions (e.g., first propose a change), or scenarios where this tool is appropriate. Sibling tools exist but are not referenced.
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 adds one key behavioral trait: it only creates a proposal, not a direct reactivation. However, it does not disclose side effects, required permissions, idempotency, or what happens after the proposal is created. This is minimal for a mutation 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 a single sentence, which is concise and front-loaded with the action. However, conciseness is achieved at the expense of valuable information. Every sentence should earn its place, but this one leaves out critical details, making it borderline under-specified.
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 the tool has 4 required parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain the concept of a rollback proposal, the meaning of expected_revision_id versus restore_revision_id, the return value, or error conditions. An agent cannot reliably invoke this tool based solely on the description.
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%, meaning the input schema provides no parameter descriptions. The tool description does not explain any of the four parameters (family_id, restore_revision_id, expected_revision_id, reason). The parameter names are somewhat self-explanatory, but the description adds no value beyond what the names imply, which is insufficient for compensating for the lack of schema descriptions.
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 creates a rollback proposal, which is a specific verb+resource. The behavioral note ('nunca reativa a revisão histórica diretamente') adds nuance. However, it does not fully distinguish from sibling tools like memory.change.propose, which might also involve proposals, so it's not a perfect 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 explicit guidance on when to use this tool versus alternatives. The behavioral note about not directly reactivating historical revisions is a caution, but it doesn't provide context for selection. No prerequisites or exclusion criteria are 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?
With no annotations provided, the description must disclose behavioral traits, but it only states the purpose. It does not mention side effects, authentication needs, or success/failure behavior, leaving the agent uninformed.
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 concise sentence (6 words), but it is overly simplistic and omits necessary detail. It does not justify its brevity by providing front-loaded key information beyond the core action.
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 the tool has 3 parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain what feedback entails, how to interpret parameters, or what the agent should expect from the tool's execution.
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 any of the three parameters (memory_id, score, accepted). It adds no meaning beyond the schema structure, failing to compensate for the lack of schema-level descriptions.
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 tool registers usage feedback for telemetry, which clearly identifies the action and resource. However, it does not differentiate from similar siblings like memory.set_weight or other feedback mechanisms, and the use of Portuguese may hinder non-Portuguese agents.
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. The description lacks context about prerequisites, exclusions, or specific scenarios for feedback submission.
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 has full responsibility for behavioral disclosure. It does not state that the tool is read-only, how output is structured (though an output schema exists), or any side effects. The simple 'list' verb weakly implies no state changes, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only one sentence and very short, which is efficient but at the cost of missing essential information. It is under-specified for the tool's role among many siblings.
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 having an output schema, the description lacks key context: language consistency, the definition of 'landing zone', and the tool's place in the workflow. A new agent would struggle to know when and why to use this tool.
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 mention the 'limit' parameter at all. The agent receives no semantic context beyond the parameter name and type, which is insufficient for correct usage.
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 (list) and resource (events from the landing zone) and is distinct from sibling tools, as no other sibling explicitly targets raw events. However, the description is in Portuguese while the tool name is English, which may cause confusion for English-speaking agents.
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 alternatives like memory.query or memory.get. It does not mention the landing zone's role or whether this is for debugging, which leaves the agent without context for appropriate invocation.
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 exist, and the description does not reveal behavioral traits such as idempotency, error handling (e.g., removing a non-existent relation), side effects, or authorization requirements. The sparse description fails to compensate for missing annotations.
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 – concise but lacking substance. It could be expanded to include critical details without being verbose.
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 the complexity (5 required parameters, no schema descriptions, no output schema), the description is severely incomplete. It fails to explain parameter semantics, return values, or operational context, leaving the agent underinformed.
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 adds no meaning to the five required parameters. While parameter names (e.g., source_id, relation_type) are somewhat self-explanatory, the description does not clarify expected values, format, or constraints.
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 ('Remove relation') and the resource ('between two nodes of the graph catalog'). It distinguishes from sibling tools like graph.relation.create, though it could further clarify the scope of 'graph catalog'.
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 alternatives (e.g., graph.relation.create or other mutation tools). There are no hints about preconditions, typical use cases, or 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action without mentioning potential side effects, required permissions, or constraints (e.g., uniqueness of slug). It doesn't disclose what happens on duplicate slug or whether it's a safe operation. This is a significant gap for a create-like operation.
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, which is concise and front-loaded with the core purpose. However, it is slightly sparse, lacking any additional context that could be valuable. It earns a 4 because it is efficient with no wasted words.
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 7 parameters, many of which are optional (tags, aliases, status, description), and no annotations or output schema, the description is underspecified. It does not explain the relationship between domains and projects, the meaning of aliases, or any constraints. A more complete description would clarify the domain creation context.
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 does not add any parameter info. However, the schema itself has clear property names (slug, name, project_id, etc.) and types. The description lists no parameters, but the schema is self-explanatory for most fields, giving a baseline of 3.
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 says: 'Cria um novo domínio no catálogo do grafo.' This clearly states the verb (create) and resource (domain in graph catalog), but it does not distinguish from sibling tools like graph.domain.update or graph.category.create. It is a clear but generic statement without specific scope details.
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 alternatives such as graph.domain.update or graph.category.create. There is no mention of prerequisites, context, or exclusions. The usage is implied by the name but not explicitly 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. It does not state whether the operation is read-only or has side effects, what happens if the PR ID is invalid, or any rate-limiting considerations. The description only states the basic action, leaving the agent unaware of key behavioral traits. Since there are no annotations to contradict, no contradiction flag is raised.
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 of 4 words, which is efficient. It front-loads the action ('Lista') and the resource. However, it could have included a brief usage note without significant bloat. The structure is appropriate for the simplicity of the tool.
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 parameter, no annotations, but an output schema (not shown), the description is incomplete. It does not explain the return format, pagination, or what qualifies as 'linked' (e.g., direct links or any transitive relationship). The agent lacks context about edge cases like empty results or error handling. A more complete description would clarify these aspects for reliable 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 but does not. The parameter 'pr_memory_id' is not explained in the description—its meaning is only hinted by the tool name and description context (linking to a PR). However, with only one parameter and a clear name, the agent can infer its purpose. The description adds no additional semantics beyond what the schema provides, earning a baseline score of 3 given the low coverage.
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 'Lista MemoryItems linkados a um PR' (Lists MemoryItems linked to a PR) clearly states the verb (list) and resource (MemoryItems linked to a PR). However, it does not distinguish this tool from siblings like 'memory.linked_prs' which lists PRs linked to a memory, or 'memory.pr.link_memory' which links a memory to a PR. The purpose is understandable but lacks sibling differentiation.
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 vs alternatives, such as 'memory.pr.query' for querying PRs, or 'memory.linked_prs' for the inverse relationship. There is no context about prerequisites (e.g., the PR must exist) or exclusions. The one-sentence description implies usage solely by mentioning the PR context, but this is insufficient for an agent deciding among many sibling tools.
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 full burden. It says it 'removes orphaned vectors,' which implies destructive action, but it doesn't disclose whether this action is reversible, what side effects occur (e.g., broken links), or whether it requires special permissions. The term 'remove' is clear but the behavioral profile around safety and rollback is opaque.
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, short sentence in Portuguese. It is concise and front-loaded with the main action. However, it could add more value without bloat by clarifying the project parameter or usage context. No wasted words.
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 destructive behavior (removal of vectors), the lack of annotations, and incomplete parameter documentation, the description is insufficient for safe use. An agent cannot tell whether running this tool is safe, what data will be removed, how to limit scope (project parameter), or what to expect after. For a tool acting on two databases, much more context is needed.
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 has one optional parameter (project) with no description and 0% schema coverage, meaning neither schema nor description explains what project does. The description does not clarify whether project limits reconciliation to a specific project or what leaving it null mean. Baseline is 4 for 0 params but since there is 1 param with no context, a 3 is appropriate—the param semantics are incomplete.
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 it verifies consistency between Neo4j and Qdrant and removes orphaned vectors. This tells the agent the action (verificar/remover) and the resources (Neo4j, Qdrant, vetores órfãos), but it doesn't specify what concrete outcome occurs (e.g., which tool is authoritative, what data is affected). Given the large sibling set, it distinguishes from pure query or mutation tools like memory.get or memory.upsert, but it's somewhat vague on the exact scope of 'consistência'.
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 tool versus siblings like memory.consolidate, memory.find_duplicates, or memory.reflect. All four deal with data health. The description does not tell the agent whether this is a maintenance task to run regularly, or only after certain operations. Also no mention of prerequisites 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. The description states it updates an existing domain but does not mention whether partial updates are supported, what happens if the domain does not exist (error or fallback), whether the operation is idempotent, or if it requires specific permissions. As a mutation tool with zero annotations, 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 concise sentence in Spanish that conveys the core purpose efficiently. It is front-loaded with the verb and resource. However, it is somewhat under-specified given the complexity of 8 parameters, but for the minimum viable statement it is appropriately short.
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 8 parameters (4 required), no output schema, no annotations, and 0% schema description coverage, the description is insufficient. It does not explain return values, required fields validation, side effects, or how this update integrates with the catalog consistency model. The sibling tools include related CRUD operations (create, delete on graph entities) and there is no differentiation in behavior from those.
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%, meaning none of the 8 parameters have descriptions in the input schema beyond their titles and types. The description mentions 'dados de um domínio' without detailing which parameters are updatable, optional, or how they relate. It does not clarify that 'id' and 'project_id' are required identifiers, nor does it explain the meaning of 'slug', 'aliases', 'tags', or 'status'. The description fails to compensate for the missing schema 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 states the verb 'Atualiza' (updates) and the resource 'dados de um domínio existente no catálogo' (data of an existing domain in the catalog), clearly indicating what the tool does. It distinguishes from sibling tools like graph.domain.create and graph.relation.create by focusing on domain update rather than creation or relation management.
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 alternatives such as graph.domain.create (for new domains) or other update tools like graph.project.update or graph.category.update. There are no explicit when/when-not conditions or prerequisites mentioned, leaving the agent to infer usage context from the tool 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?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the action (create) but does not mention side effects (e.g., does it validate slugs? Does it create dependencies?), permissions, idempotency, or what happens if a project with the same slug exists. This is a significant gap for a state-changing operation.
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, front-loading the creation purpose. It wastes no words, though it could be slightly expanded without breaking conciseness. It 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?
Given the high complexity (6 parameters, no output schema, state-altering tool with no annotations), the description is far from complete. It does not cover what the output/return value is, error conditions, or required relationships. The one sentence leaves the agent with significant ambiguity when deciding to invoke this 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?
Schema description coverage is 0% (no parameter descriptions in the schema), so the description must compensate. However, the description does not describe any parameter semantics, just the tool's purpose. Baseline 3 is not justified; since schema coverage is very low and description adds nothing, a score of 3 (marginal value) is the most lenient given the guidelines. The description provides zero detail about required fields like 'slug' or 'name', optional 'tags', 'status', 'aliases', or '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 states a specific verb ('cria') and resource ('novo projeto no catálogo do grafo'), clearly indicating creation of a graph catalog project. However, it does not distinguish from siblings like 'graph.project.update' (update) or 'graph.category.create' (category creation), though the action is unique enough.
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?
No guidance is provided on when to use this tool versus alternatives such as 'graph.project.update', 'graph.category.create', or others. There is no information about prerequisites, required context, or scenarios where this tool is preferred.
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 full burden but only states that a relationship is created. It does not disclose whether the operation is idempotent, overwrites existing links, validates memory existence, or has any side effects. Such behavioral traits are critical for a mutation tool with no annotation safety net.
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 that conveys the core action. It is efficient, but the brevity sacrifices necessary detail. A slightly longer description could improve clarity without losing 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?
Given the tool has three required parameters, no output schema, and no annotations, the description is too sparse. It fails to explain return values, error handling, relationship constraints, or what happens on failure. The low complexity of the tool does not excuse the lack of completeness when supporting metadata is absent.
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%, meaning the schema provides no parameter descriptions. The tool description mentions 'duas memórias' (two memories) and the relationship, which hints that from_id and to_id are memory identifiers and rel is the relationship type, but it does not explain format, allowed values, or constraints. Three required parameters remain under-documented.
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 'Cria relação semântica entre duas memórias' (Creates semantic relationship between two memories), which is a specific verb+resource. It distinguishes from sibling tools like 'memory.pr.link_memory' by focusing on general memories rather than PRs. However, the description is in Portuguese while the tool name is in English, which may cause initial confusion, and it does not explicitly differentiate from all similar 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?
No guidance is provided on when to use this tool versus alternatives. Sibling tools include several linking-related tools (e.g., memory.pr.link_memory, memory.linked_prs, graph.relation.create), but the description gives no context for selection, such as prerequisites or preferred 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?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states the query action and filtering criteria, but omits whether the operation is read-only, what side effects exist, authentication needs, or the nature of the response beyond what the output schema conveys.
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 delivers the core purpose with no extraneous words. It is efficiently structured, though the brevity sacrifices completeness.
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 three parameters, no annotations, and an output schema that requires context, the description is insufficient. It does not clarify the role of stored procedures, the effect of the project parameter, how pagination works via limit, or the expected output structure.
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. It mentions only task_type implicitly via 'by task type', but provides no explanation for the limit or project parameters. The meaning added is minimal beyond what the parameter names suggest.
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 queries stored procedures by task type, using a specific verb and resource. It implicitly distinguishes from siblings like memory.query (general) and memory.procedure.create (create) by focusing on procedures filtered by task type.
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 alternatives. It does not mention scenarios where other tools like memory.query or memory.episode.query would be more appropriate, or any prerequisites for invoking it.
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 fully disclose behavior. It only states 'history of executions' without explaining whether the operation is read-only, requires authentication, has rate limits, or how pagination works via the limit parameter. The lack of any behavioral detail leaves the agent guessing.
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 concise sentence, which is efficient. However, it is too terse and omits essential details. While it is front-loaded, it sacrifices completeness for brevity, making it minimally adequate.
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?
Though an output schema exists (reducing the need to describe return values), the description fails to cover key aspects like ordering, scope (e.g., all history or recent only), or how limit affects the results. For a simple 2-parameter tool with siblings, more context is expected to enable 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?
The input schema has 100% coverage? Actually 0% description coverage on properties. The description does not explain the purpose of job_name (required) or limit (default 20). It adds zero semantic value beyond the schema, failing to specify that limit controls the number of history entries or that job_name identifies the job. This is a critical 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 'Historico de execucoes de um job' clearly states the tool retrieves execution history for a specific job. It distinguishes itself from siblings like system.jobs.list (list jobs) and system.jobs.run (run a job) by focusing on historical records.
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 alternatives. There is no mention of prerequisites, context, or cases where other tools would be more appropriate. Sibling names hint at distinct use cases, but the description itself offers no such information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 disclosing behavioral traits. It only states that the tool exports a catalog, but does not indicate whether it is read-only, modifies state, requires permissions, or has any side effects. The agent receives no information about safety or impact.
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 that states the core purpose. It is front-loaded and efficient. However, it is so brief that it sacrifices completeness, which prevents a perfect score.
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 no parameters and no output schema, the description should explain what the export produces (e.g., a file path, download URL, or data stream). It does not describe the return value or behavior, leaving the agent without enough context to use the tool 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, and the schema coverage is 100% (trivially). The description adds no parameter information, but none is needed. Following the guideline for 0 parameters, a 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 the verb 'Exporta' and resource 'catálogo do grafo', specifying the output format as 'bundle CSV'. This distinguishes it from the sibling `graph.catalog.import_csv` (import). However, it does not elaborate on what constitutes a 'bundle CSV' or the scope of the export, leaving some ambiguity.
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 alternatives (e.g., `graph.catalog.import_csv` for importing, or other export methods). There is no mention of prerequisites, context, or scenarios where export 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 provided, the description bears full responsibility for behavioral disclosure. It correctly notes that the tool does not record an active memory, which is critical. However, it fails to disclose side effects, required permissions, preview lifetime, how to discard, or any error behavior. For a mutation-like tool, 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?
The description is a single short sentence that immediately conveys the action and key limitation. It is front-loaded and avoids filler. However, given the tool's complexity (8 parameters), the description could be slightly longer without losing 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?
The tool has 8 parameters, no output schema, no annotations, and many siblings. The description covers only the basic purpose and one behavioral trait. It omits parameter semantics, usage context, and sufficient behavioral details, leaving the agent underinformed 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%, meaning the input schema provides no descriptions. The tool description does not mention any of the 8 parameters, leaving the agent to infer meaning from parameter names alone. Parameters like source_locator and source_kind are ambiguous, and the description offers no help. This is a major deficit.
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 that the tool creates a server-side preview and does not record an active memory, which distinguishes it from other tools that commit changes. However, it could be more explicit about 'proposing a change to memory' to fully align with the tool name and sibling context.
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 should be used when a preview of a change is needed before recording. However, it provides no explicit guidance on when not to use it, nor does it mention alternative tools (e.g., memory.upsert or memory.pr.create). The context from sibling names like memory.change.rollback adds some implicit guidance, but the description itself lacks direct comparisons.
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 transparency. It only mentions the query capability and filter dimensions, but does not disclose what happens on successful query (return format, pagination behavior, whether it returns full memories or just IDs), what happens when no results are found, or any error conditions. The output schema exists but the description does not reference it.
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 that communicates the core purpose and main filter dimensions. It is appropriately sized for a simple query tool, though it could be front-loaded more with the return value hint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 parameters (0 required), an output schema exists, and no annotations, the description should be more complete. The output schema suggests structured return data, but the description doesn't hint at what fields are returned. For a query tool with no required parameters, the description should clarify what a query with no filters returns (e.g., all episodes? default limit only?). It's adequate but has clear gaps.
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. The description mentions the three filter dimensions (project, outcome, tag) which correspond to three of the four parameters, but does not describe the `limit` parameter or any constraints (e.g., exact match vs partial match, case sensitivity, or how multiple filters combine). This adds marginal value over raw parameter names but is incomplete.
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 verb ('Consulta' = query) and the resource ('memórias episódicas' = episodic memories), and provides three filter dimensions (project, outcome, tag). It is specific and distinguishes this tool from siblings like memory.query (general memory query) or memory.episode.create (episode creation), though it could be more explicit about the difference.
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 memory.query, memory.episode.create, or the other memory query tools (memory.pr.query, memory.query_at, etc.). There is no mention of prerequisites, ordering constraints, or when not to use this tool.
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. However, the description only states the function without any behavioral traits—such as whether results are paginated, what the default sort order is, whether it only returns active PRs, or any rate limits/permission requirements. For a tool with no annotations, this leaves significant behavioral gaps for the AI agent.
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 extremely concise at one short sentence (5 words in Portuguese) with zero wasted words. It is front-loaded with the primary action. However, given the lack of annotations and behavioral context, a slightly more informative description could have been equally concise while providing more value, such as adding 'Returns a list of PR IDs or full objects'.
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?
Considering the context: 1 required parameter, no parameter docs, an output schema exists but its content is unknown, and there are many sibling tools. The description defines the core 'what' but lacks completeness for an AI agent to confidently invoke it. The output schema may provide return value structure, but the description doesn't hint at whether results are limited, ordered, or filtered. For a simple list tool with good context signals, a score of 3 reflects that the description is minimally viable but leaves the agent guessing about return format and behavior.
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?
With schema description coverage at 0%, the description must add meaning beyond the parameter name 'memory_id'. The description does clarify that the input is a MemoryItem ID (since the resource is 'PRs linkados a um MemoryItem'), which is helpful but minimal. The schema already makes 'memory_id' required, so the description only reinforces the parameter's purpose without adding format, example, or context about where to obtain the ID. Baseline 3 is appropriate as the description does not fully 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Lista' (List) and the resource 'PRs linkados a um MemoryItem' (PRs linked to a MemoryItem). It effectively distinguishes from sibling tools like 'memory.pr.link_memory' (which creates links) and 'memory.pr.linked_memories' (which likely lists memories linked to a PR, the inverse). The purpose is specific and precise, though it could be slightly improved by explicitly stating it is a read-only retrieval operation.
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. With siblings like memory.pr.query (generic PR query), memory.pr.linked_memories (inverse listing), and memory.pr.link_memory (creating links), the description does not explain the specific scenario (e.g., 'Use this when you have a MemoryItem ID and need to see all associated PRs'). The user must infer the usage 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?
With no annotations, the description must disclose behavioral traits. It does not state whether the tool is read-only, what authentication is needed, or any rate limits or pagination behavior. The description implies a query but provides no depth.
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 sentence with no wasted words, but it sacrifices completeness for brevity. It front-loads the main action but misses important parameter details. Conciseness is adequate, but structure is minimal.
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 6 parameters with no schema descriptions and no annotations, the description is insufficient. It does not explain what 'PR memories' are, how filtering works, or that limit controls count. An agent would struggle to use this tool effectively without additional 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 mentions three parameters (project, repo, changed file) but omits three others (pr_number, limit, summary_query). An agent cannot know the purpose of pr_number or summary_query from the description alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries PR memories and specifies three filter dimensions (project, repo, changed file). This distinguishes it from sibling tools like memory.query (general query) and memory.pr.create (creation). The verb-resource combination is specific.
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 memory.query or memory.pr.linked_memories. The description only states what it does, not the context or exclusions for usage.
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 full burden. It discloses that setting weight triggers a recalculation of effective weight, which is a behavioral side effect. However, it does not mention permission requirements, reversibility, or potential impacts on other memories.
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 wasted words. However, it lacks structure and does not front-load key information like parameter details or usage scope.
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 three required parameters and no output schema or annotations, the description is insufficient. It does not explain return values, side effects beyond recalculation, or parameter constraints, leaving significant gaps 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 coverage is 0%, so parameters have no descriptions. The description mentions 'peso manual' corresponding to weight_manual, but does not explain memory_id or rationale. Thus, it adds minimal value beyond the schema 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 specifies the action (set manual weight) and resource (memory), and adds the recalculation behavior. It differentiates from sibling tools like memory.change.get or memory.upsert, which deal with other aspects. However, it is in Portuguese, which may reduce clarity for English-speaking agents.
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 tool versus alternatives (e.g., memory.change.propose). No prerequisites, exclusions, or context are provided. Usage is only implicitly derived from the tool 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 must fully cover behavioral traits. It does not mention pagination behavior with the 'limit' parameter, default sorts, or whether filtering with empty strings means 'no filter'. It also does not outline response structure, though an output schema exists.
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 fluff. It is front-loaded with the core action and adds filtering details concisely. It could be slightly improved by including 'limit' parameter, but remains clean.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 optional parameters, an output schema, and no annotations, the description is a minimal viable baseline. It covers the primary action and two filters but does not address default behavior, output format, or edge cases. An output schema exists so return structure is partly handled, but behavioral gaps remain.
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 only mentions two parameters (service, error_type) while omitting 'limit'. It does not explain semantics like the effect of default values or how empty strings affect filtering.
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 'Lists ingested errors', providing a specific verb and resource. It also mentions optional filtering by 'service' or 'error_type', which distinguishes it from other error-related tools like errors.get_investigation and errors.ingest.
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 use for listing with filtering, but does not explicitly state when to use this versus alternatives like system.jobs.list or memory.list_raw_events. It lacks when-not or context about prerequisites.
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 full responsibility for behavioral disclosure. It only states the linking action and relation types, but fails to reveal whether this is a mutation, whether it checks for existing links, if it requires special permissions, or if it has side effects on other data. The behavioral profile is severely underdescribed.
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, short sentence that immediately conveys the core action. It is front-loaded and contains no filler or repetition. Every word serves a purpose, making it highly efficient for an agent 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?
Despite the tool having four parameters and no output schema, the description is extremely brief. It does not explain how to use the parameters, what the return value is, what prerequisites exist, or how the linking behaves (e.g., bidirectional, overwrite behavior). The agent would lack enough information to use the tool reliably without additional documentation.
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 0% description coverage, so the description must compensate. It only adds value for the 'relation_type' parameter by listing valid values (IMPLEMENTS, EVIDENCES, MODIFIES). The other three parameters (memory_id, pr_memory_id, rationale) are completely unexplained, leaving the agent without crucial semantic context.
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 verb 'Liga' (links), the specific resources 'PRMemory' and 'MemoryItem', and lists the relation types in parentheses. This distinguishes it from sibling tools like 'memory.link' or 'memory.pr.create', which handle different linking or creation operations.
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 explicit guidance on when to use this tool versus alternatives such as 'memory.link' or 'memory.pr.create'. It does not mention prerequisites, when not to use it, or any scenario-based advice. The agent is left to infer usage solely from the name and brief purpose.
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 states that it lists scheduled jobs, omitting details such as authorization requirements, whether it returns active or all jobs, if it has side effects, or any rate limits.
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, clear sentence that immediately conveys the tool's purpose. There is no unnecessary text; every word serves a function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to detail return values. However, the description is minimal and does not clarify the scope or content of the listed jobs (e.g., job names, status, schedule). In a system with many related tools, a bit more context would help the agent decide when to call this 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 zero parameters, so the schema is fully covered by default. Per guidelines, baseline is 4. The description does not need to add parameter meaning, but it could hint at what the output contains. No demerit as the description is adequate for 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 'Lista jobs agendados (consolidação, summary, etc.)' which clearly indicates the verb (lists) and resource (scheduled jobs). However, it does not differentiate from sibling tools like system.jobs.history (which likely lists job runs) or system.jobs.run, leaving ambiguity about whether it returns job definitions or instances.
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 alternatives. It does not mention typical scenarios, prerequisites, or situations where another tool would be more appropriate, leaving the agent to infer usage context.
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 transparency burden. It discloses the automatic pipeline trigger as a behavioral side effect, but does not mention return values, error handling, idempotency, or authorization requirements.
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 wasted words. It front-loads the primary action and side effect, achieving maximum 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 tool with 5 parameters and no output schema or annotations, the description is too brief. It omits details about valid input values, the format of stack_trace, the nature of the investigation pipeline, and what the tool returns. The agent lacks sufficient context to use it reliably.
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 adds no explanation of the five parameters. Parameter names (e.g., error_type, stack_trace) are somewhat self-explanatory, but the description does not clarify expected formats, allowed values, or the role of each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Ingest an error' and its side effect: 'automatically triggers investigation pipeline.' It distinguishes from siblings like errors.list and errors.get_investigation by adding the automatic pipeline trigger.
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 tool versus alternatives like errors.list or errors.get_investigation. There is no mention of prerequisites, error conditions, 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?
With no annotations provided, the description must disclose behavioral traits. It correctly indicates this is an importing action ('imports everything'), implying it may be data-intensive or slow. However, it does not state whether it is destructive (overwrites existing data), whether it requires network access, or how long it might take. The claim 'not just recent' adds useful scope but not operational detail.
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, fact-rich sentences with no wasted words. The first sentence provides the core action and resources, the second clarifies the scope. Each 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?
Given no output schema and no annotations, the description is somewhat sparse for a full-system scan. It lacks information about return values, potential side effects, and prerequisites. However, for a zero-parameter, conceptually simple tool, it covers the essentials of what and scope. A 3 is appropriate as adequate but with 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, and schema description coverage is 100% (no parameters to cover). The description adds meaning by explaining what the scan covers (all PRs + Shortcut cards) and the scope ('everything'), which is valuable context since there are no configurable options. This exceeds the baseline of 3 for a no-parameter 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 clearly states the tool performs a full scan of all PRs from configured GitHub repos plus Shortcut cards, using the verb 'scan' with specific resources. It distinguishes from an incremental/recent-only scan by saying 'imports everything, not just recent', but does not explicitly differentiate from the many sibling tools that also interact with PRs or data import.
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 alternatives. It does not mention prerequisites (e.g., must repos be configured first?), expected frequency, or when a partial scan would suffice. Without this, an agent might use it repeatedly in a session unnecessarily.
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 carries full responsibility for disclosing behavior. It only states that the tool lists all projects, implying a read-only operation, but does not mention authentication requirements, pagination, rate limits, or any other side effects. The lack of explicit behavioral details leaves the agent uninformed beyond the bare 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, short sentence with no extraneous words. It is front-loaded and immediately conveys the tool's purpose. Every word earns its place, achieving maximum conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters and an output schema is present (which presumably documents the return structure), the description adequately covers the core action and scope. It does not mention potential limitations like data freshness or whether the list is exhaustive, but for a simple listing of all projects, the description is sufficiently 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 and 100% schema coverage trivially. The description adds value by clarifying the scope ('all projects in the catalog'), which goes beyond the empty schema. Per the baseline rule for zero parameters, a score of 4 is appropriate because the description provides meaningful context about what is being listed.
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 'Lista todos os projetos do catálogo' clearly states the verb (list) and resource (projects in catalog), distinguishing it from sibling tools like graph.project.create and graph.project.update. The scope 'todos' (all) is explicit. However, the description is in Portuguese while the tool name and schema are in English, which may reduce clarity for non-Portuguese-speaking agents, but the intent remains 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?
No guidance is provided on when to use this tool compared to alternatives. With many sibling listing tools (e.g., memory.query, graph.catalog.export_csv), the description offers no context about appropriate use cases, exclusions, or conditions under which this should be preferred.
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 full responsibility. It only says 'cria' (creates) but does not disclose idempotency, overwrite behavior, failure conditions, or required permissions. For a mutation tool, more behavioral context is needed.
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 efficiently structured: first sentence states purpose, second gives usage guidelines, third provides an example. No redundant words; every sentence adds value.
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 clear purpose and usage guidance, the description omits explanation of optional parameters and does not address what the tool returns (no output schema) or behavioral details like duplicate handling. For a tool creating an entity, this leaves gaps in agent understanding.
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% leaving 6 parameters undocumented. The description's example explains the role of `project`, `task_type`, and `steps`, but ignores `tags`, `preconditions`, and `tools_required`. This partial compensation is insufficient for a low-coverage 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 clearly states the purpose: 'Cria um PROCEDIMENTO reutilizável (passo-a-passo) para um tipo de tarefa.' It uses a specific verb and resource, and distinguishes from siblings like memory.upsert and memory.episode.create by explicitly stating what not to use it for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: 'Use when: o conhecimento é uma sequência de passos repetível (runbook, how-to). Do NOT use for: regra/fato estático (memory.upsert); registro de um evento único (memory.episode.create).' It names alternative tools and defines clear criteria.
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?
No annotations are provided, so the description must carry the full burden. It discloses that the result may be 'no_memory', that it passes through admission gates, and that dry_run only shows proposals. It also clarifies the hook should not block commits. This is good behavioral context for a tool with 20 parameters.
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 relatively concise at 4 sentences, covering purpose, usage timing, and behavioral notes. It is front-loaded with the core action. However, it could be slightly more structured (e.g., bullet points) for clarity, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (20 parameters, no output schema, no annotations), the description lacks parameter explanations and return value details. It provides essential behavioral context but misses details about how parameters interact or what the output contains, making it only partially complete for an agent to invoke correctly.
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. However, it does not explain any of the 20 parameters, leaving the agent to infer from names alone. The baseline for 0% coverage is low, and the description adds no parameter-level meaning, so a 3 is generous given the high parameter count.
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' (verifies) and identifies the resource as 'memória durável a partir da sessão e do commit/PR atual'. It distinguishes from siblings like memory.get or memory.query by clarifying it captures memory after a commit/PR, focusing on session context. However, it could be more explicit about the output format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: 'depois de concluir um commit ou PR quando houver contexto da sessão para explicar intenção e impacto'. It also mentions that returning 'no_memory' is correct and not to block commits, which provides clear usage boundaries. However, it does not explicitly name alternatives among 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. It describes the creation action but does not disclose behavioral traits such as idempotency, side effects, or constraints (e.g., what happens if the PR already exists). The example usage helps, but transparency is average for a creation 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 concise: a one-sentence purpose, a usage guideline, and an example. Every sentence adds value, and the structure is front-loaded with the most important information. No wasted words.
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's complexity (18 parameters, 0% schema coverage, no output schema, no annotations), the description is incomplete. It covers the core use case and a few parameters but fails to explain most parameters, return values, or side effects. The example is helpful but insufficient for a tool with such a large parameter set.
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 mentions only a few parameters in the example (project, repo, pr_number, title, summary, changed_files, pr_url, work_item_url) and notes that two are required. The remaining 8 optional parameters (e.g., areas, branch, status, authors, merged_at, objective, event_date, work_item_id, work_item_summary, work_item_provider) are entirely undocumented, leaving their semantics unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Cria memória a partir de um Pull Request (PR + work item linkados).' It also explicitly distinguishes from siblings by listing when NOT to use it (memory.upsert, memory.episode.create), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: 'Use when: persistir o que um PR mudou e por quê; ligar PR a work item. Do NOT use for: regra/decisão genérica (memory.upsert); evento sem PR (memory.episode.create).' It also states that pr_url and work_item_url are required, offering clear context for selection.
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 must carry the behavioral burden. It mentions 'loop de pós-task' and persistence but does not detail what the loop does, whether the operation is destructive or reversible, or what exact side effects occur. The behavioral picture is partial.
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 concise with two sentences plus usage guidelines and an example. It is well-structured: purpose, usage, do-not-use, allowed outcomes, example. Minor reduction for being slightly verbose in the example, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description is incomplete. It covers the high-level purpose and usage but lacks details on parameter semantics, return value, and behavioral nuances like the 'loop de pós-task'. It is adequate 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%, so the description must compensate. It only mentions the parameters in an example and lists outcome values, but does not explain the meaning of 'changes', 'task_description', or how 'project' is used. This leaves significant gaps in understanding the 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 clearly states the tool extracts knowledge from a completed task and persists it. It explicitly distinguishes from sibling tools like memory.query (retrieve) and memory.context (pre-task), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use ('terminou um trabalho') and when-not-to-use ('RECUPERAR conhecimento', 'pré-task'). Also lists the outcome enum values and includes a concrete example, giving the agent clear guidance on proper invocation.
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 must carry the full burden. It mentions one behavioral constraint (alternatives_considered requirement for ArchitecturalDecision) and the project derivation behavior. However, it does not disclose mutation effects, idempotency, permissions, rate limits, or what happens on conflicts—significant gaps for a creation 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 well-structured: purpose, usage guidelines, constraint, example, and optional behavior note. Every sentence adds value; no wasted words. The example demonstrates the most typical parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 17 parameters, no output schema, and no annotations, the description covers the core use case and required fields adequately but leaves many optional parameters unexplained. The agent can invoke the tool correctly for basic cases but lacks guidance on the full parameter set.
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 add meaning beyond field names. It only explains category, title, summary, project, and alternatives_considered (5 out of 17 parameters). The other 12 parameters have no elaboration, leaving the agent without guidance on their purpose or format.
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 creates structured memory with explicit categories (DesignRule, BusinessRule, ArchitecturalDecision, DesignPattern). It distinguishes from sibling tools by listing alternatives (memory.upsert, memory.pr.create, etc.) and specifying when not to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Use when' and 'Do NOT use for' sections with specific alternative tool names. The description also notes that ArchitecturalDecision requires alternatives_considered, providing clear context for when this tool is appropriate vs. others.
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?
No annotations provided, but description discloses search behavior (semantic + graph), hyde expansion option, and project scoping. It implies read-only nature through the word 'retrieve'. Could mention that it doesn't modify data, but for a query tool this is acceptable.
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 concise with separate sections for purpose, usage, special features. Could be better structured with bullet points, but it's front-loaded and each sentence adds value. No wasted words.
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 an 8-parameter tool with 0% schema coverage, the description covers only purpose, usage, and two parameters. It lacks parameter explanations for most options, making it incomplete. Output schema exists, but parameter semantics are critical 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%, yet description only explains 'hyde' and 'project' parameters briefly. Six other parameters (type, top_k, min_weight, query_text, memory_scope, memory_branch) are left undocumented. The default values and titles provide minimal info, but the description should compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'semantic + graph search of project memories, the standard way to retrieve'. It specifies the verb 'search/retrieve' and resource 'memories', and distinguishes from siblings like memory.get and memory.query_at.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance: 'Use when: answering how/why/what about a project; retrieving rules, decisions, patterns. Do NOT use for: getting a single memory by ID (memory.get); point in time (memory.query_at); building context package (memory.context).' Also explains when to use hyde=True for short/vague queries.
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?
No annotations are present, so the description bears full responsibility. It mentions idempotence and the 'admission' logic (create vs refine). However, it does not disclose details like overwrite vs merge behavior, required permissions, rate limits, or error handling. For a mutation tool, this is good but not exhaustive.
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 front-loaded with purpose, but it mixes Portuguese and English, which may confuse an agent expecting consistent language. The structure is logical (purpose, usage, example) but could be more streamlined and monolingual.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 7 parameters, no output schema, and many siblings, the description covers purpose and usage well but lacks return value description, full parameter details, and potential side effects. It is adequate for basic use but leaves gaps for an agent to operate reliably.
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 only partially covers parameters (project, category, title, summary via example) and omits explanation of domain, details, weight_manual, and any constraints or allowed values. The example helps but is insufficient for 7 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates/updates canonical memory idempotently and positions it as the standard save method. It distinguishes from many sibling tools by naming specific tools not to use (memory.pr.create, memory.procedure.create, etc.), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Use when' and 'Do NOT use for' sections list concrete scenarios and alternative tools. It advises calling memory.find_duplicates beforehand to avoid duplicates, providing actionable guidance. This is exceptional context for an agent to choose correctly.
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?
No annotations exist, so the description must disclose behavior. It conveys that the tool pre-loads relevant contextual knowledge before starting a task, which implies it is a read-heavy, non-destructive operation. However, it does not explicitly mention whether the operation is read-only or if it has side effects like caching or logging. Still, the intended behavior is well communicated.
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 concise, front-loading the core purpose in the first sentence. The use/when-not example is efficient. Small verbosity due to mixing Portuguese and English, but it remains brief.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (2 nullable params, no output schema, no annotations), the description adequately explains what the tool does and when to use it. However, it lacks details on return value (what is in the 'pacote'? format/pagination?) and whether the operation has side effects beyond the agent's context. This leaves some ambiguity for complete automation.
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 has 2 parameters (domain, project) both nullable and with defaults, and schema description coverage is 0%. The description adds a usage example with both parameters, which provides usage context beyond the schema. However, it does not describe each parameter's meaning or constraints individually. With no schema descriptions, the baseline is 3, and this example marginally meets 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 opens with a strong verb+resource: 'Monta um PACOTE de contexto (regras/padrões/decisões)'. It unambiguously distinguishes this tool from siblings like memory.query and memory.reflect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use ('vai iniciar um trabalho...') and when NOT to use, naming specific sibling alternatives (memory.query, memory.reflect). This provides clear decision logic for tool selection.
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 must carry the full burden. The description implies it's a write operation (creating a record) but does not disclose whether it's idempotent, whether it can overwrite existing episodes, any authentication requirements, or side effects on other memory entities. The example shows a basic usage pattern but doesn't cover behavioral edge cases.
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 with three short sentences: a definition, usage guidance with alternatives, and an example. Every sentence adds value, no redundancy, and the structure is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters (1 required), no output schema, and no annotations, the description does a good job clarifying the purpose and usage. However, without an output schema or return value description, an agent might not know what the tool returns after creation. The example helps but doesn't fully compensate for the missing output schema.
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. The description provides a concrete example (project='CORE', task_description='Migrei PLD', outcome='completed', lessons=['...']) that maps to schema parameters, but it does not explain all 8 parameters (e.g., tags, approach, occurrence_id, related_memory_ids). The example gives a good starting point but leaves some parameters undocumented.
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 explicitly states the tool registers an EPISÓDIO, defined as 'what was done in a specific task and the result'. It clearly distinguishes this from other memory tools like memory.upsert and memory.procedure.create by specifying the type of information captured (unique event vs. timeless knowledge vs. reusable procedure).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit 'Use when' and 'Do NOT use for' guidance, directly naming sibling tools memory.upsert and memory.procedure.create as alternatives. This gives an agent clear decision criteria for when to invoke this tool versus others.
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?
Discloses key behavior: pipeline handles extraction/classification/persisting autonomously. Notes cost (LLM extraction). With no annotations, the description carries full burden; it covers the main behavioral traits but omits potential side effects or required permissions.
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?
Content is front-loaded with imperative instruction, usage guidance follows, then example. Every sentence adds value. Could condense slightly (e.g., remove 'com' contractions for international agents) but not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (4 params, no output schema), the description covers the use case, parameter roles, and when not to use. Lacks explicit return value description (what does user get back?) and does not mention error handling for missing/invalid source_kind.
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 has 0% description coverage, so the description must compensate. It adds meaning for all 4 params: explains 'source_kind' (e.g., 'slack'), 'payload' as text, 'project_hint' as optional override with default behavior (derive from workspace). 'domain_hint' is not explained but is optional/nullable.
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 the verb 'ingere' (ingest) and the resource (raw text/blob), includes an explicit use case, and distinguishes from siblings like 'memory.upsert' and 'memory.manual.create'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (unstructured blob) and when NOT to use (structured content), names alternatives (memory.upsert/memory.manual.create), mentions cost trade-off (LLM extraction), and provides an example.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 transparently explains that the tool performs a similarity search (list), describes the threshold behavior with calibration details for different embedding models, and notes that omitting the project parameter uses the agent workspace folder. There is no contradiction with annotations (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 concise and front-loaded. The first sentence states the core purpose and critical usage instruction ('Chame ANTES'). Every subsequent sentence adds value—threshold calibration, parameter guidance, and sibling references. There is no redundant or extraneous text.
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?
Given the tool's complexity (6 parameters, many sibling tools, and an output schema), the description provides sufficient context for an agent to select and invoke this tool correctly. It explains the primary use case (duplicate detection), how to set the threshold, and how to use the result with other tools. The output schema exists, so detailing return values is not required. The missing parameter descriptions are a minor gap but do not undermine overall contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for three of six parameters: 'text' as title+summary of intended memory, 'threshold' with calibration values, and 'project' as optional with agent workspace default. However, it provides no explanation for 'type', 'memory_scope', and 'memory_branch', leaving a gap for those parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists similar memories with a minimum similarity threshold, and ties it to the purpose of avoiding duplicates. It distinguishes from siblings by explicitly mentioning that it should be called before creating a memory and referencing sibling tools like memory.upsert and memory.manual.create for further action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Chame ANTES de criar p/ evitar duplicatas'. It also gives clear alternatives based on the result: create new via memory.upsert or memory.manual.create, or refine existing via search-before-write. This directly informs the agent's decision-making.
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 fully carries the burden of behavioral disclosure. It explains that this is a direct lookup (not a search), which implies it is idempotent, fast, and does not modify state. It is transparent about its behavior beyond what any structured field would provide.
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, consisting of three short but dense sentences. It front-loads the core purpose, follows with usage rules, and ends with an example. Every sentence is essential and efficient.
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?
Given the tool's simplicity (1 required parameter, no output schema, clear sibling relationships), the description is complete. It tells the agent everything needed to use the tool correctly, including prerequisites, exclusions, and a usage example. No additional context is necessary.
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 description explains the meaning of the single parameter 'memory_id' by specifying its form ('exato') and providing a concrete example value. Even though the schema covers 0% of the description, the description fully documents the parameter's purpose and usage, adding significant value.
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 action ('Recupera UMA memória'), the specific resource ('memory_id exato'), and the method ('lookup direto, sem busca'). It distinguishes itself from sibling tools like 'memory.query' by emphasizing its direct, ID-based nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool ('já tem o memory_id') and provides a clear 'Do NOT use for' clause ('busca por tema (memory.query)'). It also gives a concrete example, making the usage guidance thorough and actionable.
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 present, the description carries the full burden. It clearly states that the tool performs a query (not mutation) and has bitemporal semantics. However, it does not disclose potential performance implications (e.g., time-travel queries may be slower) or access control, which would elevate it to 5. Still very strong.
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?
Four sentences, zero waste. The first sentence gives the purpose, the second gives usage guidelines, the third gives an exclusion warning, and the fourth provides a concrete example. Maximally efficient.
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?
Given the output schema exists, return values need no explanation. The tool has 6 params but only 1 is required, and the description explains the key param (point_in_time) and one filter (project). For a read query tool with clear sibling differentiation, this is contextually 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?
With schema coverage at 0%, the description must compensate. The example usage 'memory.query_at(project='CORE', point_in_time='2026-01-01T00:00:00Z')' clarifies the format for the required point_in_time parameter and shows how the optional project filter works. The description also implies that point_in_time is an ISO 8601 timestamp. However, other parameters like category, memory_scope, memory_branch, and limit are not explained, which prevents a 5.
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 verb+resource: 'Consulta memórias que estavam ATIVAS num instante passado' (queries memories active at a past point in time). This clearly distinguishes it from the sibling memory.query (current state). The reference to bitemporal ISO 8601 further specifies the temporal nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Use when: auditoria / reconstruir estado histórico' and 'Do NOT use for: estado atual (memory.query)'. This directly addresses when to use vs. the most similar sibling tool, with no ambiguity.
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:

[![DecisionsSearch MCP server](https://glama.ai/mcp/servers/Renzo-Tognella/DecisionsSearch/badges/card.svg)](https://glama.ai/mcp/servers/Renzo-Tognella/DecisionsSearch)

Score Badge

Copy to your README.md:

[![DecisionsSearch MCP server](https://glama.ai/mcp/servers/Renzo-Tognella/DecisionsSearch/badges/score.svg)](https://glama.ai/mcp/servers/Renzo-Tognella/DecisionsSearch)

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/Renzo-Tognella/DecisionsSearch'

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