TestDino MCP

Server Quality Checklist

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

Latest release: v2.0.2
Disambiguation3/5
Some tools have overlapping purposes or very similar names, such as list_testcase vs list_manual_test_cases and get_testcase_details vs get_manual_test_case, which differ only by 'manual'. Additionally, get_run_details and get_ai_insights both surface AI insights, requiring careful attention to the polling flow. Descriptions are detailed and help differentiate, but the boundaries are not always crisp.
Naming Consistency3/5
Most tools follow a verb_noun pattern, but object naming is inconsistent: 'testruns' vs 'test_run' vs 'run', and 'testcase' vs 'test_case' (e.g., list_testruns vs list_run_test_cases, list_testcase vs list_manual_test_cases). The tool 'health' breaks the pattern, and pluralization is inconsistent (list_testcase vs list_manual_test_cases). Still, the style is readable and mostly uniform.
Tool Count2/5
35 tools is a very large surface for an MCP server, even for a comprehensive QA platform. While the scope is broad (automated runs, manual cases, releases, sessions, integrations, AI, audit), many tools are CRUD variants that could potentially be combined or streamlined. The count exceeds the threshold for 'too many' and would likely increase selection difficulty.
Completeness3/5
The tool surface covers CRUD for manual test cases, releases, manual runs, and sessions, but lacks delete operations for these entities (e.g., delete_manual_test_case, delete_release, delete_session). Automated test runs are read-only (list/get) with no way to trigger or modify them. The audit flow and integrations are well covered, but the missing lifecycle operations are notable.
Average 4.3/5 across 35 of 35 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 8 commits in the last 12 weeks
- Last stable release on August 10, 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only implies a read operation. It does not disclose any side effects, authentication needs, or rate limits. The description carries full burden but adds minimal behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and return fields. Second sentence adds parameter clarification. Efficient, though could be slightly more concise if merged.
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?
Return fields are listed, and parameter semantics are partially explained. However, no output schema is provided, and the description does not cover error handling or the relationship to sibling tools like get_run_details. Adequate but missing some context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds an example for runId (counter-style ID like 'RUN-12'), which is helpful but not essential. No additional meaning for projectId.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets full details of one manual test run and lists included fields. It distinguishes from list_manual_runs but not from get_run_details, which may be ambiguous. Overall, specific verb and resource are clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like get_run_details or list_manual_runs. The description assumes the user knows when to retrieve a single run, which is not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It states the tool creates a test case, but does not mention any side effects, required permissions, rate limits, or error handling. For a creation tool, this minimal transparency is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading the core purpose. Every sentence adds value, and there is no redundancy or wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 19 parameters and no output schema. The description lacks information about what the tool returns upon success (e.g., ID of created test case) or potential errors. Given the complexity, the description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with detailed parameter descriptions. The description adds marginal value by summarizing supported fields ('test steps, preconditions, postconditions, and metadata'), but does not provide additional meaning beyond what the schema already conveys. Baseline 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's action ('Create a new manual test case') and resource ('manual test case'). It distinguishes from sibling tools like create_manual_run or create_manual_test_suite by specifying it's for documenting test scenarios, features, or requirements.
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 'Use this to document new test scenarios, features, or requirements,' which provides clear usage context. However, it does not mention when not to use it or suggest alternatives (e.g., use create_manual_run for executing test cases), so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose side effects. It does not mention what the tool returns (no output schema), whether it requires permissions, or if names must be unique. Behavioral context like idempotency or error handling is absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, clear sentences with no wasted words. Front-loaded with the primary 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 the main purpose and nesting, but fails to explain the return value or any behavioral constraints (e.g., uniqueness of names). Given the lack of output schema and annotations, the description should provide more context to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all 4 parameters. The description adds minimal value by mentioning parentSuiteId for nesting, but otherwise restates schema info. 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 'Create a new test suite folder to organize test cases,' specifying the action (create) and resource (test suite folder). It differentiates from siblings like create_manual_test_case and create_manual_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?
It explains when to use the tool ('logical grouping for related test cases') and mentions nesting with parentSuiteId. However, it does not explicitly exclude alternatives or provide 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description indicates a read-only list operation but does not disclose additional behavioral traits such as pagination, default sorting, or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences long, front-loaded with the action and usage, and efficiently lists capabilities without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite 13 parameters and no output schema, the description omits output format, default behavior, and sorting, leaving the agent without crucial information for effective invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds no extra meaning beyond the parameter descriptions; the list of filter types is 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 specifies 'Search and list manual test cases with filtering capabilities,' using a specific verb-resource pair that distinguishes it from sibling tools like list_manual_test_suites.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides context for use cases (QA testing, auditing, test management) but does not explicitly state when not to use it or mention alternatives like get_manual_test_case for single retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, pagination, ordering, or depth of hierarchy. The description is too minimal for a tool without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no superfluous information. The first sentence states the action and value, the second provides usage guidance.
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 input parameters well but lacks output details (e.g., response format, pagination) since no output schema is provided. It is adequate but leaves gaps for an agent expecting return value information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents both parameters fully. The description adds no additional meaning beyond the schema, resulting in a baseline score of 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 tool lists the test suite hierarchy and explicitly connects it to finding suiteIds for test case creation, which distinguishes it from sibling list tools and gives a specific use 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 advises using it to navigate the test suite structure and understand organization, but does not provide explicit exclusions or alternative tools when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses important behaviors: requires write permission, explains selectionMode options, warns about tags format mismatch with list_manual_runs, and notes state normalization. This adds good context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with 5 sentences covering essential points. It is front-loaded with the primary purpose and permission. While not bulleted, the information density is good and no unnecessary words.
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 15 parameters and no output schema, the description covers key aspects (permission, selectionMode, tags, state, note) but omits details about return value, some less common parameters (forecast, attachments), and potential error conditions. It is adequate for typical use but incomplete for edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful insights for several parameters: explains selectionMode's effect with 'all' vs 'selected', clarifies tags format (JSON array not comma-separated), and describes state normalization. This goes beyond the schema's enum and type info.
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 new manual test run.' with a specific verb and resource. It distinguishes from sibling tools like update_manual_run or list_manual_runs 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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool over alternatives (e.g., when to use create_manual_run vs create_manual_test_case). It only mentions a write permission prerequisite, which is necessary but not comparative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. The verb 'Fetches' and 'Returns current issue details' indicate a read-only operation, and the tie to create_external_issue adds context. However, it doesn't disclose error scenarios, provider-specific read behaviors (e.g., Jira target), or authentication requirements beyond what the schema offers.
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 concise sentences, front-loaded with the main action and resource. The second sentence adds functional value by clarifying the return and the intended use case. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read tool with four parameters and no output schema, the description covers the core behavior, applicable providers, and the relationship to create_external_issue. The return structure is only vaguely described as 'current issue details including status,' which is a minor gap but tolerable given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all four parameters described in the schema. The description reinforces that issueIds can be IDs or keys, but it doesn't add meaningful semantics beyond what the schema already provides, so the 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 fetches previously created external issues by ID or key and returns current details including status. The verb 'fetches' plus the specific resource (external issues from multiple providers) makes the purpose unambiguous and distinct from sibling tools like create_external_issue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit use case: 'Use this to check whether issues filed via create_external_issue are still open or have been resolved.' This gives clear when-to-use context, though it doesn't explicitly name alternative tools or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It implies a read-only operation by stating 'Get...' but does not explicitly disclose behavioral traits like permissions, side effects, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, concise and front-loaded with the purpose, listing key fields. Every sentence adds value with no 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?
With no output schema, the description adequately lists the returned fields (name, mission, status, etc.). It covers the main aspects of the tool for a retrieval operation given two simple required parameters.
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 both parameters. The description adds semantic value by explaining sessionId accepts both internal _id and counter-style IDs like 'SES-12', which is not in 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 gets full details of an exploratory session and lists specific fields (name, mission, status, assignee, etc.). It also distinguishes from siblings like list_sessions and update_session by specifying it retrieves a single session.
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 explains what the tool does but does not provide explicit guidance on when to use it vs alternatives or when not to use it. The sibling list offers implicit context but no direct usage recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses pagination defaults (page size 25, max 200) and state normalization behavior. However, it omits other traits like authentication requirements, rate limits, or what happens on empty results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the core purpose, then efficiently enumerates filters and defaults. Every clause earns its place with no 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?
For a list tool with 12 parameters and no output schema, the description covers all filter types, pagination defaults, and special values. It lacks details on the return format (though inferred) and ordering, but remains adequate for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (6 out of 12 parameters described). The description adds value for 'releaseId' (special value 'none') and 'state' (normalization), but fails to explain 'environment', 'isClosed', 'sortBy', 'sortOrder', and 'page' 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 a specific verb 'Browse' and resource 'manual test runs', clearly distinguishing it from sibling tools like 'get_manual_run' (single run) and 'list_run_test_cases' (test cases within a 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 lists all filter options, including special values like 'releaseId=none'. While it doesn't explicitly contrast with alternatives, the context of browsing vs. getting a single run is clear from sibling names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that write permission is required and explains that sending only specific fields in the `updates` object achieves a partial update. It also enumerates all updatable fields, which is useful. However, it does not state return value or error behavior, leaving some gaps.
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 two sentences: the first states the purpose, the second gives the key instruction and list of fields. It is concise and front-loaded with the action, with no redundant fluff. The field list is long but necessary for quick reference, though it somewhat duplicates the schema.
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 tool has a nested object and moderate complexity, and the description covers purpose, permission, and partial-update behavior. However, it does not mention any return value or outcome (e.g., whether the updated release is returned), nor does it address edge cases like empty `updates` objects or invalid fields. Since there is no output schema, a brief mention of expected response would improve 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?
The input schema description covers 100% of parameters with basic descriptions, so baseline is 3. The description adds meaningful semantic value beyond the schema by explaining the partial-update mechanism for the `updates` object ('Send only the fields you want to change'), which clarifies how the nested object should be used. This pushes it above baseline.
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 'Modify an existing release,' using a specific verb and resource that clearly distinguishes it from sibling tools like create_release and get_release. It also states the partial-update nature, 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by saying 'Modify an existing release,' which suggests you would only call this when a release already exists, but it does not explicitly mention alternatives like 'use create_release for new releases' or 'use get_release to view.' No exclusions are listed, so guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals key behaviors: the two identification methods, the requirement to pair testcase_name with testrun_id due to duplicate names, the detailed return payload, and the effect of steps_filter='failed_only' in stripping passing steps. This is strong disclosure, though it omits potential rate limits or auth requirements, which are not critical for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a tight paragraph that front-loads the purpose, then efficiently covers identification methods, return contents, the filter option, and a usage example. Every sentence adds necessary information without redundancy, making it concise 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?
Despite having 12 parameters and no output schema, the description provides a complete overview of the main workflows: how to identify a test case, what data to expect, and how to narrow results. It does not cover deprecated parameters or history settings, but those are fully documented in the schema. The description is sufficient for correct tool selection and 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 description coverage is 100%, so the baseline is 3. The description adds valuable semantics beyond the schema by explaining when testcase_id can be used alone versus when testcase_name must be combined with testrun_id, and by clarifying the effect of steps_filter. This helps the agent correctly assemble parameters, raising the score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: 'Get detailed information about a specific test case.' It lists the returned data types (error message, code snippet, logs, artifacts), which helps distinguish it from generic list tools. However, it does not explicitly differentiate itself from sibling tools like debug_testcase, so it misses the top score for sibling distinction.
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 practical usage context: 'Use this to debug why a test failed or understand how it executed' and includes a concrete example. It does not mention alternatives or exclusions, but the context is sufficiently clear for an agent to know when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses read-only browse semantics, search behavior (commit messages or exact run counter), pagination support, return fields (statistics, duration, etc.), and the TESTDINO_PAT setup requirement. It stops short of explicitly stating 'does not modify anything', but 'browse and filter' implies a non-mutating operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than minimal but well-structured: purpose, filters, pagination, return values, examples, auth note. Some filter details are redundant with the schema, but the examples and return-value description justify the length. It is front-loaded and organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 12-parameter tool with no output schema, the description covers filter semantics, return summaries, pagination, and authentication. It misses an explicit note on default time interval or handling no results, and the offset/limit mention conflicts with the schema. Overall, it is quite complete for the complexity.
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 the baseline is 3. The description adds helpful examples (branch names, environment values, time intervals, tag '@' prefix) but also introduces a potential inconsistency by mentioning 'offset/limit' pagination even though 'offset' is not a schema parameter. This ambiguity prevents a higher score.
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 a specific verb+resource ('Browse and filter your test runs') and clearly states the tool's scope: finding specific test executions. It differentiates from siblings like get_run_details and list_run_test_cases by focusing on run-level filtering rather than details or test-case listing.
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 usage context with concrete examples ('Perfect for answering questions like...') and enumerates the filter dimensions. It does not explicitly name alternative tools or state when not to use this tool, so it misses the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description bears full responsibility. It discloses the output contents but does not address permissions, side effects, or idempotency. As a read operation, it is adequate but not rich in transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the tool's purpose and output, the second explains the parameter. No redundant information, every sentence is essential.
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 lists the types of details returned (dates, status, etc.), providing a reasonable overview. However, it lacks specification of exact structure or permissions needed for a fully complete context.
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 provides 100% coverage with descriptions for both parameters. The description adds value by specifying that releaseId accepts counter-style IDs like 'MS-12', which goes 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 'Get the full details of one release' and enumerates the specific details included (dates, status, linked issues, parent/root, progress stats). It also explains the releaseId parameter accepts two formats, distinguishing it from list_releases.
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 retrieving full details of a single release, contrasting with list_releases. However, it does not explicitly state when to choose this over siblings or mention any preconditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral burden. It discloses that the tool 'surfaces clusters of tests sharing the same root-cause error' and supports filtering by status. This gives the agent a clear understanding of the analysis behavior without side effects or safety details, which are not needed for this read-only grouping operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each with a distinct purpose: (1) states the main function, (2) gives usage context with a preceding tool, and (3) explains the optional filter and required parameters. No unnecessary words or redundancies.
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?
The tool has 3 parameters, no annotations, and no output schema. The description covers the purpose, workflow (after list_testruns), and parameter constraints (requires projectId and testrun_id). It also implies the output (clusters of tests by error signature). This is sufficient for moderately complex tool, though it does not describe pagination or result size, which could be helpful.
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 provides 100% parameter descriptions, so the baseline is 3. The description adds a brief note about the status filter meaning ('failed' shows definitively failed tests, etc.), but this mostly restates the schema's enum descriptions. No additional syntax or format details are provided.
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: 'Groups failing tests in a run by error signature to identify patterns and triage failures at scale.' This specific verb+object+goal distinguishes it from sibling tools like get_run_details or debug_testcase, which address different aspects of test runs.
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 'Use this after list_testruns to drill into why a run failed,' providing clear workflow context. It also explains the status filter, but does not explicitly mention when NOT to use the tool or name alternatives beyond the sequential dependency.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must convey behavioral traits. It discloses pagination defaults (page size 25, max 200) but does not explicitly state that the operation is read-only or non-destructive, nor mentions authentication or rate limits. The absence of annotations increases the burden, and the description partially meets it.
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: purpose, filter list, and pagination default. It is front-loaded with the core action and immediately provides actionable filtering details. No extraneous 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?
The description covers the main functionality (filtered list) and pagination, but lacks any mention of the response structure or return value. Given the absence of an output schema, this omission is notable. However, for a typical list tool, the description is reasonably 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 description coverage is 54%. The description adds meaningful context beyond the schema: it explains that state accepts both canonical and display forms (with normalization), assigneeUserId accepts ID or email, and releaseId='none' for unlinked sessions. These details help correct usage. However, some parameters (sortBy, sortOrder, page) are only indirectly mentioned via the page size note, leaving gaps.
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 ('Browse exploratory sessions') and the resource ('for a project'). It distinguishes from siblings like 'get_session' (single session retrieval) and 'list_manual_runs' (different resource).
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 lists multiple filters and gives examples like releaseId='none', but does not explicitly contrast with alternative tools (e.g., 'list_manual_runs') or state when not to use this tool. It implies usage for filtered browsing but lacks explicit when-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?
With no annotations, the description carries the full burden. It discloses the OAuth URL return, the need for user browser authorization, and the already_connected behavior. Slight gaps remain on side effects or permissions, but the core behavior is well covered.
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 compact: three sentences with the main purpose front-loaded, and every sentence adds useful context without 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?
The description covers the return value (URL), the user workflow, and the alternative outcome (already_connected). No output schema exists, but for a simple URL-returning tool, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds little beyond what's in the schema, though it does list providers matching the enum. Baseline 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's purpose: 'Returns an OAuth connect URL for the requested integration provider' with a specific list of providers. This distinguishes it from sibling tools like get_integration_status and create_external_issue.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'Call get_integration_status first to check whether the provider is already connected' and 'Show the returned URL to the user — do NOT open it programmatically.' This clearly instructs when and how to use the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It explains permission requirements, nesting depth constraints, ISO date format expectations, and the independent semantics of isStarted/isCompleted vs startedAt/completedAt. This adds meaningful non-obvious context beyond the tool's name.
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 short sentences, each with a distinct purpose: stating the action, noting permissions and nesting, and clarifying date/flag semantics. It is front-loaded with the primary purpose and contains no filler or 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?
Given the tool's complexity (17 parameters) and the high schema coverage, the description fills in critical gaps such as permission roles, nesting constraints, and flag behavior. While it doesn't mention every edge case (e.g., default values or error conditions), the combination of schema and description is sufficient for a create operation with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 82%, so most parameters are already documented in the schema. The description adds extra value by clarifying parentReleaseId nesting depth and the relationship between isStarted/isCompleted and startedAt/completedAt, which are not fully explained in 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 opens with 'Create a new release,' a specific verb + resource that clearly states the tool's function. This distinguishes it from sibling tools like list_releases, get_release, and update_release, which perform different operations on the same resource.
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 practical usage context: it lists required write permissions (org_owner, org_admin, org_member) and explains how to use parentReleaseId for nesting with a max depth of 3 levels. However, it does not explicitly state when to prefer this tool over alternatives, though the name and sibling naming make that obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on the full burden of behavioral disclosure. It conveys that this is a read-only status check ('Reports whether') and describes the optional behavior of includeCreateOptions. It could be more explicit about response structure or lack of side effects, but the read-only nature is implied clearly enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences. The first sentence states the core purpose, the second provides usage guidance and explains an optional parameter. Every word earns its place, and the structure is front-loaded with the most critical 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?
The description covers the essential context: what the tool does, when to use it, and what optional behavior exists. Since there's no output schema, a more explicit description of the return format (e.g., connected boolean, provider details) would improve completeness, but the description is adequate for a status-check tool with a clear purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds value by explaining the purpose of includeCreateOptions and giving usage context, but the schema already documents each parameter thoroughly. No significant gap to compensate for.
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: 'Reports whether a third-party integration is connected for a project.' It enumerates specific providers (Jira, Linear, Asana, monday.com, GitHub) and distinguishes itself from siblings by explicitly referencing create_external_issue and connect_integration, making its purpose unmistakable.
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: 'Call this before create_external_issue or connect_integration to check whether the provider is already active.' This directly tells the agent when to use this tool and names the related alternatives, leaving no ambiguity about its positioning.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses default page size, max limit, nesting depth (3 levels), and case normalization for type. Lacks explicit read-only assertion, but browsing intent is clear. No annotations to contradict.
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, first covers purpose, second covers key filters and behaviors. No wasted words, information is 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?
Covers essential behaviors (pagination, nesting, filters) with 10 parameters and no output schema. Could mention sorting options, but schema enum suffices. Reasonably complete for a list 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?
Description adds value beyond schema by explaining default page size for limit, nesting behavior for parentReleaseId, and case normalization for type. Schema coverage 60% is reasonable, and description compensates well.
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 'Browse releases (a.k.a. milestones) for a project' with specific verb and resource. Distinguishes well from sibling tools like get_release (single) and create_release (creation).
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?
Provides explicit guidance on when to use each filter (search, type, isCompleted, parentReleaseId). Does not explicitly mention alternatives like get_release for a single release, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains that the tool returns rows with case identity, assignee, and status. No mention of destructive behavior or rate limits, but it is transparent about return data and filtering capabilities.
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 with four sentences, each adding value. It front-loads the purpose and UI analogy, then details row contents, filters, and a usage recommendation. No unnecessary 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 10 parameters and no output schema, the description is fairly complete: it describes the return fields, filters, and relationship to update_run_test_case. It lacks details on pagination and sorting but those are partially covered in the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 70%, and the description adds practical context beyond the schema, such as explaining that assignee can be email or User _id and that result accepts display or canonical forms. It also notes the alias status for result.
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 'Get the per-case execution records inside a manual run' with a specific verb and resource. It distinguishes from siblings like get_run_details and update_run_test_case by focusing on per-case execution records.
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 advises using this tool before update_run_test_case to obtain rtcRef. It provides clear context for filtering by assignee or result but does not explicitly exclude other use cases.
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 adds behavioral context: requires write permission, findings are not editable, and tags format requirement. Does not cover side effects or response behavior, but sufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured, each sentence adds necessary information without redundancy. 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?
Covers purpose, parameters, permissions, and specific field constraints. Lacks info on response or errors, but for a mutation tool with good parameter descriptions, it is fairly 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 100%, and description adds value by explaining partial update semantics, acceptable values for assigneeUserId, and required format for tags, exceeding schema details.
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 modifies an existing exploratory session, with a specific verb and resource. It distinguishes from siblings like create_session and other update tools.
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?
Provides guidance to send only changed fields inside the updates object, lists allowed fields, and notes what is not editable. Could be more explicit about when to use vs. alternatives, but overall 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 carries the disclosure burden; it reveals that write permission is required, incomplete findings are rejected and not stored, target only accepts {value, path}, and matching the audit context matters. It does not describe the response/error format or side effects of writeMarkdown, but the core mutation and validation behaviors are transparent.
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 long but front-loaded with 'FINAL STEP' and every sentence contributes operational value. It is dense and slightly repetitive around required fields, but given 13 parameters and zero annotations, the length is justified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex final-step mutation with no output schema, the description covers flow prerequisites, validation rules, orgId resolution, and reuse of context identifiers. It does not describe the return value or post-submission behavior, but the operational context is well covered overall.
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 already covers all 13 parameters, but the description adds valuable cross-parameter constraints: score plus markdownReport/markdownReportPath are required, findings must include title/summary/severity, and target is restricted to {value, path}. It slightly conflicts with the schema's required array (which lists only projectId, orgId, score), preventing full credit.
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 'FINAL STEP of the TestDino Playwright audit flow — submits a completed audit report,' giving a specific verb and resource and clearly distinguishing it from siblings like get_audit_report. It unambiguously communicates that this tool writes/submits a report rather than reading or querying data.
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?
It explicitly states 'Call this only AFTER get_audit_report(action='context') and after you have analyzed the local Playwright code and produced findings,' defining the exact prerequisite sequence. It also provides actionable guidance on resolving orgId via health() and reusing the same branch/scope/target from the context call.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses mutation behavior, write permission requirements, and the constraint that closed runs are mostly read-only. Warns about tags format (must be JSON array). No annotations provided, so description carries full burden; it does well but could mention idempotency or error handling.
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 paragraph with front-loaded purpose. Every sentence adds value without redundancy. Efficiently conveys purpose, constraints, and critical format note.
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?
Comprehensive for a mutation tool with 3 required params and no output schema. Covers allowed fields, special behavior for closed runs, and tags format. Lacks mention of return value or side effects, but sufficient for typical use.
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 description coverage is 100%, but the description adds significant value: lists allowed fields inside updates object, specifies tags format, and clarifies that runId can be internal _id or counter-style ID. This goes beyond the schema's 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 'Modify an existing manual test run' with a specific verb and resource. It lists allowed fields and distinguishes from sibling tools like create_manual_run and update_manual_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?
Provides explicit guidance: send only changed fields in updates object, requires write permission, and notes that closed runs are read-only except for releaseId. However, it does not name an alternative tool for modifying closed runs beyond releaseId.
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 carries the full burden and does so excellently. It discloses key behaviors: comments require PAT owner as author, server enforces a 20-comment cap with rejection past the cap, Jira issue linking falls back to plain text stubs when Jira is not connected or ticket not found, duplicate issue links are silently skipped, and attachments have a 10MB limit. These are valuable insights beyond basic 'updates' semantics.
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 longer than average but structured efficiently. It opens with a clear purpose, then gives usage guidance, then details specific behaviors for comments and issues. Every sentence adds value, though some redundancy with schema descriptions could be trimmed (e.g., issue resolution detail is repeated in the schema). Overall, it is appropriately sized for the tool's complexity.
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 3 required params, a nested updates object with many fields, no annotations, and no output schema, the description provides substantial context: partial update semantics, comment cap, Jira fallback, and attachment limits. However, it does not describe the return value on success (e.g., whether the updated test case is returned), which is a minor gap given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers all parameters with descriptions (100% coverage), so the baseline is 3. The description adds meaningful extra semantics by explicitly clarifying the partial-update behavior ('Provide only the fields you want to update'), and by providing usage examples for comments and issues (e.g., 'pass updates.comments as an array of strings'). This goes beyond schema descriptions and helps correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Update an existing manual test case' with specific actions ('modify test case details, steps, status, priority'). It distinguishes from siblings like 'create_manual_test_case' and 'update_run_test_case' by explicitly targeting existing manual test cases. The verb 'update' and resource 'manual test case' are 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 explicitly says 'Use this to modify test case details, steps, status, priority, or any other fields' and instructs to provide only fields to update. It gives concrete guidance for comments and Jira issues. However, it does not explicitly mention when not to use it or suggest alternative tools (e.g., update_run_test_case for run-level updates), so it lacks explicit exclusions or named 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?
No annotations provided, but description covers write permission, rich HTML for mission, minutes for estimate, dual input for assigneeUserId, state normalization, and tags format. Lacks mention of return value or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with key details front-loaded, but could be more concise with bullet points. No redundant 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?
Covers most critical aspects given 13 parameters and no output schema, but lacks return value description and error handling details.
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?
Adds significant value beyond schema: explains rich HTML for mission, email resolution for assigneeUserId, minutes for estimate, display vs canonical state forms, and provides explicit tags examples with a warning against comma-separated strings.
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 it creates a new exploratory testing session, differentiating from sibling create tools like create_manual_run or create_release.
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 permission requirement, clarifies that findings cannot be created via this tool, and warns about the tags format difference from list_sessions, guiding correct usage.
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?
No annotations, so description fully handles transparency. Discloses that versions and results are read-only, and details the activity inline with limits (latest 20 versions, latest 100 results). Leaves no ambiguity about behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is slightly verbose but each sentence serves a purpose. Front-loaded with main purpose, then details activity. Could trim a few words but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description thoroughly explains what is returned: steps, custom fields, preconditions, metadata, and activity with specifics. Covers parameters, limits, and behavior. Complete for its purpose.
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 useful semantics: projectId is TestDino identifier, caseId accepts internal _id or human-readable ID like 'TC-123'. Adds clarity beyond 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 it retrieves detailed info of a single manual test case, including steps, custom fields, preconditions, metadata, and activity. Distinguishes from update_manual_test_case and other get tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance to use update_manual_test_case for mutations. Implicitly clarifies that this is a read-only tool. Does not exhaustively list when to use over other get tools, but context is 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?
With no annotations, the description fully carries the behavioral disclosure burden. It explicitly discloses that the tool returns a runbook rather than performing the analysis itself, and that the agent must download the trace and run CLI commands locally—a key trait not inferable from the schema. This goes beyond typical descriptions.
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 dense but every sentence carries information: purpose, runbook protocol, parameter modes, and local execution. It is front-loaded with the main usage, though the length is somewhat high; a slightly tighter structure could improve scannability.
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 no annotations, the description is exceptionally complete: it explains what the tool returns (runbook), the CLI protocol steps, how to get hosted trace URLs, and the required local execution workflow. It covers both usage modes, leaving little ambiguity for an 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?
Although schema coverage is 100%, the description adds meaningful semantics: it clarifies that testcase_id is the Playwright pw_test_id, explains how projectId + testcase_id combine to generate a download URL, and notes that testrun_id optionally scopes the request. This helps the agent understand the relationships and intended 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 a specific verb ('Debug') and resource ('failing Playwright test from its trace.zip'), and differentiates from sibling tools by emphasizing the trace.zip/CLI runbook approach. It also explains the two modes (with/without IDs), making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage context: when to pass IDs to receive a download URL and when to omit them for local trace files. It also specifies that analysis runs locally, guiding the agent's workflow. However, it does not explicitly name alternative tools or state when not to use this tool, so it falls short of a 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?
With no annotations provided, the description carries the full burden and does so thoroughly. It discloses write permission requirements, that the server auto-creates records on first edit, that rtcRef accepts multiple ID formats, that assigneeUserId accepts email or _id, that result values are normalized, and that mixing quick and detailed fields is rejected.
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 dense and front-loaded with the core purpose, but it is on the longer side. However, every sentence adds essential behavioral or parameter detail, so no information is wasted. The 'IMPORTANT:' marker helps prioritize key facts.
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 a nested 'updates' object, no annotations, and no output schema, the description is remarkably complete. It covers input formats, server behavior, permission requirements, normalized values, and usage for multiple cases. It leaves little room for ambiguity.
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 schema coverage is 100%, the description substantially enriches parameter meaning: it gives concrete examples for rtcRef (TC-156, tcm_rtc_..., _id), clarifies assigneeUserId accepts email OR _id, enumerates canonical result values, and explains the mutually exclusive updates modes. This goes well beyond the schema's baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Set the assignee and/or result for one test case inside a manual run.' It uses a UI analogy to clarify the exact action and clearly distinguishes itself from sibling tools like update_manual_test_case by scoping to 'inside a manual 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 provides clear context: requires write permission, works for both touched and untested cases, and explicitly advises calling in parallel for multiple cases. It does not explicitly name alternative tools or say when not to use this tool, but the UI analogy and run-specific scope make the intended use 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?
No annotations are provided, so the description bears full responsibility for disclosing behavior. It does so thoroughly: preview mode returns a draft without creating (wouldCreate: false), idempotencyKey makes it safe to retry, and the tool returns a specific error code with a connect URL when the provider is not connected. These are meaningful behavioral details beyond simple write semantics.
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 information-dense without bloat. Every sentence adds value: purpose, required identifiers, preview behavior, idempotency, prerequisite call, and error-handling guidance. It is front-loaded with the main purpose and then logically expands into usage 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?
Despite having 9 parameters and nested objects, the description covers the essential context: what the source is, how to discover target fields, what preview does, idempotency, and error behavior. There is no output schema, so the description partially explains return values (draft, error code). It could be slightly more explicit about the full success response shape, but it is sufficiently complete for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds context that enriches parameter understanding, particularly source.type/source.id being required and resolved server-side into the issue draft, and the purpose of target being discoverable via get_integration_status. It doesn't rename or redefine every parameter, but it clarifies the relationships and usage of key fields enough to justify a score above baseline.
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 an action verb and specific resource: "Files an issue in a connected provider (Jira, Linear, Asana, monday.com, GitHub) from a TestDino source entity." It clearly differentiates from sibling tools like get_external_issue and connect_integration by specifying the action (file/create) and the source context.
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 instructs when to use it: "Call get_integration_status first (with includeCreateOptions: true to discover the provider fields available for target)." It also provides guidance for a specific error case (INTEGRATION_NOT_CONNECTED) and tells the agent to show the URL to the user rather than opening it programmatically. This is clear, actionable usage 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 provided, the description carries the full burden and does so thoroughly. It discloses that each execution includes testRunId/testRunCounter/branch, that AI insights are generated lazily and may report 'in_progress', and how to interpret the 'unavailable' status code. It also states that the AI client will analyze the data for root causes, setting expectations for the tool's role.
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 long but every section earns its place: purpose, return contents, parameter guidance, and error handling. It is front-loaded with the core purpose and includes an illustrative example. However, the AI-payload explanation is somewhat dense and could be condensed without losing essential 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 no output schema and no annotations, the description covers the key return components (raw historical data with test run details, test runs summary, debugging prompt, and optional ai_fixes) and explains the lazy AI generation and polling behavior. It does not fully detail the exact JSON structure of historical data, but it provides enough for an agent to use the tool and follow up appropriately.
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 schema already covers all five parameters (100% coverage), the description adds crucial semantics beyond the schema: it explains that testrun_id is only valid with include_ai_insights and targets a specific run rather than the most recent failure, and that suite_file_path disambiguates tests with identical titles. This enriches the parameter understanding beyond the schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Fetch historical execution and failure data for a specific test case.' It also explicitly states the intended use case ('Use this when you need to debug a failing test case') and provides an example, clearly distinguishing it from siblings like get_testcase_details or get_ai_insights.
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?
It gives clear when-to-use guidance ('Use this when you need to debug a failing test case') and explicitly names alternatives for follow-up actions: if ai_fixes status is 'in_progress', poll get_ai_insights instead of re-calling this tool; transient 5xx/timeout errors should be retried once via get_ai_insights, while 4xx errors are terminal. This is strong, actionable usage direction.
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 carries the full burden and exceeds expectations. It discloses batch limits (max 20), lazy generation of AI insights, status values ('processing'/'not_generated'), and the meaning of 'unavailable' sections including transient vs terminal upstream status codes. This gives the agent accurate expectations about side effects and retry behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than typical but well-structured: main purpose first, then AI insights specifics with actionable polling guidance. Every sentence adds operational value, though the AI Insights section is dense and could arguably be split, but it is necessary for correct invocation.
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 no output schema and no annotations, the description compensates thoroughly. It lists the returned data categories and details the structure of AI Insights, including failure categorization, clusters, cards, table, and summary. This provides a complete mental model for invoking the tool and interpreting results.
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, but the description adds meaning beyond the schema: it clarifies that include_ai_insights requires a single testrun_id (not counter/batch) and explains the lazy-generation behavior. It doesn't fully resolve the counter vs testrun_id ambiguity, but it enriches the understanding of parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get detailed information about test runs' and enumerates the specific data returned (statistics, suites, cases, git metadata, error details). It distinguishes itself from siblings like get_run_error_clusters and get_ai_insights by focusing on the full run details and batch operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use this to analyze test execution health or debug specific failures.' It also provides when-not-to-use guidance by directing users to poll get_ai_insights when AI insights are still processing, rather than re-calling this tool. This clarifies the boundary between the two 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?
With no annotations provided, the description carries full responsibility for behavior disclosure, and it excels. It details lazy generation, polling guidance, terminal states ('disabled'), transient vs. permanent errors (5xx vs. 4xx), and status vocabulary ('in_progress', 'processing', 'unavailable'). This is exemplary transparency for a tool with asynchronous behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and information-rich, with every sentence contributing value. However, it is a long wall of text without visual structure (e.g., bullet points or explicit mode headings), making it slightly harder to parse for an agent. The information density justifies the length, but a more structured format would improve scannability.
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 complex multi-mode tool with no output schema, this description is exceptionally complete. It covers all modes, parameter combinations, status handling, polling behavior, prerequisites, and even relates to sibling tools. An agent has enough context to select and invoke the tool correctly across a wide range of scenarios.
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 schema coverage is 100%, the description adds critical semantic meaning by explaining how parameter combinations map to the three modes. It clarifies that testrun_id alone triggers run mode, while testrun_id + testcase_id triggers case mode, and neither triggers project overview. It also explains the meaning of project-only parameters like dateRange and environment, enriching the schema significantly.
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 the tool retrieves TestDino's AI Insights at three distinct levels (project, run, case). It enumerates exactly what each mode returns and distinguishes itself from sibling tools like get_run_details and debug_testcase. The verb ('get') plus resource ('AI insights') with explicit scope makes the purpose immediately clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use guidance for each mode: project overview for 'what should we fix first?', run mode for triaging a run, case mode for fixes to a failing test. It also names sibling tools and describes when this tool serves as a poll target after get_run_details or debug_testcase report pending AI status, giving clear alternatives and prerequisites.
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 declares the tool as 'read-only', which is consistent with its behavior. It explains each mode's behavior in detail, including fetching audit prompts, browsing reports, and retrieving specific reports. It also includes important behavioral notes like auto-detection of branch and instructions to not write findings before the call returns.
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 long but well-structured: starts with overall purpose, then details each mode, then provides a trigger rule and full flow. Every sentence is informative, though some redundancy could be trimmed. It is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 (three modes, a trigger rule, and integration with other tools like submit_audit_report), the description covers all necessary context. It explains what each action returns, when to call the tool, and the overall workflow. No output schema is needed as the description sufficiently describes outputs.
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?
The input schema covers all 8 parameters with descriptions. The tool description adds significant extra context: for action='context', branch auto-detection behavior; for action='get', outputPath defaults and writeMarkdown effects; for action='list', page/limit usage. This adds value 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 it is a 'read-only' tool for TestDino Playwright audits, and enumerates three distinct modes via the action parameter. It distinguishes itself from sibling tools by focusing on audit report retrieval and reading.
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 provides a trigger rule: only use when user explicitly names TestDino. Warns against using for generic audits. Gives step-by-step flow instructions, including calling health() first if projectId is unknown. Provides comprehensive guidance on 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?
With no annotations, the description carries the full burden. It discloses exactly what happens (verifies PAT, shows account, lists orgs/projects with roles) and adds a caveat about the informational nature vs. security guarantee. This is more than sufficient for a read-only health check.
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 the primary purpose, then detailing behaviors and usage. Every sentence contributes value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description adequately explains what the tool does and returns (account, orgs, projects, roles). It also references workflow context by telling the user to use it first. Complete for this simple 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 has zero parameters, so the description need not explain parameters. The baseline for 0-param tools is 4; the description adds no unnecessary parameter details, which 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 checks TestDino connection, verifies PAT, shows account info, and lists orgs/projects. This specific verb and resource list distinguish it from sibling tools, which are all operational actions.
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 'Use this first' and explains it's for setup verification and obtaining org/project IDs for other tools. This gives clear when-to-use guidance and implies it's a prerequisite step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, and it excels: it reveals that missing run scope returns an empty result with a warning, limit values are snapped to allowed page sizes rather than rejected, cross-run filters resolve runs internally, and page/limit paginate within resolved runs. This level of detail is essential for an agent to predict behavior accurately.
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, dense paragraph but is well-structured: it opens with the core purpose, then explains run scoping requirements, cross-run filters, per-case filters, and pagination behavior. Every sentence adds essential information for a 20-parameter tool, and there is no fluff. It is appropriately sized for the 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 20 parameters, no output schema, and no annotations, the description adequately covers the run-scope requirement, the empty-result warning, pagination snapping, filter combinability, and cross-run resolution behavior. It provides enough context for an agent to determine the correct invocation and expected behavior, including error cases, without needing external documentation.
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 individual parameters are already well-documented. The description adds value by providing a mental model: the distinction between run scopes (by_testrun_id/counter) and cross-run filters (by_branch, etc.), and the statement that per-case filters can be combined with any run scope. This goes beyond the schema's itemized descriptions, though it duplicates some schema content like limit snapping.
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 with a specific verb and resource: 'List test cases with comprehensive filtering options.' It immediately distinguishes itself from sibling list_testruns by explaining that cross-run filters resolve runs internally, so users don't need to call list_testruns first. This is a clear, specific purpose that differentiates it from similar list 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?
Provides explicit usage guidance: 'Provide a run scope: by_testrun_id or counter for specific runs, OR a cross-run filter...' and even states 'you do NOT need to call list_testruns first,' directly addressing an alternative tool. It also warns about the empty-result case without a run scope and explains pagination semantics. These are clear when-to-use and when-not-to-use instructions.
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:

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

Score Badge

Copy to your README.md:

[![testdino-mcp MCP server](https://glama.ai/mcp/servers/testdino-hq/testdino-mcp/badges/score.svg)](https://glama.ai/mcp/servers/testdino-hq/testdino-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/testdino-hq/testdino-mcp'

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