Skip to main content
Glama
drewrukin

dtrack-mcp

by drewrukin

carry_over_triage

Transfer triage decisions from a source project version to a target project version. Use dry-run mode to preview changes before applying, with configurable overwrite rules and safety caps.

Instructions

⚠ WRITE (when mode="exact"). Transfer triage decisions v1 → v2.

ALWAYS run with mode="dry_run" first. Only switch to mode="exact" after a human has reviewed the plan. In exact mode each transfer issues PUT /api/v1/analysis and appends a comment noting the source project and match reason. The full history of source comments is preserved in the original project untouched.

Skip rules:

  • source has no actionable analysis (state NOT_SET) → skipped

  • target already triaged (state ≠ NOT_SET) and overwrite_any=False → skipped

  • target NOT_SET and overwrite_not_set=False → skipped

Safety caps:

  • max_operations (default 500) early-fails in exact mode when the plan is larger than the cap. Raise explicitly for huge transfers, or split into batches.

  • DTRACK_WRITE_DELAY_MS env var adds a per-write sleep for rate-limit-sensitive instances.

Args: source_project_uuid: Old version UUID with existing triage. target_project_uuid: New version UUID to populate. mode: "dry_run" (no writes, returns plan) or "exact" (performs writes). include_updated_components: Also transfer updated_component matches (same CVE, different component version). Default False — conservative. overwrite_not_set: Transfer over target entries in state NOT_SET. Default True. overwrite_any: Transfer over target entries in any state. Default False. comment_prefix: Prepended to every carry-over comment. max_operations: Sanity cap against hallucination-driven bulk writes in exact mode. Raise if you genuinely need to transfer more.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
source_project_uuidYes
target_project_uuidYes
modeNodry_run
include_updated_componentsNo
overwrite_not_setNo
overwrite_anyNo
comment_prefixNo[dtrack-mcp]
max_operationsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description fully discloses behavior: in exact mode it issues PUT calls, appends comments, preserves source history, and includes skip rules and safety caps. Also mentions an env var for rate-limiting.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is fairly long but well-structured: a warning, usage guidelines, skip rules, safety caps, and parameter list. It's front-loaded with the dry-run instruction. A minor point is that it could be slightly more concise, but every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (8 params, write operation, safety concerns), the description covers all necessary aspects: prerequisite dry-run, skip rules, safety caps, parameter meanings. The output schema exists but doesn't need elaboration in the description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The Args section provides detailed explanations for all 8 parameters, adding meaning beyond the schema's property titles and types. For example, it explains include_updated_components as 'same CVE, different component version'.

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 'Transfer triage decisions v1 → v2', a specific verb-resource combo. It distinguishes from siblings like broadcast_triage and diff_findings by emphasizing it's a version-to-version transfer.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit instructions: 'ALWAYS run with mode="dry_run" first' and only switch to exact after human review. Also details skip rules and safety caps, leaving no ambiguity about when and how to use the tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

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/drewrukin/dtrack-mcp'

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