VulnTracker MCP

list_board_cards

Read-onlyIdempotent

The team's CVE board: the CVEs that reached this team (by tracking notification or added by hand), each with its triage status (new, acknowledged, in_progress, resolved, dismissed), resolution status, notes, severity and the vendor/product it was recorded against. Use it to answer 'what is open on our board', 'which cards mention product X', or to find the card for a CVE.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_board_cards"
  }
}

Input Schema

Name	Required	Description
`kev`	No	Only cards whose CVE is in CISA KEV
`page`	No	Page number, 1-based
`limit`	No	Max cards (default 20, max 50)
`query`	No	CVE id prefix (CVE-2026-12) or free text matched against vendor/product/vulnerability name
`status`	No	Comma-separated card statuses: new, acknowledged, in_progress, resolved, dismissed. Empty = all non-archived
`archived`	No	Show archived cards instead of the live board
`severity`	No	critical, high, medium, low (comma-separated)
`exploited`	No	Only cards whose CVE is in CISA KEV (same as kev)
`remediation`	No	Only cards with a published VulnTracker guide of this kind: fix, workaround, guidance

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 10, 2026

changedInput schema / properties / exploited / description

Previous value: -"Only cards whose CVE has known exploitation"New value: +"Only cards whose CVE is in CISA KEV (same as kev)"

First observedNov 10, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, so safety is covered. The description adds genuinely useful behavior: the board contains only CVEs that reached this team (via tracking notification or manual add), the five triage statuses, and the implicit rule that archived cards sit outside the live board. It stops short of describing result ordering or pagination semantics, but that is minor given the schema's page/limit docs.

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

Conciseness4/5

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

Two sentences, front-loaded with the resource definition and followed by concrete usage queries; almost nothing is wasted. The field enumeration is slightly dense ('triage status ... resolution status') but each item earns its place by describing the return payload, which has no output schema.

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

Completeness4/5

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

With 9 optional parameters, no output schema, and a read-only annotation profile, the description does the necessary work by explaining what a card is and what fields it exposes. The only real gap is around the overlapping kev/exploited and query/CVE-prefix semantics, which an agent must resolve from the schema alone.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3 and the schema already carries filter meaning for kev, query, status, severity, archived, and remediation. The description adds no filter-specific nuance; notably it does not clarify the duplicated kev/exploited parameters ('same as kev') or how query free-text interacts with the CVE-prefix mode.

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 names a concrete resource (the team's CVE board) and enumerates what each card carries — triage status, resolution status, notes, severity, vendor/product — so an agent knows exactly what listing returns. It doesn't explicitly contrast itself with siblings like list_trackings or search_cves, but the 'board' concept distinguishes it well enough.

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

Usage Guidelines4/5

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

It supplies three concrete use cases in quoted form ('what is open on our board', 'which cards mention product X', 'find the card for a CVE'), which is strong when-to-use guidance. It gives no when-not guidance and does not name an alternative tool for the adjacent CVE-search scenarios, leaving that inference to the agent.

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

All VulnTracker MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?