testlink-mcp-server
Server Quality Checklist
Latest release: v1.0.0
- Disambiguation5/5
Each tool targets a distinct resource and action, such as list_projects vs create_project, read_test_case vs get_custom_field_value. Even similar tools like list_test_cases_in_suite and get_test_cases_for_test_plan are clearly differentiated by context (suite vs plan) and description.
Naming Consistency4/5The naming pattern is predominantly verb_noun (list_, create_, update_, delete_, read_, get_). Minor inconsistency between read_ and get_ (e.g., read_test_case vs get_requirement) but the pattern is otherwise predictable and readable.
Tool Count3/5With 30 tools, the server is on the heavier side, but the count is justified by the breadth of the TestLink domain (projects, suites, cases, requirements, plans, builds, executions). Still, it feels slightly over-scoped, especially with several caveat-ridden delete methods.
Completeness4/5The tool set covers the main lifecycle for projects, test suites, test cases, test plans, builds, and executions. Minor gaps exist (e.g., no update_test_plan, no update_requirement, no delete_requirement), but they can be worked around and do not critically hinder core workflows.
Average 3.6/5 across 30 of 30 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.jsonto 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?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states that the tool creates a requirement, which implies a write operation, but does not describe side effects, permission requirements, or potential errors. No additional behavior is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that avoids verbosity. It is efficient and to the point, though it could include more guidance without becoming wordy. It scores well for conciseness but is under-specified for the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a create operation with 8 parameters, 5 required, no annotations, and no output schema. The description is far too terse to be complete. It lacks information about required fields beyond the raw schema, the meaning of optional fields, prerequisites, or expected outcomes. Comparable to the 'update_drive' example, this mutation tool needs significantly more context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, with just docId and reqSpecId having descriptions. The tool description adds no parameter-level meaning and does not compensate for the 75% of undocumented parameters. It mentions the containing specification but not the fields or their intended values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create), the resource (requirement), and the container (requirement specification), effectively distinguishing it from sibling tools like create_requirement_specification and list_requirements. The parenthetical API method reference (tl.createRequirement) adds concrete grounding.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when this tool should be used versus alternatives such as create_requirement_specification. It does not mention prerequisites (e.g., an existing requirement specification) or scenarios where this tool is appropriate, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only states the action without mentioning side effects like appending vs overwriting results, permission requirements, or impact on existing data. This is a significant gap 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently states the tool's purpose without unnecessary words. It is appropriately sized for the minimal information it conveys.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (13 parameters, no annotations, no output schema), yet the description provides almost no additional context beyond the basic purpose. It does not explain return values, how to specify test case identifiers, or what reporting against a build entails, making it inadequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not add meaning to any of the 13 parameters. With schema description coverage at only 38%, the description fails to compensate by clarifying key parameters such as testCaseId, buildId, or the overwrite behavior, leaving most parameters semantically opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reports a test case execution result against a build within a test plan, using a specific verb and resource. It also includes the underlying API method name, distinguishing it from sibling read/update operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions or related tools such as read_test_execution, leaving usage context entirely to the agent's inference.
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 behavioral traits. It only states that the tool creates a build, without mentioning side effects, reversibility, required permissions, or what happens to the test plan. For a mutation operation, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is easy to parse and front-loads the core operation. It avoids unnecessary words, though it may be too brief to serve other dimensions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but without an output schema or annotations, the description should explain return behavior, prerequisites, or relationship to other operations. It does none of this, leaving the agent without context about the build lifecycle or dependencies.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must add meaning to the parameters. It partially clarifies testPlanId by stating 'under a test plan', but it does not explain buildName or buildNotes beyond their names. The description adds minimal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create'), the object ('a new build'), and the context ('under a test plan'), unambiguously distinguishing this from sibling tools like list_builds and close_build. The parenthetical API mapping (tl.createBuild) further reinforces the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as close_build or create_test_execution. There is no mention of preconditions, sequencing, or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral transparency. It only discloses the basic read operation ('List') and that execution status is included. It does not mention potential side effects, authentication requirements, pagination behavior, or what happens if no test cases are found. The description adds a small behavioral detail (execution status) but otherwise leaves most behavioral aspects undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no fluff, front-loading the core purpose. It also includes the API method reference in parentheses, which is useful for verification. It is appropriately sized for a simple list operation, though it could be slightly expanded to cover parameters without becoming overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no output schema, and no annotations, the description is insufficient for an agent to fully understand how to invoke the tool correctly. It lacks explanations for filter parameters, return value format, and any contextual prerequisites. The description alone does not tell the agent what buildId, assignedTo, or getStepsInfo mean, nor does it clarify how the 'execution status' is presented in the output. This leaves significant gaps for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 13% (only executeStatus has a description), so the description must compensate for the lack of parameter explanations. It fails to do so. The description mentions 'execution status' but does not explain the meaning or purpose of parameters like buildId, executed, keywordId, assignedTo, testCaseId, or getStepsInfo. It does not add any semantic value beyond what the schema already (minimally) provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the function: 'List the test cases (with execution status) attached to a test plan.' The verb 'List' is specific, the resource is test cases attached to a test plan, and it includes the underlying API method (tl.getTestCasesForTestPlan). This distinguishes it from sibling tools like list_test_cases_in_suite by specifying 'test plan' rather than 'suite.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: when you need the test cases for a specific test plan. However, it does not explicitly state when to use this tool versus alternatives (e.g., list_test_cases_in_suite for suites) or any exclusions. There is no mention of conditions like 'use this only if you have a test plan ID' or 'for suite test cases, use list_test_cases_in_suite.' Thus, usage guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavioral traits. It only says 'Link', but does not clarify whether assignments are appended, replaced, or require certain permissions. No side effects, idempotency, or error behavior is disclosed, which is critical 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that avoids unnecessary wording. It is appropriately concise for a brief overview, though it sacrifices substance for brevity. There is no wasted text; every word contributes to the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity—three required parameters, a nested assignments array, and no output schema—the description is far too sparse. It lacks context on parameter relationships, expected results, error conditions, and when to use the tool. The agent would need to infer too much from the schema alone, making the description insufficient for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, with only 'assignments' having a description. The tool description adds minimal parameter meaning—'one or more requirements' hints at the array nature of assignments but does not explain the roles of testCaseExternalId, testProjectId, or the structure of assignments beyond what the schema already provides. It fails to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Link') and resource ('requirements to a test case'), immediately conveying the tool's function. It also references the underlying API method (tl.assignRequirements), which aids in API mapping. The action is distinct from sibling tools, none of which describe linking requirements to test cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, nor any mention of prerequisites (e.g., test case and requirements must exist) or exclusion conditions. The description merely states what the tool does but does not contextualize its usage among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses the read-only nature via 'Fetch' and the 'last' semantics, but does not describe error behaviors, permission requirements, or what happens if no execution exists. As a read operation, the risk is lower, but the description lacks rich behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that clearly states the action and scope. The parenthetical function name adds technical reference without bloating. Each element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 8 parameters, no output schema, and no annotations. The description fails to explain parameter relationships, the meaning of 'last', return format, or edge cases. While the core purpose is clear, the surrounding context is underdeveloped.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only mentions test plan, build, and platform conceptually without explaining any of the 8 parameters (e.g., getBugs, testCaseExternalId, buildName vs buildId). This is insufficient for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Fetch' and identifies the resource as 'the last execution result for a test case within a test plan/build/platform.' This clearly distinguishes from siblings like read_test_case or create_test_execution by focusing on execution results.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. It does not mention exclusions or compare with other read tools like read_test_case or list_builds. The context 'within a test plan/build/platform' implies filtering but does not explain 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states that a test case is created, without disclosing behaviors such as duplicate name handling (block, generate_new, create_new_version), whether it validates existence of parent entities, or what the response contains. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no fluff. It immediately states the action and resource. However, it is so brief that it sacrifices necessary context, which slightly reduces the effectiveness of its conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool has 12 parameters and no annotations or output schema. The one-sentence description is far too minimal to guide an agent on required inputs, optional behaviors, or expected results. It leaves significant gaps in how to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, and the description adds no parameter-specific meaning beyond mentioning 'test suite'. The schema itself does describe a few fields (authorLogin, executionType, actionOnDuplicatedName), but the description fails to compensate for the low coverage, leaving many parameters undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create') and the resource ('a new test case'), and specifies the context ('inside a test suite'). This distinguishes it from sibling tools like create_test_suite or update_test_case, so the primary purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to add a test case to a suite) but provides no explicit exclusions or alternatives. It doesn't mention prerequisites like needing a valid testProjectId or testSuiteId, nor does it contrast with create_test_suite. The context is understood but not elaborated.
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 fully disclose behavioral traits. It only states the action without mentioning side effects, required permissions, failure modes, or that the referenced project must already exist. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, waste-free sentence that front-loads the core purpose. However, it is under-specified for a tool with five parameters and no annotations, making it too terse to be fully '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.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and sparse schema descriptions, the description carries the full burden for explaining how to invoke the tool. It covers only the basic purpose and omits prerequisites, return values, and error behaviors, so it is not complete enough for reliable use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20%, and the description adds almost no parameter-level meaning. The phrase 'inside a project' hints at the testProjectName parameter, but it does not elaborate on required testPlanName or the optional notes, active, and public fields, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Create'), the resource ('test plan'), and the context ('inside a project'), distinguishing it from sibling tools like create_test_suite or create_test_case. It also includes the underlying API method name for added specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a new test plan needs to be created, but provides no explicit when-to-use or when-not-to-use guidance. It does not mention prerequisites such as the need for an existing project, nor alternatives like listing existing plans or adding test cases to a plan.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It mentions optional nesting, but it does not explain that creation is a permanent write operation, any permission requirements, duplicate-name handling behavior (despite parameters for it), or what the response contains. This is minimal disclosure for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core purpose. The inclusion of 'tl.createTestSuite' is redundant technical detail but does not significantly harm readability. It is appropriately concise, though slightly under-specified for the number of parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, no output schema, and no annotations, the one-sentence description is insufficient. It does not cover duplicate handling, return value, permissions, or how ordering works. Sibling tools exist but are not referenced. The description leaves many practical questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 29% (2 of 7 parameters have descriptions), so the description must compensate. It adds meaning for parentId via 'nested under a parent suite' and testProjectId via 'inside a project', but it provides no guidance on testSuiteName, order, checkDuplicatedName, or actionOnDuplicatedName. The description does not sufficiently explain the parameter semantics for a tool with many optional parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a test suite within a project, and it distinguishes itself from sibling tools like create_project or create_test_case by specifying the resource type ('test suite') and the action ('create'). The optional nesting detail adds further specificity. This is a strong, unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: if you need to create a test suite, use this tool. However, it does not explicitly mention when not to use it or suggest alternatives (e.g., update_test_suite for existing suites). No exclusions or comparisons are provided, so while the context is clear, it lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the intent to list all test plans, but does not clarify whether the result includes archived plans, pagination behavior, or the structure of returned objects. The parenthetical API method provides minimal additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise—a single sentence that immediately states the tool's purpose. The parenthetical API method is optional but not distracting. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with a single parameter and no output schema. The description covers the core purpose, which is sufficient for basic selection, but it misses details about return values, edge cases, or how the parameter maps to the 'project' concept. Given the low complexity, a score of 3 reflects a minimally viable but incomplete description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has a single parameter (testProjectId) with no description, and schema description coverage is 0%. The description only implies the parameter is connected to 'for a project' but does not explicitly identify testProjectId as the project identifier or explain how to determine its value. It adds very little beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List') and resource ('test plans') with a specific scope ('for a project'). It also includes the underlying API method (tl.getProjectTestPlans), which adds implementational clarity. This distinguishes it from sibling tools like list_test_suites or list_builds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to choose this tool over alternatives. It does not mention prerequisites, exclusions, or contrast with similar listing tools such as list_test_suites or list_builds.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden for behavioral disclosure. It only states that a container is created, without mentioning side effects, permissions, preconditions, or what happens to existing data. It does not satisfy the transparency needed for a create 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with the main action front-loaded. Every word contributes to the core purpose, and there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter create tool with no annotations and no output schema, this description is insufficient. It does not explain required fields, return values, preconditions, or how the container relates to the broader requirement workflow beyond a brief hint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 57% of parameters, so the description should compensate for remaining gaps, but it does not. 'Parent grouping' loosely relates to parentId but adds no information beyond the schema's existing description. No parameter-specific guidance is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Create') and resource ('requirement specification container'), and distinguishes this tool from sibling create_requirement by noting it is the 'parent grouping for requirements'. This makes the tool's unique role immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool ('parent grouping for requirements') but does not explicitly state when to choose it over alternatives like create_requirement. No exclusions or direct comparison to sibling tools are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only adds the API method name and does not disclose return format, pagination, whether it is read-only, or how the 'deep' and 'details' parameters affect behavior. This leaves significant behavioral uncertainty for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and front-loaded with the core action and resource. It is succinct with no wasted words, achieving maximum conciseness while still conveying the essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is too terse to be complete. It does not explain the parameters (deep, details), what the return value looks like, or any edge cases. For a tool with three parameters and no structured safety annotations, this level of detail is insufficient for an agent to use it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 33%, and the description does little to compensate. It implicitly references testSuiteId by saying 'in a test suite' but does not explicitly explain any parameter, though the schema does have descriptions for deep and details. The description adds minimal value beyond the raw parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the resource 'test cases contained in a test suite', which precisely identifies the tool's function. It also includes the underlying API method (tl.getTestCasesForTestSuite), further clarifying its purpose and distinguishing it from sibling tools like list_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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for retrieving test cases from a suite, but it does not explicitly state when to use it versus alternatives or any exclusions. Since there is no direct sibling for listing test cases in a suite, the lack of explicit alternatives is acceptable, but the guidance remains implicit rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Add', implying mutation, but does not disclose side effects, permissions, idempotency, or error conditions. The parenthetical function name adds no behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core purpose. The parenthetical function name is redundant but not verbose enough to lower the score further.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters, 4 required, and no output schema or annotations, the description is too sparse. It does not explain return values, parameter relationships, or usage prerequisites, leaving the agent uncertain about correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It provides minimal context for 'version' and 'platform' but does not explain the required parameters like testProjectId, testPlanId, or testCaseExternalId, nor optional ones like urgency and executionOrder.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: adding a specific test case version to a test plan, with an optional platform filter. This verb+resource pair is specific and distinguishes it from sibling tools like 'get_test_cases_for_test_plan' or 'read_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for associating a test case version with a test plan, which provides clear context for when to use it. However, it does not mention alternative tools or when not to use it, so it lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It adds a useful caveat about API availability, but does not disclose the destructive nature, impact on dependent entities, permission requirements, or reversibility of the deletion. This is a significant gap for a delete 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first clearly states the action, and the second provides a critical caveat. There is no redundant information, and the structure is effective and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description provides the essential purpose and a critical availability check, but it lacks important context such as destructive side effects and error behavior. It is minimally sufficient but not complete, especially without annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (testSuiteId) with zero description coverage. The description does not explain what testSuiteId is, how to obtain it, or its format. Although the parameter name is self-explanatory, the description adds no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Delete a test suite' with a specific verb and resource, clearly distinguishing it from sibling tools like create_test_suite and update_test_suite. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The caveat instructs the agent to run list_available_api_methods first to confirm server support, which is useful operational context. However, it does not explicitly state when to use this tool over alternatives or provide exclusions, so usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It adds the important caveat that the underlying API method may not be available on most installations, which is a non-obvious behavioral trait. However, it does not disclose other aspects like the destructive nature (though the verb 'delete' is self-evident) or any permissions or permanence, 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose in the first sentence. The second sentence adds a critical caveat in an efficient manner, with no wasted words. It is appropriately sized for a simple delete tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of annotations/output schema, the description provides the essential caveat about API availability but omits parameter semantics. It does not explain what happens on success or failure, but for a delete operation this may not be critical. Overall, it is moderately complete but has clear gaps in parameter guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and the description does not mention the testPlanId parameter at all. The parameter name and type are present in the schema, but no additional meaning is provided, such as where to find the ID or its format. With low schema coverage, the description should compensate but fails to do so.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Delete a test plan.' with a specific verb and resource, clearly distinguishing it from sibling tools that delete other entities like delete_test_suite. The purpose is unambiguous and immediately understood.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance by instructing to run list_available_api_methods first to confirm the server exposes the API, effectively telling the agent when to use this tool. It does not explicitly mention alternatives, but the caveat implies it should not be used if the method is unavailable, which is a clear prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosure. The word 'Read' clearly indicates a non-destructive operation, and the version scoping adds context. However, it does not mention return format, error behavior, or permissions, which would be useful but 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that effectively front-loads the core purpose without extraneous information. Every word contributes to understanding what the tool does.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read tool with 4 required parameters and no output schema, the description adequately states the purpose but omits details about the return value format and potential errors. This is a moderate gap, as the agent cannot infer what the tool returns, but the operation is sufficiently scoped by the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, with only customFieldName described. The description does not elaborate on any parameter meanings, though the purpose sentence implies the roles of testCaseExternalId, version, testProjectId, and customFieldName. Given the low schema coverage, the description should compensate but does not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'custom field's value for a specific test case version', making it distinct from sibling tools like update_custom_field_value. The mention of 'tl.getTestCaseCustomFieldDesignValue' further reinforces the exact function call.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a custom field value for a particular test case version is needed, but it does not explicitly state when not to use it or mention alternatives (e.g., read_test_case for full test case details). The 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavior. It implies a read operation via 'Fetch' but does not explicitly state that it is read-only, nor does it describe what happens if neither ID is provided, if both are provided, or if the test case is not found. The behavior beyond identification is largely undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the core functionality and lookup modes, with no redundant wording. The inclusion of the API method name adds reference value without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite being a simple read tool, the absence of an output schema and annotations means the description should explain the return value and error behavior. It does not, leaving agents uncertain about what the tool returns or how failures are handled. The description is adequate for identifying the tool but incomplete for operational use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover all three parameters, so the baseline is 3. The description adds useful relational context by indicating that IDs are alternatives and that version is optional with external ID, which is slightly beyond the schema but not extensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (fetch), resource (test case), and identifies two lookup methods (internal id or external id with optional version). It also includes the API method name (tl.getTestCase) for reference. This distinguishes it from sibling read tools like read_test_execution and get_requirement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on how to identify a test case (by internal or external ID) and notes the optional version parameter. However, it does not explicitly mention when to use this tool over alternatives or any exclusions. Since no alternative for reading test cases exists among siblings, this is clear but not fully 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?
No annotations are provided, so the description carries the full burden. It states the mutation ('Create') but does not disclose potential side effects, permission requirements, or behavior on duplicate names. For a create operation, this is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, with no filler. Including the API method name adds useful context without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and high schema coverage, the description is acceptable but minimal. It lacks information about project name uniqueness, validation rules, or the response format, but these are not strictly necessary for a basic create tool. The absence of annotations and output schema leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for 8 of 9 parameters (89% coverage), including details like 'Short prefix used to generate test case external IDs'. The description itself adds no parameter-level detail, but with high schema coverage, 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new TestLink test project, using the specific verb 'Create' and the resource 'test project', and even includes the API method name 'tl.createTestProject' for disambiguation. This distinguishes it from sibling create tools like create_test_suite and create_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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: use this to create a new test project. However, it does not explicitly state when to prefer this over alternatives, nor does it mention any prerequisites or exclusions. Given the simple nature of the operation, this is sufficient but not exemplary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only mentions API availability and omits whether deletion is permanent, what data is affected, or required permissions. The caveat is useful but does not cover the core behavioral expectations of a destructive 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, with the main purpose as a clean first sentence and a critical caveat in the second. No waste, no redundant phrasing, and important warning is front-loaded after the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter delete tool, the description covers the purpose and a key availability caveat, but with no output schema and no annotations it leaves out typical expectations like return value or confirmation behavior. It is minimally viable but lacks the detail an agent might need to fully trust and post-process the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description says 'by internal id', which clarifies that testCaseId is a system-internal identifier, but it does not specify format, examples, or how to obtain the ID. Since schema description coverage is 0%, this modest clarification raises the score from 1 to 3, but the parameter semantics remain thin.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the specific resource ('a test case'), with the qualifier 'by internal id' distinguishing it from side-effect-free reads and other delete tools in the sibling list. It unambiguously tells an agent exactly what operation this tool performs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The caveat provides a clear usage prerequisite—verify server support via list_available_api_methods before relying on this tool. It does not explicitly state alternatives or exclusions, but for a targeted delete operation the usage context is sufficiently instructive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'List' implies a read-only operation, but the description does not state required permissions, pagination, response format, or whether any side effects occur. The API reference (tl.getRequirements) adds minimal behavioral context beyond the 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose and then lists scoping options. It contains no filler and is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no annotations and no output schema, the description covers the core purpose and scoping but leaves out behavioral details such as returned data structure, result limits, or how filters interplay. It is adequate for a simple list tool but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25% (only reqSpecId has a description). The description adds meaning by mapping three parameters to scoping concepts (test plan/platform/req spec), but it does not explain parameter formats or potential combinations. This partially compensates for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists requirements for a project, with optional scoping by test plan, platform, or requirement specification. This is a specific verb+resource+scope and distinguishes it from siblings like get_requirement (singular) and list_test_plans.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: listing requirements, optionally filtered. It does not explicitly name alternatives or exclusions, but the scoping context implies typical usage. It stops short of a full when-to-use/not-use guide.
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 of behavioral disclosure. It indicates the operation is a read (list) and scopes it to a test plan, which is helpful. However, it does not disclose details such as whether closed builds are included, pagination behavior, or the return format, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no redundancy. The parenthetical API reference adds useful context without length. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter read tool with no output schema, the description is mostly sufficient. It clearly defines the tool's purpose and scope. However, it could be more complete by mentioning any return value structure or edge cases (e.g., empty list, invalid testPlanId), but given the simplicity, it remains adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides only the parameter name 'testPlanId' with a type, but with 0% schema description coverage, the description must compensate. The description clarifies that the parameter refers to the test plan whose builds are listed, adding some semantic context. However, it does not explain the format or expected values for testPlanId, so compensation is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List every build') and the resource ('defined for a test plan'), with a specific and identifiable scope. It also references the underlying API method (tl.getBuildsForTestPlan), which adds specificity and distinguishes it from sibling tools like create_build or close_build.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to retrieve all builds for a given test plan, but does not explicitly state when to use this tool vs alternatives or mention any exclusions. There is no comparison to sibling tools such as list_test_plans or create_build, so the usage context 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.
- 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 does disclose an important behavioral nuance—that custom field values are stored per test case version, not just external id—which adds transparency beyond a basic write description. However, it omits other relevant behavior such as overwrite semantics, error conditions, or authentication requirements, leaving gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the main purpose, and includes only the critical contextual detail about versioning. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main purpose and the critical version/project id requirement, but it lacks information about expected outcomes or error behavior (no output schema exists). Given the tool is a write operation without annotations, the description could be more complete by mentioning success/failure signals or side effects, so it is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 25%, so the description must compensate. It adds meaning by explaining why version and projectId are needed (values belong to a specific version), and mentions the external id in the rationale. It does not, however, elaborate on the structure or constraints of the customFields array, leaving that to the schema's example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Write one or more custom field values on a test case') with a specific resource and operation. It also includes the underlying API method name for additional clarity, and the verb 'write' distinguishes it from sibling read tools like get_custom_field_value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context on when to use this tool by stating the hard requirement for exact version and project id, explaining the per-version storage model. It does not explicitly name alternatives or exclusions, but the prerequisite guidance is clear and helpful for correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the key limitation that no custom field parameter exists, which is helpful, but it does not mention mutation consequences, required permissions, return behavior, or version handling. It is better than a bare statement but still leaves significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the core purpose, and wastes no words. It earns every sentence by combining purpose, identification method, and a critical alternative in a compact format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no output schema, and no annotations, the description is far from complete. It explains only the tool's high-level purpose and one exclusion, but omits parameter semantics, return value, error conditions, and behavioral nuances, so an agent would struggle to invoke it correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only clarifies the external ID and the absence of a custom field parameter. The other seven parameters (steps, summary, version, importance, etc.) remain unexplained, leaving the agent without semantic guidance for building a correct request.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates fields on an existing test case and explicitly identifies the required identifier (external id). It also distinguishes itself from sibling update_custom_field_value by noting that tl.updateTestCase has no custom field parameter, 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 Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete guidance on when to use this tool vs. alternatives: use it for updating standard test case fields, and use update_custom_field_value for custom field values. This explicit alternative and exclusion is exactly what the dimension asks for.
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 are present, so the description carries the transparency burden. It discloses a critical behavioral trait (endpoint may not exist on most installations) and directs the user to verify beforehand. However, it omits other behavioral details like side effects or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence followed by a caveat. It is concise, front-loaded, and contains no filler, making it easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description provides the critical caveat but lacks additional context such as what 'closed/inactive' means functionally, any prerequisites, or how testPlanId relates to buildId. It is minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain the two parameters (buildId, testPlanId) beyond their names. Since the description must compensate for the lack of schema documentation, this is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Mark a build as closed/inactive') with a specific resource (build) and target state. This distinguishes it from sibling tools like create_build and list_builds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides an explicit usage caveat: first run list_available_api_methods to confirm the endpoint exists. This is actionable guidance for when to use the tool, though it does not cover alternatives or non-caveat scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosure. It adds the underlying API method names and describes the conditional behavior, but does not explicitly state read-only nature, pagination, or return format. For a simple list operation, this is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the primary action and then provides conditional detail. Every word contributes to understanding the tool's behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, 1 required, no output schema), the description is sufficient to understand what to pass and what to expect. It explains the two modes clearly. It might benefit from mentioning return values, but the absence is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 essentially restates the parentSuiteId behavior already documented in the schema, adding no new semantic detail. It does not fully compensate for any potential gaps, but none exist given full schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifically states the tool lists test suites, distinguishing top-level suites for a project from child suites when parentSuiteId is supplied. This clearly identifies the tool's purpose and differentiates it from sibling tools like list_test_cases_in_suite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when to use parentSuiteId to list child suites versus top-level suites, which guides usage. However, it does not explicitly name alternative tools or state when not to use this tool, leaving some room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It reveals a critical non-obvious behavioral trait: tl.updateTestSuite may not exist on standard installations, and a pre-check is required. This adds valuable context beyond the schema, though it doesn't cover all side effects or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, and the caveat earns its place. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters, no output schema, no annotations, and zero schema coverage, so a richer description is expected. It provides the main purpose and the critical availability caveat, but omits return value expectations, error handling, and any constraints on parentId or order. This is adequate but leaves notable gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It lists the updatable fields ('name, details, parent, order') which map to parameters, but does not add any deeper semantics like value constraints, relationships between parentId and existing suites, or behavior of the 'order' parameter. This is a minimal mapping, not sufficient compensation for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Update') with a clear resource ('existing test suite') and lists the updatable fields (name, details, parent, or order). This strongly distinguishes it from sibling tools like create_test_suite and delete_test_suite.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The caveat explicitly instructs running list_available_api_methods first to confirm the API exists, which is a clear when-to-use prerequisite. It doesn't explicitly name alternatives for create/delete, but the purpose already implies the context clearly.
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 of behavioral disclosure. It correctly indicates a read-only operation ('List') and the authentication scope, but omits details about return structure, ordering, or potential limitations. This is adequate for a simple no-parameter tool but could be richer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It includes only essential information: the action (list), the object (projects), and the scope (visible to API key).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description sufficiently conveys the core function and access control. The phrase 'List every...' implies a list return, and the authentication scope is a critical detail. It is complete enough for its simplicity, though an explicit return-format note could push it higher.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema covers 100% trivially. Per the baseline for 0 parameters, a score of 4 is appropriate; the description adds no parameter details because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List', identifies the resource as 'TestLink test project', and clarifies scope with 'visible to the authenticated API key'. This clearly distinguishes it from sibling list tools for other entities (e.g., list_test_suites) and avoids tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it obvious when to use this tool: whenever a user needs to enumerate TestLink projects. It does not explicitly state alternatives or exclusions, but no sibling tool provides equivalent functionality, so the context is clear and no further guidance is necessary.
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 and adds useful behavioral detail: it reveals that TestLink has no direct single-requirement lookup and that this tool fetches all requirements for the project and filters client-side, implying performance characteristics and why testProjectId is needed. It stops short of describing not-found behavior or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the action, and each sentence earns its place. No filler or redundant restatement of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-fetch tool with no output schema and no annotations, the description adequately covers what the tool does and its mechanism. It lacks explicit return value details or error handling, but the complexity is low and the behavior is reasonably predictable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It does add meaning by explaining that requirementId or docId are the lookup keys and that testProjectId provides the project scope because the underlying API fetches all project requirements. It does not clarify whether docId and requirementId are mutually exclusive or what happens if both are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and resource ('single requirement') and clearly distinguishes this from sibling list_requirements by specifying single-record lookup by requirement id or doc id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context: use when you need one requirement by id/doc id, and explains the TestLink API limitation that forces client-side filtering. It does not explicitly name list_requirements as the alternative but the contrast is implied by 'single requirement' vs the listing behavior.
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 reveals the best-effort nature, the probing mechanism (multiple calls per candidate), and the filtering behavior (only fields with non-empty values are returned). It also discloses the API limitation. Missing details like permissions, error handling, and performance impact, but core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each delivering essential information: the overall goal, the API context and limitation, and the required inputs/behavior. There is no fluff or redundancy. It is front-loaded with the tool's purpose and provides all necessary guidance in a compact form.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the workaround nature, input requirements, and return filtering (only non-empty values). Since there is no output schema, this suffices to set expectations. It doesn't cover error handling or what happens if no fields match, but for a discovery tool with no annotations, the provided context is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context beyond the schema: it explains that testCaseExternalId is a 'representative test case' and that candidateFieldNames come from the admin UI. With 50% schema coverage, this compensates for missing descriptions. It doesn't detail version and testProjectId, but they are self-explanatory from names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as custom field discovery via probing, and distinguishes it from the sibling get_custom_field_value by explaining the API's limitation (no enumeration endpoint, only reading named field values on a test case). It specifies the resource (custom fields for a project) and the action (list/discover), making it 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: when needing to discover custom field definitions for a project, given the API limitation. It also describes preconditions (a representative test case and candidate field names). However, it does not explicitly name alternatives or exclusions, so it doesn't fully meet the 'explicit when/when-not' standard.
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 are provided, so the description carries the burden of behavioral disclosure. It adds context by mentioning it uses standard system.listMethods introspection and points out the non-standard nature of other methods. However, it does not explicitly state that the operation is read-only or safe, though 'list' strongly implies no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and every sentence adds value. The first sentence states what it does, the second provides usage guidance. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is complete: it explains what the tool does, how it works (via system.listMethods), and when to use it. The lack of output schema is fine because the description implies a list of method names as the return value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is trivially 100%. The description does not need to explain parameter semantics because there are none, and the baseline for 0 params is 4. The description adds no parameter info, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists every XML-RPC method the TestLink server exposes via system.listMethods. It uses a specific verb ('List') and resource ('every XML-RPC method'), and distinguishes itself from sibling tools by focusing on introspection of available methods.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool: to check availability of non-standard methods before calling update_test_suite, delete_test_suite, delete_test_case, delete_test_plan, and close_build. It also explains why (those methods are not part of every stock TestLink installation), providing clear context.
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:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/adama007/MCP-TESTLINK'
If you have feedback or need assistance with the MCP directory API, please join our Discord server