engineering-mcp

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action (e.g., work_upsert_project vs work_upsert_ticket vs work_upsert_task). Lifecycle tools like investigate_open/add_finding/conclude and qa_record_run/record_bug are clearly separate, and the reporting and knowledge tools have unique roles. No two tools appear to do the same thing.
Naming Consistency4/5
The naming pattern is generally domain_prefix + verb_noun (e.g., work_upsert_ticket, qa_record_run). Minor deviations include 'work_list' lacking an explicit object, 'work_board' and 'time_metrics' using nouns as commands, and 'eng_route' not following the domain-prefix structure. Overall, it's predictable and readable.
Tool Count4/5
With 23 tools, the server is on the heavier side, but the count is justified by the breadth of domains covered (work, time, investigation, knowledge, QA, reporting, routing). Each tool serves a specific purpose, and the volume aligns with the comprehensive engineering management scope.
Completeness4/5
The tool surface covers the full lifecycle for tickets, tasks, projects, investigations, time tracking, and QA evidence, including reporting and knowledge handoff. Minor gaps include the absence of explicit delete or archive operations on tickets/projects, and no bulk actions, but these are not critical for typical workflows.
Average 3.2/5 across 23 of 23 tools scored. Lowest: 1.9/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
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description simply states 'lança tempo trabalhado' without explaining whether it appends to existing logs, requires pre-existing tickets/tasks, or how it handles timezone/validation. It is essentially a restatement of the tool's purpose and provides no additional behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is not a matter of conciseness but under-specification. It does not front-load key information about parameters or behavior, and every word simply restates the obvious from the name and title. It is appropriately short in length but fails to earn its place by omitting necessary details.
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?
For a tool with five parameters, no output schema, and no annotations, the description is woefully incomplete. It does not explain return values, constraints like required fields beyond schema, or any relationship between ticket_id and task_id. An agent has no way to correctly invoke this tool beyond guessing from the schema, which itself is sparse.
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 only 40%, and the description adds no parameter-level meaning. The schema itself documents 'hours' and 'logged_at', but the description doesn't elaborate on the meaning or constraints of any parameter. With five parameters and incomplete schema coverage, the description fails entirely to compensate, leaving agents blind to how to correctly fill note, task_id, or ticket_id.
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 'lança' (launches) and the resource 'tempo trabalhado em um ticket ou task' (worked time on a ticket or task), which clearly states the tool's function. However, it doesn't differentiate from the sibling 'time_estimate', which could be confused for similar functionality.
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 given on when to use this tool versus alternatives like 'time_estimate' or 'time_metrics'. The description provides neither explicit context nor exclusions, leaving the agent to infer the appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose whether the operation is read-only, what data it returns, how it aggregates metrics, or any side effects. While it implicitly suggests reading metrics, there is no explicit statement about behavior, response format, or expected 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.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (one short line), which makes it under-specified rather than appropriately concise. It front-loads the key concept, but it lacks essential detail that the tool requires given its three undocumented parameters and no other structured information. It is not over-wordy, but it is too sparse to be effective.
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?
For a tool with 3 parameters, no schema descriptions, no annotations, and no output schema, the description is completely inadequate. An agent would have no idea what the tool returns, whether it requires authentication, how to combine filters, or what the results look like. The definition is missing substantial context that is 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%, so the description must compensate for the undocumented parameters. The phrase 'por ticket, projeto ou global' gives a hint that ticket_id, project_id, and project_key are filtering options, but it does not explain each parameter individually, their optionality, or how they interact. The description adds minimal value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the resource (time metrics: estimated vs actual vs remaining) and the scoping options (ticket, project, global). It clearly distinguishes from sibling tools like time_estimate (logging) and time_log (recording), though the verb is implicit rather than explicit. Overall, a specific and understandable purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. It does not mention that time_metrics is for viewing metrics while time_estimate and time_log are for creation/recording, nor does it give any context on typical workflows. The agent is left to infer usage from the name and minimal description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It merely says 'visão kanban' (kanban view), implying read-only behavior but not stating what it returns (e.g., tasks grouped by stage), whether it filters by project, what happens if both project_id and project_key are missing, or any side effects. This is minimal and insufficient for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler, which is concise. However, it is so brief that it omits essential information. While there is no waste, the brevity borders on under-specification rather than effective conciseness, so a middle score is appropriate.
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?
For a tool with no annotations, no output schema, and zero parameter documentation, the description is grossly inadequate. It does not explain the returned structure, how to specify the project, or any prerequisites. An agent cannot reliably call this tool correctly based on the description alone.
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%, yet the description does not clarify the meaning of project_id or project_key. It only mentions 'de um projeto' (of a project), which vaguely suggests a project identifier but does not explain which parameter to use, whether they are alternatives, or their formats. The description adds no value beyond the raw parameter names.
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 provides a kanban view (backlog/todo/doing/review/done) of a project. While it lacks an explicit verb like 'get' or 'list', the noun 'visão' (view) clearly indicates a read-only retrieval of a project's board. It distinguishes from siblings like work_list (general list) and work_list_projects (project list) by focusing on kanban stages, so an agent can infer its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no context on when to use this tool versus alternatives like work_list or work_get. It does not state whether it is for a specific project scope, what parameters to use, or any conditions that would make this the preferred tool. Users are left to infer usage from the name and title.
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 behavioral burden. It only says 'cria/atualiza' without disclosing idempotency, side effects, permission requirements, or response format. Critical behaviors such as whether id is required for updates, or what happens if the ticket does not exist, are not mentioned.
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?
While the description is a single concise sentence, it is under-specified for a tool with 4 parameters and no annotations. It does not front-load critical usage or parameter details, making it more an under-specification than an efficient, complete summary.
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?
There is no output schema, no annotations, and low schema coverage. The description does not explain how the 'id' field differentiates create vs. update, the meaning of 'status' values, or any required preconditions. An agent cannot reliably call this tool correctly with only the provided information.
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 only 25% (only ticket_id has a description). The description itself adds no parameter information, failing to compensate for the low schema coverage. It does not explain the roles of id, title, status, or ticket_id, leaving the agent without essential 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 states a specific verb (cria/atualiza) and resource (task filha de um ticket), clearly distinguishing it from sibling tools like work_upsert_ticket (which handles tickets, not child tasks) and work_upsert_project. The phrase 'filha de um ticket' clarifies that this is a task nested under a ticket, removing 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. The description does not mention prerequisites (e.g., existence of a parent ticket) or conditions for create vs. update. It only states what the tool does, leaving the agent to infer usage context from the schema 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?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It indicates a write operation ('records or updates') but does not elaborate on whether it creates new estimates or overwrites existing ones, how the note parameter is handled, error conditions, or what happens on conflicts. This is insufficient for a mutation tool with zero annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
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 without any fluff. It is front-loaded with the action and resource. It earns its place, though it could be more informative without becoming overly long.
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 three parameters, no output schema, and no annotations, this description is sparse. It omits return values, behavior on update vs. create, parameter usage for 'note', whether the estimate is set absolutely or incrementally, and any prerequisites. An agent would lack critical context needed to call it correctly, especially since none of this is covered by annotations or an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33% (only 'hours' has a description). The description adds no additional meaning for 'ticket_id' or 'note'. It does reinforce that hours are in hours, but that is already in the schema. Given the low coverage, the description should compensate, but it does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('grava ou atualiza' – records or updates) and a clear resource ('a estimativa em horas de um ticket' – the hourly estimate of a ticket). This makes the tool's purpose clear and distinguishable from siblings like time_log (which likely logs actual time) or time_metrics (which retrieves metrics). However, it does not explicitly name or contrast any sibling, so it doesn't fully differentiate by itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No mention of scenarios, prerequisites, or which sibling to choose instead. The description only says what the tool does, leaving the agent to infer usage context from the name and schema alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral expectations. It merely states an action (adding a finding) without disclosing side effects, permissions, whether the investigation must be open, or how the finding is recorded. This is a minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant information. It fronts the action and scope, achieving high 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 mutation tool with 3 parameters, 2 required, no annotations, and no output schema, this description is inadequate. It omits required fields' semantics, error conditions, success behavior, and any preconditions beyond the implied 'open investigation'. An agent has to infer too much.
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 explicitly lists the allowed 'kind' values (observation, evidence, hypothesis, decision) and implies 'investigation_id' refers to an open investigation. However, it does not clarify 'body' or any constraints on it, leaving some parameters 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 states a clear verb (adiciona) and resource (observação, evidência, hipótese ou decisão) to an open investigation. It is specific enough to distinguish from sibling tools like investigate_open or investigate_conclude, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus investigate_conclude or investigate_list. It does not mention any prerequisites, exclusions, or alternative 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?
No annotations are provided, so the description must carry the behavioral burden. The description only states it lists investigations, but doesn't disclose details like pagination, ordering, or return format. It doesn't even state that it's a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that front-loads the purpose with the 'INVESTIGATION:' prefix. There is no unnecessary verbosity. It is appropriately sized for a simple list 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?
For a simple list tool with no output schema and no annotations, the description is insufficient. It doesn't describe the output structure, any limitations, or whether it returns all investigations or paginated results. An agent would have to infer behavior from the name.
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 description mentions optional filtering by ticket or status, providing context that the two parameters are filters. However, it doesn't explain the enum values for status or the format for ticket_id. With 0% schema coverage, the description partially compensates but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb 'lista' (lists) and resource 'investigações' (investigations) with optional filters by ticket or status. However, it doesn't explicitly differentiate from sibling tools like investigate_open or investigate_conclude, though the name itself suggests a general listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is given. The description doesn't mention when to use this over other investigate_* tools, nor any exclusions or alternatives. The agent is left to infer appropriate use 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?
No annotations are provided, so the description carries full responsibility for disclosing behavior. It only states that it attaches evidence, but does not disclose side effects, permission requirements, reversibility, or how the attachment is stored. The description adds minimal behavioral context beyond what the tool name implies.
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 with no filler. It is efficiently written, but it errs on the side of underspecification rather than concise completeness. Still, for the dimension of conciseness, it scores well.
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 6 parameters, low schema coverage, and no output schema, the description is far too minimal. It does not explain the interdependency of target IDs (bug_id, run_id, ticket_id), the meaning of 'kind', or the required path_or_url semantics. An agent cannot confidently call this tool correctly based on the description alone.
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 only 17%, with only path_or_url documented in the schema. The description does not compensate for this gap: it vaguely references 'log, screenshot, report, URL' which correspond to kind values, but does not explain how to use kind, note, bug_id, run_id, or ticket_id. This is insufficient for correct parameter usage.
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 function: attaching logs, screenshots, reports, or URLs to a ticket, bug, or run. It names the specific verb (anexar), the resource types (evidência), and the target entities (ticket, bug, run), which effectively distinguishes it from sibling tools like qa_record_bug or qa_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any selection criteria, prerequisites, or exclusions. An agent would have no basis to choose this over other QA 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that tickets are listed with filters, but does not reveal pagination, sorting, default limits, whether the query text searches title/description, or how multiple filters combine. This leaves an agent guessing about the operational behavior of 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It front-loads the main action and filter dimensions. However, it is almost too sparse, bordering on under-specification rather than efficient conciseness, but given the low word count it earns a strong score for structure.
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 5 optional parameters with enums, no output schema, and no annotations. The description only gives a vague overview of filtering capabilities, missing critical context such as return format, pagination behavior, and any constraints on combining filters. Sibling tools are numerous, and the description does not help an agent decide when this tool is appropriate. It is far from complete given the complexity.
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 filters by project, status, type, and text, which loosely maps to parameters like project_id/project_key, status, type, and query. However, it does not explain the meaning or format of each parameter, does not differentiate project_id from project_key, and does not clarify how the query parameter works. The high-level list is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists tickets, with explicit mention of filter dimensions (project, status, type, text). The verb 'lista' and resource 'tickets' are specific, and the mention of filters distinguishes it from sibling tools like work_list_projects (which lists projects) and work_get (which retrieves a single ticket).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or contrast with siblings like work_board or work_get. The intended use is only implied by the phrase 'lista tickets com filtro', which is not enough to differentiate selection conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of behavioral disclosure. The qualifier 'local' indicates a scope constraint, and listing implies a read-only operation, but there is no explicit statement about side effects, authorization requirements, or return format. It adds minimal behavioral context beyond the action itself.
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, and the 'WORK:' prefix provides immediate category context. However, the brevity comes at the cost of missing useful details, so it is concise but not optimally structured for agent guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter, the description is minimal. It does not mention the status filter, describe the return structure (no output schema), or clarify what 'local' means in the context of the system. An agent would lack crucial usage context, especially given the presence of many related sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one optional parameter 'status' with an enum, and the description does not mention it at all. Schema description coverage is 0%, and the description fails to compensate by explaining how status affects results. While the enum is self-explanatory, the description adds no value beyond what the schema already provides.
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 projetos locais' which is a specific verb-resource pair, clearly indicating it lists local projects. However, it doesn't explicitly differentiate from siblings like work_list or work_board, leaving some ambiguity about scope. The qualifier 'local' adds a useful distinction, so it's above a tautology but lacks full 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?
No guidance is provided on when to use this tool versus alternatives. There is no mention of when to prefer this over work_list, work_board, or other project-related tools, nor any exclusions or conditions. The agent is left to infer context from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. The word 'snapshot' implies a read-only, non-destructive operation, which is a useful behavioral cue. However, it does not explicitly state that it is read-only, nor does it mention any permissions, rate limits, or potential side effects. The description adds some value but leaves the safety profile implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded line that conveys the core purpose and content in a compact form. Every word earns its place; there is no filler or repetition. It is appropriately sized for a reporting 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?
The description is incomplete for an agent to call this tool correctly. It does not state how to identify the project (project_id vs project_key), whether the snapshot includes all projects by default, what the output looks like (no output schema is provided), or how the 'days' parameter filters QA runs. These are essential details for correct invocation, and the description omits them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 3 parameters but only 'days' has a description (coverage 33%, below the 50% threshold). The description itself never mentions any of the parameters—it does not explain what project_id or project_key are, whether one is required, or how 'days' affects the snapshot. The description fails to compensate for the schema's sparse documentation, leaving the agent to guess parameter usage.
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: 'REPORTING: snapshot do projeto' followed by a specific list of contents (board counts, time, recent failures, bugs, open investigations). This distinguishes it from sibling tools like report_ticket, time_metrics, or investigate_list, which focus on individual aspects. The verb 'snapshot' plus resource 'project' makes the intent 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?
The description gives no guidance on when to use this tool versus alternatives. It does not mention that it aggregates status for a quick overview, nor does it exclude cases where more specific tools (e.g., time_metrics, investigate_list) would be preferred. Without this context, an agent might select it inappropriately or miss it when needed.
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. It states it creates/updates tickets, but it does not explain side effects: whether updates overwrite all fields or only provided ones, whether creation requires specific fields, or what the response contains. Since it is a mutation tool (upsert), the lack of these details is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no fluff. It front-loads the core purpose ('cria/atualiza ticket'), lists relevant types, and gives a key usage hint. Every word adds value, making it a model of efficient writing.
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 complexity (9 parameters, no required fields, low schema coverage, no output schema, and no annotations), the description is markedly incomplete. It does not specify what fields are necessary for creation, what happens on update (e.g., partial or full overwrite), or what the tool returns. An agent would have to open the schema and still miss the behavioral semantics. This is insufficient for a mutation tool with such a parameter surface.
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 only 44%, so the description needs to compensate for the missing parameter explanations. It adds clarity for 'id' (format KEY-N, use for status update) and implicitly mentions the 'type' via the list of ticket types, but it does not explain other parameters like 'status', 'priority', 'title', or 'description'. It partially compensates but leaves many parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates/updates tickets and lists the ticket types (story, bug, task, spike, epic). However, it does not explicitly differentiate itself from the sibling tool 'work_upsert_task', which could lead to confusion. The verb+resource is clear, but the lack of distinction from a closely named sibling prevents a perfect score.
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 instruction 'Passe id para atualizar status' provides some guidance on when to pass an id (update) versus when to create, implying the conditional usage. However, it does not mention any alternative tools or when NOT to use this tool, leaving the routing between work_upsert_ticket and work_upsert_task ambiguous. There is no explicit exclusions or alternatives, so it is adequate but not complete.
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 disclosure. It states it will close the investigation and save knowledge, which are significant side effects. However, it does not disclose whether closing is irreversible, what happens to existing findings, or any prerequisites like permissions. It adds some context but lacks depth for a mutation-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 extremely concise, with two short phrases in Portuguese. It front-loads the primary action ('fecha com causa raiz e classificação') and mentions the secondary action ('gravar knowledge'). The brevity is efficient, but it sacrifices essential parameter and behavior detail, making it borderline between efficient and 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?
For a tool with 4 parameters, 1 enum, and no output schema, the description is incomplete. It does not explain the optionality of parameters, the meaning of the classification values, or what the tool returns or how knowledge saving works. An agent would lack critical information to invoke this tool correctly and understand its side effects, despite the brief guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'causa raiz e classificação' which maps to root_cause and classification, but omits hypothesis and investigation_id entirely. It also does not explain the classification enum values or that only investigation_id is required. This is insufficient for an agent to correctly fill parameters without looking at the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to conclude an investigation with a root cause and classification, and then save knowledge. The verb 'fecha' (close) with 'causa raiz e classificação' specifies the action and resource. It implicitly differentiates from siblings like investigate_open and investigate_add_finding by focusing on the conclusion phase.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage is when an investigation is complete and needs to be closed with findings and knowledge saved. However, it does not explicitly mention when not to use it or alternatives such as investigate_add_finding for intermediate steps. No clear guidance on selecting this over sibling tools, but the context is inferable.
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. It implies creation ('abre') and mentions crossing WORK + QA, but does not disclose side effects, permissions, reversibility, or response behavior. This is insufficient 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with no wasted words, and the key scoping ('Cruza WORK + QA') is front-loaded. The 'INVESTIGATION:' prefix is slightly redundant but does not hurt. It efficiently conveys purpose and a routing hint.
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 creation tool with 4 parameters, no annotations, and no output schema, this description is incomplete. It does not explain what the tool actually creates, what the response looks like, or how parameters interact (e.g., whether ticket_id or bug_id must be present). It also does not distinguish from other investigate tools well enough.
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 hints that bug_id and ticket_id are used for linking, but does not explain title, hypothesis, or their formats/relationships. Parameter semantics are largely left to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('abre uma investigação (RCA)') tied to a resource (ticket/bug) and clearly differentiates from siblings by mentioning the QA-oracle alternative for CI/Jira logs. It is not a tautology and provides concrete scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context: opening an RCA linked to ticket and/or bug, and even names an explicit alternative (qa-oracle) for CI/Jira logs. However, it does not mention exclusions or when not to use this tool relative to other investigate steps like investigate_add_finding or investigate_conclude, so it's not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions 'Local memory (FTS)', which indicates storage location, but does not clarify whether it creates new entries or can overwrite existing knowledge, nor does it mention permissions, side effects, or error conditions. It provides some context (local full-text search memory) but lacks depth expected for a write 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 concise, using two short sentences with no fluff. The 'KNOWLEDGE:' prefix front-loads the domain, and the core action is stated immediately. It is efficient, though its brevity contributes to the thin parameter and behavioral coverage.
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 6 parameters (2 required), no output schema, and no annotations, the description is notably incomplete. It does not explain required fields (title, body), the role of optional parameters, or what happens after saving. An agent would struggle to construct a correct call without additional information.
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 vaguely references the kind enum ('playbook, lição ou padrão'), but does not explain the required title and body fields, or the purpose of tags, ticket_id, or investigation_id. This leaves agents without guidance on how to populate the parameters correctly.
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 records playbook, lesson, or pattern from an investigation ('grava playbook, lição ou padrão a partir de uma investigação'). It specifies the verb and resource, and the context distinguishes it from knowledge_search (which searches) and investigate_* tools (which manage investigations). The 'KNOWLEDGE:' prefix further signals its domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used after an investigation to save knowledge, but it does not explicitly state when to use it versus alternatives like knowledge_search or when not to use it. No sibling names are mentioned, and the 'from an investigation' clause is the only usage hint. This is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It only says 'busca' (search), implying a read-only operation, but does not explicitly state safety, return format, pagination, or any limitations. This is a significant gap for a tool with no annotation coverage.
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 brief and front-loaded, conveying the core purpose and usage hint in two short sentences. The 'KNOWLEDGE:' prefix is mildly redundant but not harmful; overall it is appropriately sized 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?
For a search tool with no output schema and no annotations, the description should clarify return behavior, pagination, and the meaning of 'limit'. It only mentions searching by text and a usage context, leaving essential operational details missing, making it incomplete for an agent to call correctly without further assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%; only 'query' has a description ('Texto livre. Vazio = mais recentes.'), which already exists in the schema. The tool description adds no additional meaning for 'query' and says nothing about 'limit'. The 50% coverage requires the description to compensate for the undocumented 'limit' parameter, which it fails to do.
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 searches playbooks/lessons by text ('busca playbooks/lições por texto'), using a specific verb and resource. It distinguishes from the sibling knowledge_save by the action (search vs. save) and mentions the context of 'reabrir bug parecido', making its 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit usage instruction: 'Use antes de reabrir bug parecido' (use before reopening a similar bug). This gives clear contextual guidance for when the tool is appropriate, though it does not explicitly state when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It implies a read-only aggregation ('junta') but doesn't explicitly state side effects, permissions, or output characteristics. It adds context about the data sources involved, which is useful, but omits safety or behavior expectations. There is no contradiction with annotations since none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with 'REPORTING' to set context. It lists components and use cases efficiently without wordiness. Structure is clear and scannable, though the parameter explanation is missing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that aggregates data from multiple domains, the description gives a high-level overview but lacks details on prerequisites (e.g., must have existing work/QA data), output format, or any constraints. Without an output schema, the description should at least note what the report returns. The use cases help, but the description leaves some gaps for an agent to fully understand the tool's behavior.
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% – the schema only defines 'ticket_id' as a string with no description. The tool description doesn't mention the parameter at all, so it adds no meaning beyond the schema. For a single simple parameter this is less critical, but the description could have clarified its format or purpose, and fails to compensate for the schema gap.
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 ('junta' – gathers) and resource ('ticket'), and enumerates the combined components (WORK, QA, TIME, INVESTIGATION, KNOWLEDGE). It clearly distinguishes from a simple status report by framing itself as a complete package, though it doesn't explicitly name alternatives. The purpose is clear and specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use para status, handoff ou evidência' explicitly gives three use cases, guiding when to invoke this tool. It doesn't provide explicit when-not-to-use or alternatives, but the context is adequate for a single-purpose aggregation 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. It only states that the tool creates or updates a project, but does not explain side effects (e.g., id derivation, default statuses, whether updates are partial or full, deletion behavior, or output format). For a mutation tool with zero annotation coverage, 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, efficient sentence that front-loads the action and purpose. It is concise and contains no wasted text, though it could include more behavioral detail without violating 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 create/update tool with 5 parameters, no output schema, and no annotations, the description is incomplete. It does not explain parameter semantics, edge cases (e.g., id requirement, archive behavior), or what the tool returns. The single hint about tickets ('Use antes de abrir tickets') is insufficient for an agent to invoke it correctly in all scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add meaningful parameter semantics. With schema coverage at 60%, the missing descriptions for 'status' and 'description' are not compensated by the description. It also does not clarify the relationship between parameters (e.g., that 'name' is required on creation, or how 'id' is derived). The description adds no value beyond the high-level purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('cria ou atualiza') and a specific resource ('projeto de engenharia') with examples (app, backend, QA lab). It clearly distinguishes from sibling tools that handle tickets (work_upsert_ticket) and tasks (work_upsert_task). The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: 'Use antes de abrir tickets' (use before opening tickets). This gives a practical scenario. However, it does not explicitly mention when not to use this tool or recommend alternatives for listing or viewing projects, though the purpose itself differentiates from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'records a local bug' without mentioning persistence, side effects, overwrite behavior, authentication, or response format. For a mutation tool 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded purpose, and an explicit alternative. No filler or redundant phrasing – every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 6 parameters, no output schema, and no annotations, the description is too sparse. It does not explain what the required 'title' should be, how status values relate to the bug lifecycle, what ticket_id refers to, or what the tool returns. An agent would struggle to invoke it correctly with confidence.
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 only 17% (only status has a description). The description mentions severity and classification but does not explain title, status, ticket_id, or description beyond what the schema provides. Since coverage is low, the description fails to compensate and leaves most parameters semantically underdocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (records) and resource (local bug) and names the key alternative (qa-oracle's search_bug_history), making it distinguishable from the corporate Jira history tool. The phrase 'severity + classification' adds clarity on the main fields involved.
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 instructs when not to use this tool: 'Para histórico Jira corporativo use o MCP qa-oracle (search_bug_history).' This provides a clear when-not and names the alternative tool, which is exactly what this dimension rewards.
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 behavior. It states the tool 'routes' a task, but it is ambiguous whether it actually executes the task in the target domain or merely identifies/returns the domain. There is no mention of side effects, whether it is a read-only operation, or what the output looks like. This ambiguity is a significant gap for a mutating-capable tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the purpose and enumerates the domains without any redundant words. It is concise and effectively structured for quick comprehension.
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 only one parameter and no output schema, the description leaves out critical operational details. An agent needs to know what happens after routing: does the tool return a domain label, an instruction set, or does it invoke another tool? Without annotations or an output schema, this ambiguity means the description is not complete enough for the agent 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 input schema already documents the 'task' parameter at 100% coverage. The description adds value by listing the possible domains, giving the agent a concrete sense of what the task string will be classified into, which goes beyond the schema's minimal description.
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 function: routing a natural language task to the correct domain, and explicitly enumerates the six possible domains (work, qa, time, investigation, knowledge, reporting). This is a specific verb+resource with clear scope, and it distinguishes itself from sibling tools which are domain-specific actions.
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 implicitly conveys when to use this tool: when you have a natural language task and need it routed to the appropriate domain. It does not explicitly mention alternatives (like using domain-specific tools directly) or exclusions, but the context of sibling tools makes the use case clear. No conflicting guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. The verb 'lista' implies a read-only operation without side effects, and the description does not contradict that. However, it does not explicitly state 'read-only' or describe any limitations (e.g., pagination, sorting, or behavior when ticket_id is not found). For a simple list tool, this is minimally transparent but leaves behavioral details unstated.
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 compact two-clause sentence: the main purpose is front-loaded ('QA: lista runs, bugs e evidências'), and the filter detail follows. Every word earns its place, with no redundancy or filler. This is exemplary conciseness for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity—one optional parameter, no output schema—the description covers the essential actions and the filter. It does not specify the return structure (e.g., that it returns a list of objects with fields), but for a list tool this is reasonably implicit. It could add a note on the output format, but overall it is sufficiently complete for an agent to call it correctly for typical use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% (no descriptions in the schema), so the description must compensate. It does: 'Filtra por ticket_id se informado' explicitly explains that the parameter filters results and that it is optional. This adds meaning beyond the bare schema definition of a string field. It could be more detailed (e.g., format or example), but it adequately clarifies the parameter's role.
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 specific verb 'lista' (lists) and the resource: runs, bugs, e evidências (runs, bugs, and evidence). It clearly distinguishes from the recording tools (qa_record_run, qa_record_bug, qa_attach_evidence) by being a read/list operation. The optional filtering by ticket_id is also mentioned, 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: to list QA items. The phrase 'Filtra por ticket_id se informado' provides clear context for the optional filter. However, it does not explicitly name alternatives (e.g., 'use qa_record_run to add a run') or state exclusions, so it's clear but not fully explicit about when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that it does not execute tests and points to qa-lab-agent for that, which is helpful. However, it does not disclose potential side effects like modifying the linked ticket or requiring specific permissions, which a write operation typically needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action and then the exclusion. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple record tool, the description covers the essential: what it does, that it writes (implies), and that it doesn't run tests. It lacks details on side effects or return, but given the simplicity and no output schema, it's mostly complete. Still, it could mention prerequisites like having a ticket ID.
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 describes 60% of parameters (suite, source, status), and the description repeats the status enum and mentions linking to a ticket, which gives context for ticket_id. However, it does not explain summary or ticket_id beyond the schema, and with 60% coverage it only partially compensates for undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb 'grava' (records) a test run (pass/fail/flaky/blocked) linked to a ticket, and explicitly differentiates from qa-lab-agent that executes tests. This clearly distinguishes it from sibling tools like qa_record_bug or qa_attach_evidence.
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 says 'Não executa testes — para rodar, use o MCP qa-lab-agent', which tells the agent when not to use this tool and names the alternative. It also implies usage when recording a test result for a ticket, providing clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It implies a read-only operation (via 'detalhe') and specifies the content (ticket with tasks), which conveys what to expect. It does not explicitly state non-destructiveness, but the name 'get' and context make it clear. The alternative to report_ticket further implies a lighter operation, adding useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loading the core purpose and immediately providing the alternative. Every word earns its place; no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool with one parameter and no output schema, the description is complete. It states the return scope (ticket with tasks), the alternative, and implicitly the read-only nature. Nothing critical for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the single parameter 'id' with an example (ENG-3), achieving 100% coverage. The description adds no further parameter-specific semantics, so the baseline of 3 applies—the schema handles parameter documentation effectively.
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 retrieves ticket details including tasks ('detalhe de um ticket com tasks'), and explicitly distinguishes it from report_ticket for a fuller package. The verb and resource are specific and unique among siblings.
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 names an alternative (report_ticket) and the condition for using it ('Para pacote completo... use report_ticket'), giving clear when-to-use vs. when-not-to-use guidance. This leaves 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:

[![engineering-mcp MCP server](https://glama.ai/mcp/servers/Wesley-Gomes93/engineering-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Wesley-Gomes93/engineering-mcp)

Score Badge

Copy to your README.md:

[![engineering-mcp MCP server](https://glama.ai/mcp/servers/Wesley-Gomes93/engineering-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Wesley-Gomes93/engineering-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Wesley-Gomes93/engineering-mcp'

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