QASE MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clearly distinct purpose targeting specific resources (cases, plans, projects, results, shared steps, suites, runs) with unambiguous actions (create, get, update, list). No overlapping functionality exists between tools, making selection straightforward for an agent.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern with perfect uniformity (e.g., create_case, get_cases, update_suite). The naming convention is predictable across all 26 tools, using snake_case consistently without any deviations or mixed styles.
Tool Count3/5
With 26 tools, the count is borderline high for typical MCP servers, which often have 3-15 tools. While the tools are well-organized, the number may feel heavy and could overwhelm agents, though it aligns with comprehensive test management coverage.
Completeness5/5
The tool set provides complete CRUD/lifecycle coverage for test management, including create, get, update, and list operations for all core resources (cases, plans, projects, results, shared steps, suites, runs). No obvious gaps exist, ensuring agents can handle full workflows without dead ends.
Average 2.5/5 across 26 of 26 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
This repository is archived. Archived repositories automatically receive an F maintenance tier.
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?
No annotations are provided, so the description carries the full burden of behavioral disclosure, but it offers no information about the tool's behavior. It doesn't mention whether this is a read-only operation, what permissions might be required, how results are returned (e.g., pagination, sorting), potential rate limits, or error conditions. The description is too minimal to provide any 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just three words, which could be appropriate if it were more informative. However, it's under-specified rather than efficiently structured—it doesn't front-load critical information or use its brevity to convey essential details. While not verbose, it wastes its minimal word count on a tautological phrase that adds little value.
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 complexity (2 parameters with no schema descriptions, no annotations, no output schema), the description is completely inadequate. It doesn't explain what the tool returns, how to use the parameters, behavioral traits, or differentiation from siblings. For a list operation with pagination parameters, this level of documentation leaves critical gaps that would hinder an AI agent's ability 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 2 parameters (limit, offset) with 0% description coverage, meaning the schema provides no semantic information about these parameters. The description 'Get All Projects' doesn't mention any parameters at all, failing to compensate for the schema's lack of documentation. Users would have no idea what limit and offset do or how to use them effectively.
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 'Get All Projects' is a tautology that essentially restates the tool name 'list_projects' without adding meaningful specificity. It uses a generic verb 'Get' rather than a more precise action like 'List' or 'Retrieve', and doesn't distinguish this tool from sibling tools like 'get_project' (singular) or other list operations like 'get_cases' or 'get_plans'. The description fails to clarify what 'All Projects' means in context.
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?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools with similar naming patterns (e.g., 'get_project' for a single project, 'get_cases' for cases), but the description doesn't indicate that this tool retrieves multiple projects or explain when to choose it over other retrieval tools. No context, prerequisites, or exclusions are mentioned.
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 behavioral disclosure. The description only states the action ('Create') without any details on permissions, side effects, response format, error handling, or rate limits. For a mutation tool with zero annotation coverage, this is a critical gap in transparency.
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 a single phrase, 'Create test run result', which is front-loaded and wastes no words. However, this brevity comes at the cost of under-specification, as it lacks necessary details for effective tool use.
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 (mutation tool with 3 parameters, nested objects, no output schema, and 0% schema coverage), the description is severely incomplete. It does not explain what the tool returns, how parameters interact, or behavioral aspects, making it inadequate for the agent to use the tool correctly without additional context.
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 none of the three parameters (code, id, result) are documented in the schema. The description does not add any meaning or explanation for these parameters, failing to compensate for the lack of schema documentation. This leaves the agent guessing about parameter purposes and formats.
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 'Create test run result' is essentially a tautology of the tool name 'create_result'. While it indicates the action (create) and resource (test run result), it doesn't specify what constitutes a 'test run result' or how this differs from sibling tools like 'create_result_bulk' or 'update_result'. The purpose is stated but lacks differentiation and specificity.
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. The description does not mention prerequisites, context, or comparisons to sibling tools such as 'create_result_bulk' for bulk operations or 'update_result' for modifications. This leaves the agent without direction on appropriate usage scenarios.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure but provides none. 'Create a new shared step' implies a write/mutation operation but doesn't disclose any behavioral traits: no information about required permissions, whether this is a destructive operation, what happens on success/failure, rate limits, or what the response looks like. For a creation tool with 6 parameters and no annotation coverage, this is completely inadequate.
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 maximally concise at just four words. While this represents severe under-specification rather than ideal conciseness, from a pure structural perspective, it's front-loaded with the core action and wastes no words. Every word earns its place, even though the place is inadequate for the tool's complexity.
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 complexity (creation operation with 6 parameters), lack of annotations, no output schema, and 0% schema description coverage, the description is completely inadequate. It provides no context about what a shared step is, when to create one, what the parameters mean, what behavior to expect, or what the tool returns. This leaves the agent with insufficient information 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?
With 0% schema description coverage and 6 parameters (3 required), the description provides no information about any parameters. It doesn't explain what 'code', 'title', 'action', 'expected_result', 'data', or 'steps' mean in the context of creating a shared step. The schema defines the structure but not the semantics, and the description fails completely to compensate for this gap, leaving all parameters undocumented.
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 'Create a new shared step' is a tautology that essentially restates the tool name without adding meaningful differentiation. While it identifies the verb ('create') and resource ('shared step'), it doesn't specify what a 'shared step' is or how it differs from other entities like cases, plans, or suites that appear in sibling tools. This provides minimal value beyond the name itself.
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?
The description provides absolutely no guidance about when to use this tool versus alternatives. With multiple sibling tools like create_case, create_plan, create_suite, and update_shared_step, there's no indication of what distinguishes a 'shared step' from these other entities or when one would choose to create a shared step versus other creation tools. This leaves the agent with no contextual understanding of appropriate usage scenarios.
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 behavioral disclosure. It only states the action ('Get') without any information about permissions, rate limits, error handling, or what the return value includes (e.g., plan details). This is inadequate 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy to parse quickly.
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 (a retrieval tool with 2 required parameters), no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It doesn't explain parameters, return values, or behavioral traits, leaving significant gaps for an AI 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, meaning the two required parameters ('code' and 'id') are undocumented in the schema. The description adds no meaning about these parameters—it doesn't explain what 'code' or 'id' represent, their formats, or how they relate to retrieving a test plan. This fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get a specific test plan' states a clear verb ('Get') and resource ('test plan'), but it lacks specificity about what distinguishes this from sibling tools like 'get_plans' (which likely lists multiple plans) or 'get_project' (which might retrieve project-level information). It's not tautological but remains somewhat vague about scope.
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. With siblings like 'get_plans' (likely for listing plans) and 'get_project' (for project-level data), there's no indication of prerequisites, context, or exclusions for selecting 'get_plan' over these other retrieval tools.
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 behavioral disclosure. It only states the action ('Get') without any details on permissions required, error handling, rate limits, or what 'Get' entails (e.g., read-only access, data format returned). This leaves critical behavioral traits unspecified for a tool that likely involves data retrieval.
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 a single sentence ('Get a specific shared step'), which is front-loaded and wastes no words. It directly states the core purpose without unnecessary elaboration, making it efficient for quick understanding, though this brevity contributes to gaps in other dimensions.
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 complexity (2 required parameters with no schema descriptions, no annotations, and no output schema), the description is severely incomplete. It doesn't explain what a shared step is, how parameters work, what data is returned, or any behavioral aspects. For a retrieval tool with undocumented inputs and no structured context, this minimal description is inadequate.
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 description provides no information about parameters, while the input schema has 2 required parameters ('code' and 'hash') with 0% schema description coverage. This means both parameters are entirely undocumented in the schema, and the description fails to compensate by explaining their purpose, format, or how they identify a shared step, leaving semantics unclear.
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 the tool's purpose ('Get a specific shared step'), which is clear but vague. It specifies the verb ('Get') and resource ('shared step'), but lacks detail on what a 'shared step' is or how it differs from similar resources like cases or suites. It distinguishes from sibling 'get_shared_steps' (plural) by indicating retrieval of a single item, but doesn't clarify scope or uniqueness compared to other 'get_' 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. The description doesn't mention prerequisites, such as needing a specific shared step identifier, or contrast it with sibling tools like 'get_shared_steps' for listing multiple items or 'get_case' for different resource types. Usage is implied only by the tool name and basic purpose.
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?
With no annotations provided, the description carries full burden but offers no behavioral details. It doesn't disclose that this is a mutation operation (implied by 'update'), what permissions are required, whether updates are reversible, rate limits, or what happens to unspecified fields (e.g., partial vs. full updates). This leaves critical gaps for safe tool invocation.
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—a single sentence with no wasted words. It's front-loaded with the core action, though this brevity comes at the cost of completeness. For conciseness alone, it's optimal.
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 high complexity (20 parameters, 0% schema coverage, no annotations, no output schema), the description is severely incomplete. It doesn't explain the tool's behavior, parameter meanings, return values, or usage context. This is inadequate for a mutation tool with many undocumented inputs.
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 schema provides no parameter documentation. The description adds no parameter semantics—it doesn't explain what 'code', 'id', or any of the 20 parameters mean, their formats, or constraints. This forces the agent to guess parameter purposes, which is inadequate for such a complex tool.
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 'Update an existing test case' clearly states the action (update) and resource (test case), which is adequate. However, it doesn't differentiate this tool from sibling update tools like update_plan or update_suite, nor does it specify what aspects of a test case can be updated beyond the generic term.
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 doesn't mention prerequisites (e.g., needing an existing test case ID), compare with create_case for new cases, or explain when to use update_case versus other update tools in the sibling list. The agent must infer usage from context alone.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure but offers none. It doesn't indicate whether this is a safe operation, what permissions are required, if it's idempotent, or what happens on success/failure. For a creation tool with zero annotation coverage, this is a critical gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, front-loading the essential action and resource. There is no wasted language or unnecessary elaboration, making it efficient for quick comprehension.
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 complexity (5 parameters, creation operation), lack of annotations, and no output schema, the description is severely incomplete. It doesn't cover parameter meanings, behavioral traits, usage context, or expected outcomes, failing to provide the necessary context for effective tool 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 description adds no parameter information beyond what the input schema provides. With 0% schema description coverage and 5 parameters (code, title, description, access, group), the description fails to explain what these parameters mean, their formats, or constraints. This leaves key inputs like 'access' enum values unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create new project' clearly states the action (create) and resource (project), making the purpose immediately understandable. It distinguishes from sibling tools like 'list_projects' or 'get_project' by specifying creation rather than retrieval. However, it doesn't specify what kind of project or domain (e.g., software, construction), which 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 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 doesn't mention prerequisites (e.g., authentication), when not to use it, or how it differs from similar creation tools like 'create_case' or 'create_suite'. This leaves the agent with minimal context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states 'Create' (implying a write/mutation operation) but doesn't disclose permissions needed, whether creation is atomic/transactional, rate limits, error handling for partial failures, or what happens on success. This is inadequate for a mutation 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a basic tool description, though the brevity contributes to gaps in other dimensions.
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 mutation tool with 3 required parameters (including a nested object), 0% schema coverage, no annotations, and no output schema, the description is severely incomplete. It doesn't explain what the tool returns, how to interpret parameters, or critical behavioral aspects like error handling.
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 provides no information about the three required parameters (code, id, results). The term 'results' in the description refers to the resource being created, not the parameter named 'results', creating potential confusion. No parameter meanings, formats, or examples are given.
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 ('Create multiple test run results') and resource ('in bulk'), distinguishing it from the singular 'create_result' sibling tool. However, it doesn't specify what 'test run results' are in this context or how they differ from other test entities like cases or suites.
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 like 'create_result' (singular) or other creation tools. The description implies bulk creation but doesn't specify thresholds, performance considerations, or prerequisites for using bulk operations.
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 behavioral disclosure. It only states 'Get a specific test run', which implies a read-only operation but does not clarify permissions, rate limits, error handling, or what data is returned (e.g., run details, status). For a tool with zero annotation coverage, this lack of behavioral information is a significant gap, making it inadequate for safe and effective use.
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, 'Get a specific test run', which is appropriately sized and front-loaded with the core action. There is no wasted text or unnecessary elaboration, making it efficient for quick understanding, though it lacks depth.
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 (3 parameters, no annotations, no output schema), the description is incomplete. It does not explain the return values, parameter usage, or behavioral traits, leaving gaps that could hinder the agent's ability to invoke the tool correctly. For a retrieval tool with undocumented inputs and outputs, more context is needed to ensure reliable operation.
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 3 parameters (code, id, include) with 0% description coverage, meaning no parameter details are documented in the schema. The description does not add any meaning beyond the schema—it does not explain what 'code' and 'id' represent (e.g., project code and run ID) or how 'include' works (e.g., to embed cases). Since the schema coverage is low and the description fails to compensate, the score reflects this deficiency.
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 the tool's purpose as 'Get a specific test run', which includes a verb ('Get') and resource ('test run'), making it clear what it does. However, it lacks specificity about what 'specific' means (e.g., by ID/code) and does not distinguish it from sibling tools like 'get_runs' (which likely lists multiple runs) or 'get_result' (which might retrieve results within runs). This vagueness prevents a higher score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing a run ID), exclusions, or comparisons to siblings like 'get_runs' for listing runs or 'get_result' for run results. Without such context, the agent must infer usage from the tool name and schema alone, which is insufficient for effective selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states 'Get' implying a read operation, but doesn't clarify if this requires authentication, returns error conditions, or has any side effects like caching. This leaves gaps in understanding 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words, making it easy to parse. However, it could be more front-loaded with additional context to improve utility without sacrificing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 required parameters, no annotations, no output schema), the description is insufficient. It doesn't explain what a 'test suite' entails, how parameters are used, or what the return value looks like, leaving the agent with significant gaps in 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?
The input schema has 2 parameters (code and id) with 0% description coverage, so the schema provides no semantic information. The description adds no details about what these parameters mean (e.g., code could be a project code, id a numeric identifier), failing to compensate for the schema's lack of documentation.
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 'Get a specific test suite' clearly states the verb ('Get') and resource ('test suite'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_suites' (plural) or 'get_case'/'get_plan' which retrieve different resources, leaving some ambiguity about scope.
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. For example, it doesn't specify if this is for retrieving a single suite by identifier versus using 'get_suites' for listing multiple suites, nor does it mention 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.
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. 'Create' implies a write/mutation operation, but the description doesn't disclose permissions needed, whether creation is idempotent, error handling, or what happens on success (e.g., returns a case ID). It lacks critical behavioral context 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 extremely concise with a single sentence, 'Create a new test case', which is front-loaded and wastes no words. It efficiently states the core action, though this brevity contributes to gaps in other dimensions.
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 (a creation operation with 2 parameters, including a nested object), no annotations, and no output schema, the description is incomplete. It doesn't explain what 'code' and 'testCase' represent, what the tool returns, or any behavioral traits, making it inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the schema provides no parameter descriptions. The tool description doesn't mention any parameters, failing to compensate for the coverage gap. Parameters 'code' and 'testCase' (a nested object) are entirely undocumented, leaving their purpose and format ambiguous.
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 'Create a new test case' clearly states the verb ('Create') and resource ('test case'), but it's vague about what a 'test case' entails in this context. It distinguishes from siblings like 'create_plan' or 'create_suite' by specifying the resource type, but lacks specificity about the domain or system involved.
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 like 'update_case' or 'get_case'. The description doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage 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 the full burden of behavioral disclosure. 'Create a new test plan' implies a write operation, but it doesn't disclose permissions needed, whether creation is idempotent, error handling, or response format. It lacks details on behavioral traits beyond the basic 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, efficient sentence with zero waste. It's front-loaded and appropriately sized for a basic tool definition, though it may be too concise given the lack of detail in other dimensions.
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 (a creation tool with 4 parameters, no annotations, and no output schema), the description is incomplete. It doesn't explain return values, error conditions, or how parameters interact. For a tool that likely mutates data, more context is needed to guide an AI agent effectively.
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 undocumented parameters. It doesn't add any meaning beyond the input schema—no explanation of what 'code', 'title', 'description', or 'cases' represent, their formats, or constraints. With 4 parameters and low coverage, this is inadequate.
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 'Create a new test plan' states a clear verb ('Create') and resource ('test plan'), but it's vague about what a 'test plan' entails and doesn't distinguish it from sibling tools like 'create_project', 'create_suite', or 'create_case'. It provides a basic purpose but lacks specificity about the domain or scope.
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. Sibling tools include other creation tools (e.g., 'create_case', 'create_suite') and update tools (e.g., 'update_plan'), but the description doesn't mention prerequisites, context, or exclusions. Usage is implied only by 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 carries full burden. 'Create a new test suite' implies a write/mutation operation, but there's no information about permissions required, whether creation is idempotent, what happens on failure, or what the response contains. For a creation tool with zero annotation coverage, this is a significant gap in behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - just 4 words. It's front-loaded with the essential action and resource. There's zero wasted language or redundancy. While it may be too brief for completeness, as a standalone statement it's perfectly structured and efficient.
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 5 parameters, 0% schema description coverage, no annotations, and no output schema, the description is severely incomplete. It doesn't explain what a test suite is in this context, what parameters mean, what the creation entails, or what to expect as a result. The agent would struggle to use this tool correctly 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%, meaning none of the 5 parameters have descriptions in the schema. The tool description provides no information about parameters whatsoever - not what 'code', 'title', 'description', 'preconditions', or 'parent_id' mean or how they should be used. The description fails to compensate for the complete lack of schema documentation.
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 'Create a new test suite' clearly states the verb ('create') and resource ('test suite'), which is better than a tautology. However, it doesn't differentiate from siblings like 'create_project' or 'create_plan' - all could be creating different types of test artifacts. The purpose is clear 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 versus alternatives. With siblings like 'create_project', 'create_plan', and 'create_case', there's no indication of when a test suite is appropriate versus other test artifacts. No prerequisites, constraints, or alternatives 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?
No annotations are provided, so the description carries full burden. It states 'Get' which implies a read operation, but doesn't disclose behavioral traits such as authentication needs, error handling, rate limits, or what happens if the case doesn't exist. For a retrieval tool with zero annotation coverage, this is a significant gap in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized for a simple tool and front-loaded with the core action, though it could benefit from more detail given the lack of other documentation.
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 (2 required parameters, 0% schema coverage, no output schema, no annotations), the description is incomplete. It doesn't explain parameter semantics, return values, or behavioral context, making it inadequate for an agent to use the tool effectively 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 provides no information about the parameters 'code' and 'id', leaving their meaning, format, or relationship undocumented. The description adds no value beyond the schema, failing to explain what these identifiers represent or how to use them.
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 'Get a specific test case' clearly states the action (get) and resource (test case), but it's vague about what 'specific' means and doesn't distinguish this tool from sibling 'get_cases' which likely retrieves multiple cases. It provides basic purpose but lacks specificity about scope or 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 like 'get_cases' or other retrieval tools. The description implies retrieval of a single case but doesn't specify prerequisites, context, or exclusions, leaving usage unclear relative to 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?
With no annotations provided, the description carries full burden but only states it's an update operation. It doesn't disclose behavioral traits like permission requirements, whether updates are reversible, rate limits, or what happens to unspecified fields. 'Update' implies mutation, but lacks critical details 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded with the core purpose and appropriately sized for the minimal information it conveys.
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 5 parameters, 0% schema coverage, no annotations, and no output schema, the description is insufficient. It doesn't explain what the tool returns, error conditions, or provide enough context for reliable use. The gap between complexity and documentation is significant.
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 adds no parameter information. It doesn't explain what 'code', 'id', 'title', 'description', or 'cases' represent, their formats, or how they affect the update. With 5 parameters and no schema descriptions, this is inadequate.
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 'Update an existing test plan' clearly states the action (update) and resource (test plan), but it's generic and doesn't differentiate from sibling update tools like update_case or update_suite. It specifies 'existing' which distinguishes from create_plan, but lacks detail about what aspects can be updated.
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 is provided. The description implies it's for modifying existing plans, but doesn't mention prerequisites, when to choose create_plan instead, or how it relates to other update tools. The context is minimal.
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. While 'update' implies a mutation operation, the description doesn't specify permissions required, whether the update is reversible, rate limits, or what happens to unspecified fields. This leaves significant gaps in understanding the tool's behavior beyond the basic 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, straightforward sentence with no wasted words. It's appropriately sized for a basic tool description and front-loaded with the essential action, making it easy to parse quickly.
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 (4 required parameters including a nested object, no output schema, and no annotations), the description is insufficient. It doesn't explain parameter meanings, return values, error conditions, or behavioral nuances, leaving the AI agent with inadequate information to use the tool correctly in 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%, meaning none of the 4 parameters (code, id, hash, result) are documented in the schema. The description adds no information about what these parameters mean, their formats, or how they interact (e.g., whether 'id' identifies the result to update, what 'hash' is for, or what 'result' object should contain). This fails to compensate for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an existing test run result' clearly states the action (update) and target resource (test run result), which is adequate. However, it doesn't distinguish this tool from similar sibling tools like 'update_case', 'update_plan', or 'update_suite', leaving ambiguity about when to use this specific update operation versus others.
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. With multiple 'update_' sibling tools available (e.g., update_case, update_plan, update_suite), there's no indication of context, prerequisites, or exclusions to help an AI agent choose appropriately among them.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It states 'update' implying mutation, but doesn't disclose what happens on success/failure, whether changes are reversible, permission requirements, or rate limits. For a mutation tool with 7 parameters, this leaves critical gaps in understanding how the tool behaves.
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 at just 4 words, with zero wasted language. It's front-loaded with the core action, though this brevity comes at the cost of completeness. Every word directly contributes to stating the tool's purpose.
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 7 parameters, 0% schema coverage, no annotations, and no output schema, the description is severely incomplete. It doesn't explain what a 'shared step' is, what fields can be updated, what the update does, or what to expect in return. The agent lacks sufficient context to use this tool effectively.
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 all 7 parameters are undocumented in the schema. The description adds no information about what parameters mean (e.g., what 'code', 'hash', or 'steps' represent), their formats, or relationships. This forces the agent to guess parameter purposes based on names alone.
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 'Update an existing shared step' clearly states the verb (update) and resource (shared step), but it's vague about what specifically gets updated. It doesn't differentiate from sibling tools like update_case or update_plan, which follow the same pattern for different resources.
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. The description doesn't mention prerequisites (e.g., needing an existing shared step), nor does it differentiate from create_shared_step for new items or get_shared_step for reading. The agent must infer usage 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 but offers minimal behavioral insight. It implies a read operation ('Get') but doesn't disclose critical traits like pagination behavior (hinted by 'limit' and 'offset' parameters), rate limits, authentication needs, or whether results are sorted. This leaves significant gaps for agent decision-making.
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 efficiently conveys the core purpose without unnecessary words. It's front-loaded and wastes no space, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (15 parameters, no output schema, no annotations), the description is severely incomplete. It doesn't address parameter usage, return values, error conditions, or behavioral constraints, leaving the agent with insufficient context to use the tool effectively beyond basic intent.
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 fails to do so. It mentions 'all test cases in a project' but doesn't explain any of the 15 parameters, including the required 'code' parameter or filtering options like 'search' or 'severity'. This leaves parameters largely 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 action ('Get') and resource ('test cases in a project'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'get_case' (singular) or explain the scope of 'all' versus filtered results, which 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 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 'get_case' (singular) or 'get_suites' (for related resources). It lacks context about prerequisites, such as needing a project code, or when filtering might be preferred over retrieving all cases.
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 but only states the basic action. It doesn't disclose behavioral traits such as pagination behavior (implied by 'limit' and 'offset' parameters), authentication needs, rate limits, or what 'all' means in practice (e.g., completeness of results).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's appropriately sized and front-loaded with the core purpose, making it easy to scan.
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 (3 parameters, no annotations, no output schema), the description is incomplete. It lacks details on parameter usage, return values, and behavioral context, making it inadequate for reliable tool invocation without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate but adds no parameter information. It doesn't explain what 'code' refers to (likely a project identifier), or how 'limit' and 'offset' affect pagination. This leaves key 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 action ('Get') and resource ('all test plans in a project'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_plan' (singular) or 'list_projects', which could cause confusion about scope or 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?
No guidance is provided on when to use this tool versus alternatives like 'get_plan' (for a single plan) or 'list_projects' (for projects). The description implies usage for retrieving multiple plans but lacks explicit context 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 full burden. It states it's a read operation ('Get'), but doesn't disclose behavioral traits like error handling (e.g., what happens if code/hash is invalid), authentication needs, rate limits, or response format. The description is minimal and lacks critical operational 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 extremely concise (one short sentence) and front-loaded with the core purpose. There is no wasted verbiage, making it efficient for quick scanning.
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 2 required parameters, no annotations, and no output schema, the description is incomplete. It doesn't explain what a 'test run result' entails, how to obtain the code/hash, or what the return value looks like. For a retrieval tool with no structured support, more context is needed.
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 parameters 'code and hash' but provides no semantic meaning (e.g., what these identifiers represent, their format, or examples). This adds minimal value beyond the schema's structural definition.
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 ('Get') and the resource ('test run result'), specifying it's retrieved by 'code and hash'. This distinguishes it from sibling tools like 'get_results' (plural) which likely returns multiple results. However, it doesn't explicitly contrast with other 'get_' tools like 'get_case' or 'get_run'.
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 doesn't mention prerequisites (e.g., needing a valid code/hash), exclusions, or comparisons to similar tools like 'get_results' or 'get_run'. The description implies usage only when you have both identifiers.
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 burden. It mentions 'Get all test run results' but doesn't disclose behavioral traits like pagination (implied by limit/offset params), authentication needs, rate limits, or return format. This is inadequate for a tool with 6 parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It's front-loaded and appropriately sized for its content, though it could benefit from more detail given the tool's complexity.
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 (6 parameters, no annotations, no output schema), the description is incomplete. It lacks details on parameter usage, behavioral context, and output, making it insufficient for an AI agent to use the tool effectively without guesswork.
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 'for a project' which hints at the 'code' parameter, but doesn't explain the other 5 parameters (limit, offset, status, from, to) or their semantics. This leaves most 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 verb ('Get') and resource ('all test run results for a project'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_result' (singular) or 'get_runs', leaving some ambiguity about scope.
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 like 'get_result' (singular) or 'get_runs'. The description implies it retrieves all results, but without context on filtering or comparison to siblings, usage is unclear.
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 but offers minimal behavioral insight. 'Get all' implies a read operation, but doesn't disclose pagination behavior (despite limit/offset parameters), authentication needs, rate limits, or what 'all' means in practice (e.g., completeness guarantees).
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?
Extremely concise with a single, front-loaded sentence that states the core purpose without waste. Every word earns its place, though this brevity contributes to gaps in other dimensions.
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?
Incomplete for a tool with 10 parameters, 0% schema coverage, and no output schema. The description lacks parameter explanations, behavioral context, and output details, making it inadequate for an agent to use the tool effectively without guessing.
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 fails to do so. It mentions no parameters, leaving all 10 parameters (like 'search', 'status', 'milestone') undocumented. The phrase 'in a project' hints at the 'code' parameter but doesn't explain its role or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all test runs in a project' clearly states the action (get) and resource (test runs), with scope (in a project). It distinguishes from siblings like 'get_run' (singular) by specifying 'all' runs, but doesn't explicitly differentiate from other list-like tools like 'get_cases' or 'get_results' beyond resource 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 on when to use this tool versus alternatives. The description doesn't mention when to choose 'get_runs' over 'get_run' (singular) or other filtering tools, nor does it provide context about prerequisites or typical use cases.
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 burden. It states it 'gets' data, implying a read operation, but lacks details on permissions, rate limits, pagination behavior (despite 'limit' and 'offset' parameters), error handling, or output format. This is inadequate for a tool with multiple parameters and no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no wasted words. It front-loads the core purpose ('Get all shared steps in a project'), making it easy to scan and understand quickly.
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 4 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It doesn't explain parameter usage, behavioral traits, or return values, leaving significant gaps for an AI agent to invoke the tool correctly in a complex context with many 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?
Schema description coverage is 0%, so the description must compensate. It mentions 'in a project', which hints at the 'code' parameter (likely a project identifier), but doesn't explain the 'search', 'limit', or 'offset' parameters. This adds minimal meaning beyond the schema, failing to address the coverage 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 'Get all shared steps in a project' clearly states the action (get) and resource (shared steps) with scope (in a project). It distinguishes from siblings like 'get_shared_step' (singular) and 'create_shared_step', but doesn't explicitly differentiate from other list-like tools such as 'get_cases' or 'get_suites' in terms of resource 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 on when to use this tool versus alternatives is provided. The description implies it retrieves all shared steps, but it doesn't specify prerequisites (e.g., project existence), exclusions, or compare to similar tools like 'get_shared_step' (for a single step) or other 'get_' tools for different resources.
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 states it 'gets' data, implying a read operation, but doesn't cover aspects like pagination behavior (suggested by 'limit' and 'offset' parameters), error handling, authentication needs, or rate limits. This is a significant gap for a tool with multiple parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 (4 parameters, 1 required), lack of annotations, and no output schema, the description is incomplete. It doesn't address parameter meanings, behavioral traits, or return values, leaving the agent with insufficient context to use the tool effectively beyond its basic purpose.
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 adds no parameter information. It doesn't explain what 'code', 'search', 'limit', or 'offset' mean, their formats, or how they affect the operation. With 4 parameters and no schema descriptions, this leaves key semantics 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 action ('Get') and resource ('all test suites in a project'), making the purpose understandable. It doesn't explicitly differentiate from sibling tools like 'get_suite' (singular) or 'list_projects', but it's specific enough to convey its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 'get_suite' (singular) or 'list_projects'. It lacks context about use cases, prerequisites, or exclusions, leaving the agent to infer usage 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. 'Update' implies a mutation operation, but the description doesn't specify what happens during update (partial vs full updates, validation rules, error conditions), whether it requires specific permissions, or what the response contains. This leaves significant behavioral gaps 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is maximally concise at 4 words, front-loading the essential action and resource. There's zero wasted language, though this conciseness comes at the cost of completeness. Every word earns its place in conveying the core purpose.
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 6 parameters, 0% schema coverage, no annotations, and no output schema, the description is severely incomplete. It states what the tool does at a high level but provides none of the necessary context about how to use it effectively, what parameters mean, what behaviors to expect, or what results will be returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage for all 6 parameters, the description provides no information about parameter meanings beyond what's inferable from names. It doesn't explain what 'code', 'id', 'title', 'description', 'preconditions', or 'parent_id' represent in the context of updating a test suite, leaving the agent to guess parameter purposes and formats.
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 ('Update') and resource ('an existing test suite'), making the purpose immediately understandable. It distinguishes from sibling 'create_suite' by specifying 'existing', but doesn't differentiate from other update tools like 'update_case' or 'update_plan' beyond the resource 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (like needing an existing suite ID), when to choose update_suite over create_suite, or how it differs from other update operations in the sibling list. The agent must infer usage 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 provided, the description carries the full burden of behavioral disclosure. It states the action ('Get') but doesn't clarify if this is a read-only operation, what happens on failure (e.g., if the code doesn't exist), or any rate limits or authentication needs. For a retrieval tool, this minimal description misses key operational details.
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—a single phrase with no wasted words—and front-loaded with the core action. It efficiently communicates the essential purpose without unnecessary elaboration, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, no output schema, and minimal parameter details, the description is incomplete for effective tool use. It doesn't explain what 'Get' entails (e.g., returns project details or just metadata), error handling, or how it fits within the broader context of sibling tools, leaving significant gaps for the agent.
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 adds minimal semantics by implying that 'code' is used to identify a project, but with 0% schema description coverage and one required parameter, it doesn't elaborate on the format or constraints of 'code' (e.g., whether it's a numeric ID, string identifier, or case-sensitive). This provides some value over the bare schema but doesn't fully compensate for the coverage 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 'Get project by code' clearly states the verb ('Get') and resource ('project'), and specifies the lookup mechanism ('by code'), making the purpose unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'list_projects' or other 'get_' tools that might retrieve projects differently, which 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 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. For example, it doesn't mention when to choose 'get_project' over 'list_projects' or other retrieval tools, nor does it specify prerequisites or contextual constraints. This lack of usage direction leaves the agent to infer based on tool names alone.
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:

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

Score Badge

Copy to your README.md:

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

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/rikuson/mcp-qase'

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