tarn-mcp

by NazarKalytiuk

Overview Schema Related Servers Score Discussions

Rust

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Tools are largely distinct, but tarn_run and tarn_run_agent overlap in purpose despite differing modes, and tarn_last_failures/tarn_last_root_causes/tarn_report have subtle granularity differences that could cause minor confusion.
Naming Consistency5/5
All tools follow a consistent tarn_verb_noun or tarn_noun pattern in snake_case, making the set predictable and easy to navigate.
Tool Count5/5
14 tools cover the full lifecycle of testing with Tarn without being excessive; each tool serves a clear, non-redundant role.
Completeness5/5
The tool surface includes running tests, inspecting results in multiple granularities, impact analysis, scaffolding, validation, and fix planning—leaving no obvious gaps for the domain.
Average 3.9/5 across 14 of 14 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 2 community issues answered or closed in the last 6 months
- 3 commits in the last 12 weeks
- Last stable release on June 4, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states the tool inspects archived reports and includes artifact paths in the response. However, with no annotations provided, it does not disclose whether the tool is read-only, requires permissions, or handles errors such as missing runs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loads the main purpose, and contains no unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description mentions that the response includes artifact paths. However, it lacks details about error handling, pagination, or the full structure of the report, which would be helpful for a tool with multiple granularity levels.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage for all four parameters. The description adds some context about 'filter_category' and 'target' granularity, but mostly repeats what the schema already provides, so it adds marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool inspects a prior run's archived report at multiple granularities (run, file, test, step). It mentions the optional filter_category and response contents, but does not explicitly differentiate from sibling tools like 'tarn_report' or 'tarn_last_failures'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for inspecting archived reports at different levels, but provides no explicit guidance on when to use this tool versus alternatives, nor any conditions to avoid using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description indicates read-only behavior (no execution) but lacks details on side effects, output format, or error handling. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the main action. No wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, output schema, or complex parameters, the description is adequate but lacks details on return values, error messages, or examples. Could be more complete for an agent unfamiliar with the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The tool description adds no extra meaning beyond what the schema already provides. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool validates .tarn.yaml files without executing, checking syntax and schema. It distinguishes from siblings like tarn_run by specifying no execution, but does not elaborate on the exact schema validation scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: validate before running tests. But no explicit guidance on when to use this vs alternatives like tarn_run or tarn_impact. No when-not-to-use or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it states what the tool does, it does not discuss side effects (e.g., whether it triggers test execution, writes files), permissions, or read-only nature. This is insufficient for a tool that likely performs write operations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, both front-loaded with the core action and followed by valuable context about the response shape. No unnecessary words, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and nested objects, the description is relatively brief. It explains the core purpose and return shape but does not detail how 'failing pairs' are determined, error cases, or prerequisites (e.g., a prior run must exist). Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100%, so the parameters are well documented in the schema. The description adds some context about the return shape but does not add meaning beyond what the schema provides for the parameters themselves. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool reruns only failing (file, test) pairs from a prior run, using the verb 'rerun' and specifying the resource. It distinguishes from siblings like tarn_run (which runs all tests) and tarn_run_agent (different purpose).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context by mentioning that the response shape matches tarn_run, enabling a loop of run → inspect → rerun without switching tool surfaces. However, it lacks explicit when-not or alternative tool guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description effectively discloses the key behavioral trait: the tool is read-only and does not load artifact payloads. This gives the agent a clear understanding of the tool's lightweight, non-destructive nature. Additional details about error handling or required privileges are omitted, but the core behavior is well communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short sentences with no redundant information. The first sentence states the primary function, and the second clarifies a key behavioral constraint. This is highly efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list-style tool with two optional parameters and no output schema, the description adequately covers what the tool returns and its scope. It could be improved by briefly noting the format of the returned data, but given the tool's simplicity, the current description is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes both parameters (cwd and run_id) with detailed documentation including defaults and allowed formats. The tool description adds no further information about parameters beyond what is already in the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Return' and the resource 'artifact paths plus existence flags for a specific run'. It also clarifies what it does not do ('Does not load any artifact payload'), which helps distinguish it from potential sibling tools that might load payloads. However, it does not explicitly differentiate from siblings by name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by stating it only returns paths and existence flags and does not load payloads. This suggests using it when only metadata is needed. However, it lacks explicit guidance on when not to use it or direct references to alternative tools for loading payloads.
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 must disclose behavioral traits. It does so by stating that artifacts are written to `.tarn/runs/<run_id>/` and that the tool returns a compact agent report plus paths to avoid large JSON blobs. It could mention if it is destructive or requires authentication, but the disclosed side effects and return format are valuable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, with the first sentence stating the primary action and the second providing key behavioral information. No superfluous text; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, no output schema, no annotations), the description covers purpose, side effects, and return format reasonably well. It could elaborate on the structure of the 'compact agent report' or when to use different report modes, but it is sufficiently complete for most agents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents each parameter well. The description adds context about the compact report and artifact paths but does not add new meaning beyond what the schema provides for individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Run API tests defined in .tarn.yaml files.' It specifies the action (run), resource (API tests), and distinguishes itself from siblings like tarn_fix_plan or tarn_rerun_failed by mentioning artifact handling and compact reports.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus siblings (e.g., tarn_run_agent, tarn_rerun_failed). The description implies it's for standard test runs that produce artifacts, but lacks when-not-to-use or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only describes the function (runs suite, returns report) without disclosing side effects, permissions, or state changes. Minimal behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus an equivalence line, all front-loaded with the core action and usage guidance. No unnecessary words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, nested objects, and no output schema, the description adequately explains the tool's purpose and preferred use case. It mentions the AgentReport (NAZ-412) and artifact paths, though could be more detailed on return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 9 parameters have descriptions in the input schema (100% coverage). The description adds no additional parameter-level information beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Run', the resource 'suite with report_mode=agent pre-selected', and distinguishes from tarn_run via agent report and failure iteration focus. It also provides the CLI equivalent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it is the preferred entry point when the caller will iterate on failures, giving clear context. Implicitly differentiates from tarn_run via the equivalence statement, though no explicit when-not guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It mentions the tool analyzes and returns a plan, but doesn't state whether it has side effects (e.g., creates files, modifies state) or if it is read-only. The name suggests planning, but confirmation is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core purpose, the second explains the two input modes. No extraneous words or repetition. Every sentence adds essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 7 parameters (including nested objects), the description is fairly complete about inputs but omits details about the output format (e.g., structure of the plan) and any prerequisites. It covers the two modes well but could describe what the plan contains for an agent to process the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter. The description adds significant value by clarifying the two invocation modes: either supplying a `report` or the same inputs as tarn_run (path, env, tag, vars). This contextual information is not captured in the individual parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool analyzes a Tarn JSON report to produce a prioritized fix plan with next actions, evidence, and remediation hints. It distinguishes from siblings like tarn_run (which runs tests but doesn't plan) by explicitly mentioning both modes: accepting a report or running tarn first.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the two usage modes—passing a report object or the same inputs as tarn_run—which helps an agent decide how to invoke it. However, it lacks explicit guidance on when not to use it or comparison to alternatives like tarn_run_agent.
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 full burden. It discloses support for truncation budgets and the general assemble action. However, it does not mention side effects (e.g., no modifications), auth needs, or failure modes when artifacts are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first front-loads the core purpose and contents, second adds a feature and equivalent command. No unnecessary words, efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the what and high-level how, but lacking details on output shape (no output schema), prerequisites (must have prior run artifacts), and parameter interaction. With 7 parameters and no annotations, more context on error handling or typical usage would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning beyond parameter names by contextualizing 'failing entries' (failed param), 'truncation budgets' (max_chars), and 'prior run' (run_id). This helps an agent understand what the parameters influence.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'assemble a remediation bundle (NAZ-414) from a prior run's artifacts', specifying the verb (assemble), resource (remediation bundle), and provenance (prior run). It lists contents (failing entries, YAML snippets, etc.) and differentiates from siblings like tarn_run or tarn_inspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage for creating a bundle from prior run artifacts, and mentions truncation budgets for context-limited agents. But no explicit guidance on when to use this tool versus alternatives like tarn_get_run_artifacts or tarn_report, and no when-not-to-use conditions.
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 present, so the description bears full responsibility. It claims to be the 'fastest failures-first read' but does not disclose any side effects, authentication needs, rate limits, or error conditions. For a tool with no annotations, more behavioral detail is expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: purpose, use case, and equivalence. No filler, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only 2 parameters, no output schema, and no annotations, the description covers the core purpose and usage well. It lacks explicit output format details, which would be helpful since no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers both parameters (cwd, run_id) with descriptions, achieving 100% coverage. The tool description adds no additional parameter-specific meaning beyond what the schema already provides, so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Explicitly states it returns root-cause failure groups (NAZ-402), contrasting with the wider failures envelope. Includes a specific verb ('Return') and resource, and distinguishes from sibling 'tarn_last_failures' by mentioning it is the fastest failures-first read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context for use ('agent planning a fix') and gives an equivalent CLI command. However, it does not explicitly state when not to use it or directly contrast with alternatives like tarn_last_failures.
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 for behavioral disclosure. It partially fulfills this by stating it returns file names, test names, and step counts, implying a read-only operation. However, it does not explicitly confirm non-destructive behavior or mention any potential side effects, authentication needs, or performance impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, with the purpose stated first and the return value immediately following. Every word adds value, and there is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of a listing tool and the absence of an output schema, the description adequately covers the purpose and return format. It could be enhanced by noting that only tests in .tarn.yaml files are listed, which is already clear, but no significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the two parameters (cwd and path) with clear descriptions. The tool description adds no additional parameter meaning beyond what the schema already provides, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'list', the resource 'tests', and the source '.tarn.yaml files'. It immediately distinguishes from sibling tools like tarn_run (execution) and tarn_inspect (detailed view) by specifying the output: file names, test names, and step counts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need to enumerate available tests, providing a clear context. However, it does not explicitly exclude when not to use it (e.g., when a filtered search is needed) nor compare to alternative siblings directly.
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 full burden. It discloses core behavior (generating skeleton, returning metadata, optional file write) but omits details about side effects, permissions, or safety considerations. The `force` and `out` overwrite behavior is described in the schema but not reiterated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—three sentences covering all key aspects without redundancy. It prioritizes the main action, input modes, output, and optional file writing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and the tool's complexity (10 params, nested objects), the description provides a good overview of inputs and outputs (YAML + structured metadata). However, it could be more explicit about the exact return format or fields.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by summarizing input modes and providing an equivalent CLI command, but does not deepen understanding beyond what the schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: generating a minimal `.tarn.yaml` skeleton from four distinct input modes. It specifies the output (rendered YAML plus structured metadata) and optional file writing, distinguishing it from other tools on the server.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly guides when to use the tool by enumerating the four input modes (OpenAPI, curl, explicit, recorded). However, it does not explicitly state when not to use it or mention alternatives, leaving some ambiguity for the agent.
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. It discloses read-only behavior (no HTTP, no test execution) and output characteristics (confidence tiers, run hints). While it lacks details on error handling or edge cases, it adequately describes the core 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences. The first sentence front-loads the purpose and key features, and the second adds essential clarifications (read-only, CLI equivalence). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks an explicit output schema and only vaguely mentions output (confidence tiers, run hints). It does not cover error behavior or edge cases, leaving some gaps for an agent to guess the return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds limited value beyond what the schema already provides. It does not elaborate on parameter usage beyond the schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool maps a change to the tests it likely affects, with confidence tiers and run hints. It distinguishes itself from sibling tools like tarn_run and tarn_run_agent by noting it is read-only and does not execute tests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for impact analysis without running tests, and mentions the CLI equivalent. However, it does not explicitly state when not to use it or provide direct comparisons to sibling tools for guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it reads a persisted file rather than re-running tests, implying non-destructive behavior and efficiency. No annotations provided, so description carries the burden well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no wasted words. Efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, but the description specifies 'structured JSON' which is adequate for a utility tool. Could detail the JSON structure more, but context from sibling tools and schema covers essential needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline score is 3. Description does not add additional parameter details beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it returns grouped failures for a specific run as structured JSON, distinguishing itself from sibling tools like tarn_report by noting it provides a failures-only view without loading the full report.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage context: 'Useful for agents that want a failures-only view without loading the full report.' Does not explicitly list alternatives or when not to use, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides good behavioral transparency: it is read-only (purely reads files), no side effects, and no network calls. This suffices for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with purpose and essential details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description appropriately describes the output format and input defaults. It covers all key aspects for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by stating defaults (cwd defaults to workspace root, run_id defaults to 'last'), going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it renders a concise report for a persisted run, specifying the input files and output format. It distinguishes from siblings like tarn_run by noting no HTTP or test execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use (after a persisted run) and what not to expect (no HTTP, no test execution), effectively guiding usage without naming alternatives explicitly.
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:

[![tarn MCP server](https://glama.ai/mcp/servers/NazarKalytiuk/tarn/badges/card.svg)](https://glama.ai/mcp/servers/NazarKalytiuk/tarn)

Score Badge

Copy to your README.md:

[![tarn MCP server](https://glama.ai/mcp/servers/NazarKalytiuk/tarn/badges/score.svg)](https://glama.ai/mcp/servers/NazarKalytiuk/tarn)

Latest Blog Posts

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

MCP directory API

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

curl -X GET 'https://glama.ai/api/mcp/v1/servers/NazarKalytiuk/tarn'

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