Qase MCP Server

Official

by qase-tms

Overview Schema Related Servers Score Discussions(1)

TypeScript

Remote

Server Quality Checklist

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

Latest release: v2.1.1
Disambiguation4/5
Most tools target distinct actions: upserts for cases/defects/runs, result recording, search, and context retrieval. The main overlaps are between qase_defect_upsert/qase_triage_defect and qase_run_upsert/qase_ci_report, but the descriptions clearly differentiate use cases. With 13 tools, only a couple pairs could be confused.
Naming Consistency3/5
All tools share a qase_ or qql_ prefix and use consistent snake_case, but the verb/noun order varies: qase_case_upsert and qase_defect_upsert follow entity-action, while qase_triage_defect and qase_discover_tools follow action-entity, and qase_project_context and qase_regression_run are noun phrases. This inconsistency makes the naming pattern somewhat unpredictable.
Tool Count5/5
13 tools is within the ideal 3-15 range for a test management server. Each tool addresses a distinct workflow or entity, and composite tools like qase_ci_report and qase_regression_run earn their place by reducing multi-step operations.
Completeness3/5
The core workflows (case/run/defect management, result recording, search, project context) are covered, but direct operations for deletions, milestone management, and attachments are absent from the visible set, requiring qase_discover_tools or qase_api as workarounds. This leaves notable gaps for a full test management lifecycle.
Average 4.2/5 across 13 of 13 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- 12 of 14 community issues answered or closed in the last 6 months
- No commit activity data available
- Last stable release on August 13, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate it's not read-only, not idempotent, and not destructive. The description adds the key behavioral fact that the tool performs an upsert and notes limited update support in the Qase API. However, it does not disclose what happens to omitted fields during updates or other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence that efficiently conveys the core behavior. Every word is necessary, and no information is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 13 parameters and no output schema, the description lacks needed context. It does not explain the return value, error handling, or how the test run is structured. Users must rely solely on the input schema for parameter understanding.
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 54%, so the description is not required to extensively cover parameters. The description clarifies the role of the 'id' parameter for distinguishing create vs. update, which adds semantic value beyond the schema. However, it offers no further explanation for other parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it creates or updates a test run, with the logic based on the presence of an 'id' parameter. It directly conveys the dual purpose, though it does not explicitly distinguish itself from sibling tools like qase_case_upsert or qase_defect_upsert.
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 only explains the id-based upsert logic but does not mention prerequisites, limitations, or scenarios where other tools would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds feature context ('powerful filtering and cross-project queries') but does not disclose additional behavioral traits such as pagination behavior, rate limits, or query validation. No contradiction 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?
The description is a single, front-loaded sentence with no wasted words. It immediately communicates the verb and resource, making it highly efficient and well-structured.
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 QQL, the description is minimal but sufficient because the schema provides detailed query syntax examples and the output schema is present. It adds the key differentiator of cross-project search. Mentioning qql_help for further syntax guidance would improve completeness, but the existing structured data compensates.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with detailed examples for the query parameter and clear limit/offset descriptions. The description's mention of 'powerful filtering' adds little beyond the schema's rich examples, so it does not significantly enhance 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 a specific action ('Search') on a resource ('entities') using a distinct method ('Qase Query Language'), and highlights 'cross-project queries' which distinguishes it from sibling tools like qase_get and qql_help.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the appropriate tool for complex, filtered QQL searches but does not explicitly state when to use it over alternatives like qase_get or when to consult qql_help. No exclusions or alternative tool references are 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?
The description discloses a key behavioral trait: 'the API offers no way to attach existing runs or results to a defect — the runs/results seen on a defect are populated by the test runner when a result is reported as a defect.' This adds valuable context beyond the annotations, which only indicate readOnly=false and openWorld=true. It does not contradict any 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?
The description is three sentences long, front-loaded with the purpose, and every sentence adds value—the purpose, the mandatory fields, and a critical API limitation with a workaround. No wasted words or redundancy.
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 the core use case and a critical limitation, which is good for a create tool with an output schema. However, it omits the required 'code' parameter entirely and does not address optional parameters like tags, attachments, or custom_field. Given 8 parameters and nested objects, this is a noticeable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds some meaning for actual_result ('Reference failing results in actual_result instead') and clarifies that severity is 'Required by the API,' but it incorrectly states 'Requires title, actual_result, and severity' while omitting 'code,' which is also required per the schema. With only 50% schema description coverage, the description fails to compensate and introduces a misleading requirement list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create a defect from a test failure,' which uses a specific verb ('Create') and resource ('defect') with a clear context ('from a test failure'). This clearly differentiates it from the sibling tool qase_defect_upsert, which likely supports update operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for use ('from a test failure') and gives important guidance about how to handle the API limitation: 'Reference failing results in actual_result instead.' However, it does not explicitly mention alternatives or when not to use this tool, and the statement about required fields is incomplete.
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=false (write operation) and destructiveHint=false. The description adds valuable context about the conditional create/update behavior and the server-side normalization of enum labels/IDs, which goes beyond the structured annotations. 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?
The description is two sentences, front-loaded with the core action, and provides precisely the essential information about upsert behavior and enum flexibility. No wasted words or redundant repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (21 parameters, nested objects, no output schema), the description is functional but sparse. It covers the primary upsert behavior and enum normalization, but does not mention the required `code` and `title`, the nested step structure, or expected response shape. The schema fills many gaps, but a richer description would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 48% schema description coverage, the description partially compensates by explaining that enum fields accept both labels and numeric IDs. However, it does not add detail for the many other undocumented parameters, leaving the schema descriptions to carry most of the burden. The added enum guidance is useful but limited.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Create or update a test case,' which is a specific verb+resource pair that clearly identifies the tool's function. It further specifies the behavior based on the presence of `id`, distinguishing it from sibling tools like defect or run upserts.
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 gives clear context on when to use upsert semantics (update if `id` provided, create otherwise). It does not explicitly mention alternatives or exclusions, but the resource is unambiguous, and sibling tool names already imply distinct purposes.
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 indicate a write operation (readOnlyHint=false) and non-idempotent behavior. The description adds valuable context: the dual create/update behavior based on 'id', and the effect of setting status to 'resolved'. No contradiction 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 concise, front-loaded sentences with no redundant information. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, 2 required, and no output schema, the description covers the core behavior but lacks details on update semantics (partial vs full overwrite), response format, and handling of optional fields like 'custom_field'. More completeness would aid 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?
Schema coverage is only 44%, so the description should compensate. It adds meaning only for 'id' (controls create vs update) and 'status' (can set to resolved). Other parameters like 'tags', 'severity', 'actual_result', and 'attachments' are not explained beyond the schema. The description partially compensates but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create or update a defect', specifying the verb and resource. It distinguishes between creation and update based on the presence of 'id', differentiating this tool from sibling tools like qase_case_upsert or qase_run_upsert.
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 guidance on when to create (id omitted) vs update (id provided), and includes an example for resolving a defect via status. It does not explicitly compare with sibling tools like qase_triage_defect, but the context is sufficient for basic usage.
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 creates a run, records results, and optionally completes the run, adding behavioral context beyond annotations. Annotations indicate non-readonly and non-idempotent, consistent with the description. 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 two sentences long, with no wasted words. The first sentence states the primary function, and the second provides context and efficiency benefit. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters (3 required) and no nested objects, and an output schema exists, the description covers the high-level behavior well. It explains the single-call workflow vs alternatives, though it could mention return values or error scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has descriptions for all parameters (83% coverage based on context), so the description adds little on parameter meaning. The description does not elaborate on parameters beyond what's in the schema, so a baseline 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 the tool reports CI/CD test results in one call, replacing a multi-step workflow. It specifies the verb 'report', the resource 'CI/CD test results', and distinguishes from sibling tools like qase_result_record or qase_run_upsert by emphasizing the combined operation.
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 says it is 'designed for CI pipeline integration' and replaces a manual 3-4 step workflow, providing clear context. While it doesn't explicitly list when not to use it, the intended use case is well communicated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false (mutating) and destructiveHint=false. The description adds that it creates the run and adds cases, but does not elaborate on side effects, retry behavior, or how it handles conflicting parameters. Annotations cover the key behavioral traits; description adds marginal 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?
Three concise sentences, front-loaded with the core purpose, and no redundant information. Every sentence adds value.
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 8 parameters and the existence of an output schema, the description adequately covers the selection logic and workflow. However, it could mention that only one selection method should be used at a time. Still, for a complex tool with good schema support, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 63%, and the description adds value by explaining how parameters like suite_ids, include_cases, and plan_id interact for case selection, which is not fully captured in individual schema descriptions. This helps the agent understand that only one selection method should be used.
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: setting up a regression test run in one call, with specific case selection methods (suite IDs, explicit case IDs, plan ID). It distinguishes from siblings by emphasizing the one-call regression workflow and efficiency over the multi-step alternative.
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?
Implicitly suggests usage for regression runs and replacing multi-step workflows, but lacks explicit guidance on when not to use it or direct comparison to alternatives like qase_run_upsert. Still, the description provides clear context for appropriate use.
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 safety profile (readOnlyHint=false, destructiveHint=false). Description adds behavioral context: bulk API for multiple entries, single for one. 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, front-loaded with purpose, efficient and no fluff.
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?
No output schema, and description does not explain return value or error conditions. Adequate for a write operation but could be improved.
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 detailed parameter descriptions. Description adds value by emphasizing 'status required; case_id recommended,' which is not redundant.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool records test results into a run, with specific details about single vs bulk API usage. It distinguishes from sibling tools like qase_run_upsert and qase_case_upsert.
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 single vs bulk (single result vs array), but does not explicitly mention when not to use this tool or provide alternatives like qase_ci_report.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-readonly, non-destructive, and open-world. The description adds that it's a 'direct API call' but lacks details on error handling, rate limits, or side effects beyond 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?
Three sentences, front-loaded with purpose, no redundant information. Every sentence earns its place.
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?
Adequate for an escape hatch tool with 4 parameters and no output schema. Covers basic usage and context, though could elaborate on response behavior.
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 descriptions for all parameters. The description reinforces the path format and method usage, adding value 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's function as a direct Qase REST API call for endpoints not covered by other tools, distinguishing it from sibling tools and specifying the escape hatch role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use when dedicated tools don't cover the use case, and provides an external API reference. This clearly differentiates from 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 and idempotentHint=true; the description adds value by explaining the activation behavior and that it searches for tools, which is beyond the annotation data.
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 three concise sentences that front-load the purpose and usage, with 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 output schema exists (implied) and annotations are present, the description sufficiently covers the tool's behavior for selection and invocation, though it omits details like error handling on activation.
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 enriches parameter meaning by providing concrete example queries and explaining the activate and category parameters' purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches for and activates additional Qase tools, distinguishing it from sibling tools that perform specific CRUD operations.
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 the tool (to find tools for specific needs) and provides example queries. It does not explicitly state when not to use it, but the context 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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds contextual behavior by listing which entities require `code` and mentioning field projection support. It does not disclose rate limits or error behavior, but the annotation coverage lowers the burden.
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 long, front-loads the core purpose, and uses every word to convey entity scoping and field projection. No redundant or filler content.
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 rich schema and safety annotations, the description is complete for a generic retrieval tool. It explains the two key operational constraints (code requirement per entity type, field projection) and covers the main usage decision. No output schema exists, but return format is standard and implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing baseline 3. The description adds meaningful semantic detail about `code` by enumerating exactly which entities need it, and reinforces the purpose of `fields`. This goes beyond what the schema alone 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 states clearly it gets any Qase entity by type and ID, using a specific verb and resource. It distinguishes from sibling tools like qase_case_upsert or qase_run_upsert by focusing on retrieval, and adds specificity by listing entity categories.
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 important usage context: it specifies when the `code` parameter is required (project-scoped entities) and when it can be omitted (global entities). However, it does not explicitly mention alternatives or when not to use this tool relative to siblings, so it falls short of a full 5.
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 readOnly/idempotent annotations, the description discloses caching ('Cached for 5 minutes'), pagination defaults ('first 100 entities by default'), truncation reporting via 'coverage' field, and the cost/behavior of 'full: true' ('costs one API call per 100 entities'). These are valuable operational details not present in 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?
The description is five sentences, front-loaded with the tool's purpose and value, then usage guidance, then pagination behavior. No redundant or tangential 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?
With annotations declaring read-only/idempotent and an output schema present, the description covers the necessary aspects: what the call returns at a high level, when to use it, caching, pagination limits, truncation handling, and full-page behavior. This fully equips the agent to decide when to call and how to interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters with high detail ('code' format, 'full' behavior), giving 100% coverage. The description reinforces the 'full' parameter's purpose and mentions checking the 'coverage' field, but adds little new parameter-level semantics 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's function: 'Get full project context in one call' and enumerates the included data types (suites tree, milestones, environments, custom fields, users). It also distinguishes from sibling tools by positioning it as the initial call that avoids '6 separate list calls,' making the purpose specific and differentiated.
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 gives explicit when-to-use guidance: 'Use this as the first call when starting work with a project.' It also provides exclusions and alternatives: 'prefer the targeted list tools or qql_search when you only need a subset.' This clearly sets usage boundaries.
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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds the behavioral detail that only one section is returned per call and that the agent should request a specific topic, which is useful beyond the annotations. No contradiction exists.
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 three sentences, with the main purpose front-loaded, followed by concise usage guidance. Every sentence adds value, and there is no redundant or vague text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with a rich enum schema and helpful annotations, the description fully covers what the tool does, how to use it, and which topic to choose. No output schema is needed for a reference section, and the description is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with a detailed enum description for the topic parameter. The description adds use-case mappings for certain topics (entities, aggregation, enumValues), which goes beyond the schema's per-option descriptions and helps the agent decide which parameter value to use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get one section of the Qase Query Language (QQL) reference.' It uses a specific verb ('Get') and resource ('QQL reference'), and distinguishes itself from the sibling qql_search tool, which is for executing queries, by focusing on retrieving documentation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on which topic to use in different scenarios ('Start with "entities" when you are unsure which fields an entity has... "aggregation" to count or summarise without paging, and "enumValues" for valid field values') and warns against requesting the whole reference ('ask for the section you need rather than the whole reference'). This helps the agent choose correctly.
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:

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

Score Badge

Copy to your README.md:

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

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

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