zephyr-scale-mcp

Server Quality Checklist

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

Latest release: v0.1.2
Disambiguation5/5
Each tool targets a distinct resource and action (e.g., add_test_steps vs set_test_script, clone_test_case vs create_test_case, etc.), with no overlapping purposes. Agents can clearly differentiate between tools.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., create_test_case, update_test_plan, download_attachment). No mixing of conventions or vague verbs.
Tool Count5/5
22 tools is well-scoped for a test management server, covering core entities (test cases, plans, runs, folders, attachments) and common operations without bloat.
Completeness2/5
Missing several expected operations: delete_test_case, delete_test_run, delete_attachment, list_folders, search_test_cases, and get_test_run_results. These gaps will likely cause agent failures in standard workflows.
Average 4.6/5 across 22 of 22 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 45 commits in the last 12 weeks
- Last stable release on July 31, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, and description adds that response includes linked test runs and issues beyond what annotations convey. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description mentions response contents (linked test runs/issues). Sufficient for a simple read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description adds marginal value by explaining fields parameter as optional payload restriction, but does not exceed schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Read a Zephyr Scale test plan by key' with specific verb and resource, and distinguishes from sibling tools like search_test_plans.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Specifies the HTTP method and endpoint, and mentions optional field restriction. Implicitly suggests using this tool when you have a specific key, though lacks explicit when-not alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, which aligns with downloading. The description adds behavioral details: the file is saved to a local path (side effect), the parent directory must exist, and credentials are never sent to external hosts. These details go beyond what annotations provide.
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 appropriately sized with 5 sentences, each providing distinct information. It is front-loaded with the main action and then details constraints and output. While not overly concise, every sentence adds value and there is no repetition of schema data.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description includes the return format ({ savedTo, bytes }). It covers required parameter, optional parameters, security, and file writing constraints. It could mention error cases or file overwrite behavior, but overall it is sufficiently complete for a download tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so parameters are documented. The description adds meaning by specifying that exactly one of url or attachmentId should be passed, that url must be from list_attachments and on the configured host, and that the parent directory for outputPath must exist. This adds context beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Download a Zephyr Scale attachment to a local file') and specifies the resource (attachments). It distinguishes from sibling tools like list_attachments and delete_attachment by focusing on downloading. The verb 'Download' is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use this tool (to download attachments) and provides clear guidance on addressing attachments via attachmentId or url. It does not explicitly state when not to use it, but the context of sibling tools implies alternatives. The safety note about url host adds valuable usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, which is consistent. The description adds behavioral context: it returns the latest result across all runs, implying a broad scope. No destructive effects are mentioned, but none are needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, immediately states the core functionality, and includes a useful comparison. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single required parameter, no output schema, read-only operation), the description fully addresses what the agent needs to know. It covers purpose, scope, and alternative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema alone provides full coverage (100%) with a clear description for 'testCaseKey'. The tool description adds no extra semantic detail beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the most recent execution result across all test runs. It specifies the verb 'get', the resource 'execution result', and distinguishes from the sibling tool 'get_test_run_results', which targets a specific run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts with the sibling tool 'get_test_run_results', telling the agent when to use each. It could mention other alternatives, but the provided guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers behavioral traits: IT discloses the HTTP method (POST), return key format, the inability to build a UI URL, and critical constraints (folder must pre-exist, status case-sensitive, owner format). No contradictions noted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence for the main action plus a structured list of constraints. Every sentence adds value, and the critical information is front-loaded. No redundant phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 parameters, nested objects, no output schema), the description covers return values, prerequisites, and parameter nuances. It lacks explicit error handling or response details, but it is largely complete for a creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the return format, folder creation requirement, status defaults, and owner resolution. This enriches the parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Create a Zephyr Scale test plan (POST /testplan).' It specifies the action, resource, and API method, and distinguishes it from sibling tools like create_test_case and create_test_run. The return value format { key } is also mentioned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool and includes prerequisites (folder must exist, owner resolution via find_jira_user). It does not explicitly state when not to use it or compare directly to alternatives, but the constraints and context are sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With empty annotations, the description carries full burden. It discloses creation behavior, immutability of run items, optional field sending, default statuses, units (ms for time, ISO 8601 for dates), scriptResults format, and batch-level disambiguation via matchEnvironment/matchUserKey as query parameters. Lacks error case disclosure but is otherwise thorough.
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, well-organized paragraph of around 150 words. It front-loads the main purpose and every sentence provides necessary detail without redundancy. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (bulk creation, multiple parameters, nuanced behavior), the description is largely complete: it covers prerequisites, default statuses, units, date format, per-step results, disambiguation, and return value. Lack of error handling or permission notes is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value beyond schema by clarifying the batch application of matchEnvironment/matchUserKey as query parameters, the requirement that testCaseKey be a run item, and the format of scriptResults. It enriches understanding of parameter behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create NEW executions (test results) for several test cases of one test run in a single call.' It specifies the verb (create), resource (executions/test results), and scope (bulk), distinguishing it from single-creation sibling create_test_result and other bulk tools 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use: for bulk creation of results within a single run, with the constraint that testCaseKeys must already be run items. It implies exclusion of single-result operations but does not explicitly name alternatives or when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true; description adds significant behavioral detail: composite read-only nature, multiple HTTP calls per case, null lastResult for unexecuted cases, and performance guidance (capping volume). No contradiction.
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?
Concise and well-structured: begins with core purpose, then explains composite API calls, null result behavior, and performance caveat. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description effectively communicates input behavior, performance implications, and output semantics (null lastResult). Sufficient for agent understanding, though output format lacks explicit specification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all 3 parameters (100% coverage), but description adds value by explaining the rationale behind maxCases (to limit HTTP calls) and clarifying defaults (50 for maxCases, true for includeLastResults). Links parameter purpose to tool behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly describes the tool as a traceability report for a Jira issue, listing linked test cases with latest execution results. Distinguishes from sibling get_test_cases_linked_to_issue by including results, and from get_latest_result_for_test_case by aggregating multiple cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining test coverage with results, and mentions volume capping with maxCases, but does not explicitly state when to use this over alternatives like get_test_cases_linked_to_issue or get_latest_result_for_test_case. No exclusion criteria provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, and description confirms read operation. Adds context about per-step ids and safe editing, going beyond the annotation. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with primary action. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description hints at return values (per-step ids). Covers key usage context. Could briefly mention default return structure if fields not specified, but minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. Description adds that fields are sent as comma-separated list and that the parameter is optional, providing extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Read a Zephyr Scale test case by key' with the API endpoint. Distinguishes from siblings like search_test_cases and update_test_case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains that fields parameter is optional and notes that per-step ids are required for safe editing via update_test_case. Provides helpful cross-tool context but lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool returns a list of attachments as reported by the API, and that the numeric ids are for delete. Annotations confirm readOnlyHint=true, so no contradiction. The description adds value by explaining limitations (e.g., no per-step endpoint for test runs) which go beyond the annotation.
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 detailed but well-structured, starting with the core purpose and then expanding on addressing rules. Every sentence adds value, though some minor redundancy could be trimmed. It avoids unnecessary fluff and is front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of three target types with optional step addressing and no output schema, the description covers the mandatory identifier handling and the output's link to delete_attachment. It does not mention pagination or response structure, but these are less critical for a listing tool. The presence of readOnlyHint annotations reduces the need for further behavioral disclosure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the input schema covers all parameters with descriptions, the description adds crucial context about parameter interdependencies: which identifier is required for each target, and that stepIndex is only valid for test_case and test_result. This goes well beyond the schema and is essential for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool lists attachments of a Zephyr Scale test case, test run, or test result, optionally for a specific step. It distinguishes between three target types and explains the addressing scheme, making the purpose very specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit instructions on which identifier to pass for each target, and notes that step addressing is only available for test_case and test_result. It also mentions that the returned ids can be used with delete_attachment, guiding subsequent actions. However, it does not explicitly compare to sibling tools like download_attachment or upload_attachment, which would help the agent decide when to use this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the destructiveHint annotation: it states the operation cannot be undone and describes the exact return format. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no unnecessary words. All essential information is front-loaded: action, endpoint, permanence, return value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter destructive tool, the description covers purpose, irreversibility, and return value. No missing context given the simplicity of the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is only one parameter (testPlanKey) and its schema description is clear. The description does not add further detail beyond the schema, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Permanently delete a Zephyr Scale test plan') and provides the REST endpoint. It distinguishes itself from sibling tools like create_test_plan and update_test_plan by indicating permanence and deletion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the tool's irreversible nature ('This cannot be undone'), which serves as a strong usage guideline. However, it does not explicitly mention when not to use it or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide idempotentHint=true, which the description does not contradict. Beyond that, the description discloses the name format constraint ('must not contain "/" or "\"') and explains why the numeric id is necessary (API cannot list folders). This adds behavioral context beyond the idempotency hint.
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?
Three concise sentences: first states purpose and key parameters, second clarifies the name constraint, third explains the id sourcing limitation. No fluff, front-loaded with essential information. Every sentence serves a distinct purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers parameter constraints and a critical API limitation. However, it does not mention the return value or success/error behavior. Given no output schema, a brief note on expected output would improve completeness. Still, it provides enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all parameters. The description reinforces the name parameter's constraint ('single folder segment, NOT a path') and adds critical context about the folderId's origin ('as returned by create_folder'). This extra context goes beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb-resource pairing ('Rename an existing Zephyr Scale folder') and clearly identifies the required identifier ('numeric id'). It also distinguishes from sibling tools by noting the dependency on create_folder, which is the only way to obtain the id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the prerequisite: 'keep the numeric id returned by create_folder — rename_folder needs it (otherwise the id can only be found in the Jira UI).' This guides the agent on when to use this tool (after creation) and provides a critical constraint. Though alternatives are not listed, no sibling tool performs renaming, so no exclusion is needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden of behavioral disclosure. It explicitly states that step IDs are never carried over, execution history/attachments are not copied, name and folder defaults, and the return object includes key, url, and sourceKey. No contradictions.
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 paragraph that efficiently communicates all necessary information. Each sentence adds value, though it could be slightly more structured (e.g., bullet points for behaviors). It is appropriately sized for the complexity of the operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description provides complete context: it explains the composite nature (read+create), enumerates what is and is not copied, specifies defaults, and mentions the return fields. All four parameters are sufficiently described, and constraints (folder must exist) are noted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with descriptions, and the description adds meaningful defaults (name defaults to '<source name> (copy)', folder defaults to source folder, includeScript defaults true). It clarifies the meaning of testCaseKey as the source key, enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool clones a Zephyr Scale test case using specific verbs ('clone', 'composite read+create') and specifies the resource. It distinguishes itself from siblings like create_test_case (which creates from scratch) and update_test_case (which modifies existing) by describing its unique behavior of duplicating an existing test case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when you want to duplicate a test case with settings) and provides context about what is copied and what is not, but it does not explicitly name alternative tools or state conditions when this tool should be avoided. The context is clear, so it scores a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Covers API constraints (folder existence, BDD rejection with 400, key format, case sensitivity, millisecond units). Annotations are empty, so description carries full burden. Missing explicit mention of idempotency but creation is inherently non-idempotent.
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?
Front-loaded with key info (endpoint, return format). Every sentence adds value despite length. Could be slightly more concise but remains clear and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 15 parameters, complex nested objects, and no output schema, the description is remarkably complete. Covers all critical aspects: folder prerequisite, status/priority case sensitivity, script format rules, estimatedTime units, and references sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds significant value: explains BDD restriction in detail, owner resolution workflow, testScript structure beyond schema. The extra context justifies a 4 over baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a Zephyr Scale test case (POST /testcase)' and specifies the return format '{ key, url }'. It distinguishes the tool from siblings like 'update_test_case' and 'clone_test_case' by focusing on creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides extensive guidance: folder must exist (use create_folder first), owner must be a Jira user key (resolve with find_jira_user), status/priority case-sensitive with defaults, script format rules (BDD without headers). Explicitly tells when to use other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses destructive actions (deleting steps, irreversible format switch) and API-specific constraints (rejecting BDD headers). This adds significant value beyond the destructiveHint annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense paragraph but is well-organized. Minor improvement could be bullet points for better readability, but it remains concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple formats, destructive, conditional params), the description covers essential aspects including return value. Lacks error-handling details but sufficient for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the description still adds meaning by clarifying usage (e.g., 'pass text for PLAIN_TEXT/BDD', steps behavior for STEP_BY_STEP).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool replaces a test case's entire script or changes its format, specifying the HTTP method and endpoint. It distinguishes from siblings like add_test_steps by focusing on full replacement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit warnings about destructive behavior and explains when to use each format. It could explicitly mention when not to use (e.g., for incremental additions), but the context is still clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses partial update behavior (omitted fields unchanged), warns against sending empty placeholders, and notes return value {key}. These details add value beyond the idempotentHint annotation, with no contradictions.
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 (3 sentences), front-loading the core action and partial update nature, then adding essential constraints and return info. No unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, no output schema), the description covers the most critical aspects: partial update, key constraints, and return value. It references create_test_plan for additional details, which is acceptable but could include a brief example for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter descriptions, but the description adds crucial context: partial update semantics, immutability of projectKey (though not a direct parameter but implied), and constraints inherited from create_test_plan. This enriches understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates a Zephyr Scale test plan via PUT, specifying it's a partial update and distinct from create or delete operations. It provides the HTTP method and key constraints, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for updating existing test plans and warns about partial updates and constraints (e.g., projectKey unchangeable). It does not explicitly compare to siblings like create_test_plan or update_test_case, but the partial update nature and references to create_test_plan constraints provide sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: partial update (only sent fields change), targeting only the latest result, requirement for run composition, and nuances like matchUserKey/matchEnvironment being query parameters. Annotations only provide idempotentHint, so the description carries the full behavioral burden and does so thoroughly.
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 front-loaded with the main purpose and structured logically. It covers all necessary details without being overly verbose, though a slightly tighter structure could improve conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (17 parameters, nested objects, query parameters), the description is largely complete. It covers update semantics, limitations, data types, and disambiguation. The lack of return value description is a minor gap, but the tool's context (update) makes the return somewhat predictable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (88%), but the description adds value by explaining partial update semantics, duration units, date format, scriptResults structure, and special parameter behavior (e.g., query parameters vs body). This goes beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies 'update the LAST (most recent) test result of a run item' with a clear verb and resource. It distinguishes from sibling 'create_test_result' by noting that older executions cannot be targeted. This provides precise purpose differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (update last result) and when not (use create_test_result for new execution). Also notes precondition that test case must already be a run item, and provides disambiguation hints for duplicate items. This is comprehensive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: immutability, automatic status computation, case-sensitive status values, and the inability to rename or move. It also explains the default statuses.
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 structured with a clear 'IMPORTANT' section and front-loads critical limitations. However, it is somewhat verbose; a slightly more concise version would improve readability without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (12 parameters, nested objects, no output schema), the description is comprehensive. It covers creation constraints, parameter details, defaults, and references sibling tools, leaving minimal gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (83%), but the description adds meaningful context beyond the schema, such as the requirement for Jira user keys, folder existence precondition, and case sensitivity of statuses. This adds value while the schema already documents most parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a Zephyr Scale test run, specifying the key format (PROJ-R123). It distinguishes from siblings by explaining that after creation, updates to executions should use test result tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns about the API v1 limitation: the test run is immutable after creation. It advises passing the complete list of items now and points to test result tools for later updates, providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses critical behavioral traits: immutability, absence of PUT endpoint, inability to rename/move/add/remove items, automatic status computation. No contradictions.
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?
Two well-organized paragraphs: first gives core purpose, second details limitations and alternatives. Efficient with no redundant text. Could be slightly more concise, but structure is good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with 2 parameters and no output schema, the description provides all necessary context: what it does, limitations, and related tool. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Both parameters have schema descriptions (100% coverage). The description adds valuable context about the return including items and status computation, which supplements the schema. Slightly above baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Read'), the resource ('Zephyr Scale test run by key'), and the scope ('including its items'). It distinguishes this tool from siblings like get_test_run_results and create_test_run.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (to read a test run by key) and when not to (immutable after creation, no PUT). Provides alternative: use get_test_run_results for execution results. No ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description extensively discloses behavioral traits: return structure (`startAt`, `maxResults`, `count`, `isLast`), the `isLast` heuristic, pagination defaults, server-side default for `maxResults`, and strict TQL syntax rules. This goes far beyond the `readOnlyHint` annotation.
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 paragraph with multiple sentences, each providing essential information. It is front-loaded with purpose and contains no redundant or irrelevant details. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no output schema, the description fully explains the return structure and pagination behavior. It covers all necessary aspects for correct usage, including TQL syntax and common fields, making it complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds substantial value: TQL syntax examples for the `query` parameter, default values for `startAt` and `maxResults`, explanation of server-side default, and behavior of `fields` as comma-separated list. This significantly enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Search Zephyr Scale test plans with a TQL query (GET /testplan/search)', clearly stating the verb, resource, and method. It distinguishes this tool from siblings like `search_test_cases` and `search_test_runs` by specifying test plans.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides detailed usage guidance on TQL syntax, pagination parameters, and common fields. While it doesn't explicitly state when to use this tool versus alternatives, the context and sibling names imply it is for test plans specifically.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully covers behavioral traits: composite operation (read, merge, write), position behavior (append/prepend/clamped integer), preservation of existing step ids, and return value { key, totalSteps }.
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?
Five sentences, front-loaded with purpose, efficient and no wasted words. Every sentence adds essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the operation (composite read-merge-write, position logic, script type restrictions) and lack of output schema, the description covers all necessary context completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by explaining position options in detail, clarifying that steps carry no ids, and noting the 'Call to Test' special step.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource: 'Add steps to a STEP_BY_STEP test case without losing the existing ones.' It clearly distinguishes from sibling tools like set_test_script, which is for other script types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: only when the script is STEP_BY_STEP or no script yet. Provides a clear alternative: for PLAIN_TEXT or BDD scripts, use set_test_script instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With empty annotations, description fully covers behavior: recursive handled client-side, auto-creation on 400, no auto-creation by other tools, and API limitation (cannot list folders). Discloses that id must be saved for later use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively long but every sentence adds value. It is well-structured: purpose first, then parameter details, then behavioral notes. Could be slightly more concise, but justified given complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 4 parameters (2 required), the description covers all necessary context: usage, parameter semantics, behavioral quirks, dependencies (rename_folder). Complete guidance for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions, but the description adds significant context: explains name must be full path from root, recursive default true and client-side handling, projectKey defaults to environment variable. This goes beyond schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a Zephyr Scale folder for test cases, test plans, or test runs. It specifies the resource and action, and distinguishes from sibling tools like create_test_case and create_test_run by noting they do not auto-create folders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: when to use (before test case/run creation), name format (absolute path starting with /), recursive behavior, and hierarchical name convention. Also advises keeping the numeric id since the API cannot list folders, and notes rename_folder needs it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses detailed step-by-step synchronization behavior, immutability of projectKey, format constraints (e.g., BDD script body rejection), and return value structure. The idempotentHint annotation is not contradicted; partial update semantics support idempotency.
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?
Every sentence adds value; logically ordered from basic update to step sync rules to alternative tool suggestion to return value. Appropriate length for the complexity, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 15 parameters, nested objects, and complex step synchronization, the description covers all critical behaviors, constraints, and return values. No output schema but return format is described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage, and description adds critical extra context: owner must be Jira user key, folder must exist, BDD text restrictions, step id logic, and custom fields. Enhances understanding beyond schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool updates a Zephyr Scale test case via PUT, with explicit 'PARTIAL update' behavior. It distinguishes from siblings like add_test_steps and get_test_case by referencing them for alternative workflows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: never send empty placeholders, step synchronization logic (id-based create/update/delete), and advises using add_test_steps for simply adding steps. Clearly states when to use this tool vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that filePath must be an absolute path on the MCP server's local disk and describes the return value format, including a fallback when API returns empty body. No annotations exist, so description carries full burden and handles it well.
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?
Well-structured with clear labeling of sections (Addressing, Pass ONLY...). Each sentence adds value; no redundancy. Concise enough while covering all necessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (7 parameters, 3 targets, file system dependency, optional step addressing, non-standard response), the description is thoroughly complete, leaving no ambiguity for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, yet description adds crucial context: relationship between target and identifier parameters, key format examples, and constraints like 'no step addressing for runs'. This goes far beyond the schema's property descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states 'Upload a file as an attachment to a Zephyr Scale test case, test run or test result — optionally to a single step'. Clearly distinguishes from sibling tools like download_attachment or delete_attachment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides detailed guidance on selecting parameters based on target, explains that stepIndex only applies to test_case and test_result, and references other tools for obtaining test result IDs. Includes explicit instruction to 'Pass ONLY the identifier that matches the chosen target'.
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:

[![zephyr-scale-mcp MCP server](https://glama.ai/mcp/servers/vilaabo/zephyr-scale-mcp/badges/card.svg)](https://glama.ai/mcp/servers/vilaabo/zephyr-scale-mcp)

Score Badge

Copy to your README.md:

[![zephyr-scale-mcp MCP server](https://glama.ai/mcp/servers/vilaabo/zephyr-scale-mcp/badges/score.svg)](https://glama.ai/mcp/servers/vilaabo/zephyr-scale-mcp)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/vilaabo/zephyr-scale-mcp'

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