Skip to main content
Glama
Sign In
fairquery-agent-trust-mcp

fairquery-agent-trust-mcp

Official
by fairquery
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Get vulnerability advisory details (free, OSV.dev)

osv_get_vulnerability
Read-onlyIdempotent

Fetch full OSV vulnerability records by advisory ID to get summaries, severity, affected ranges, and fixed versions.

Instructions

WHAT: Fetch full OSV records (summary, details, aliases, severity vectors, affected ranges, fixed versions, references) for advisory IDs directly from api.osv.dev. WHEN: You have IDs (from osv_query_packages or a report) and need details or the fixed version. WHEN NOT: To find which vulns affect a package version (osv_query_packages, free) or a whole manifest (osv_audit_dependencies, paid). COST: Free; no token. RETURNS: Paged "vulnerability" rows with the raw OSV record fields, or "error" rows (VULN_NOT_FOUND | OSV_FETCH_FAILED, see PARAMETERS). BEHAVIOR: One HTTPS call per ID to api.osv.dev, in parallel; typically <2 s, 20 s timeout each. Max 25 IDs per call. PARAMETERS: ids: each ID is fetched separately (in parallel) and yields exactly one row in input order, so one bad ID never fails the others: an unknown ID returns a VULN_NOT_FOUND row (not retryable), a network/5xx problem an OSV_FETCH_FAILED row (retryable - retry just that ID). Prefer the ecosystem/GHSA IDs returned by osv_query_packages (vuln_ids); a CVE-... ID only resolves when OSV indexes that CVE as its own record, otherwise look up the GHSA alias. IDs are matched as given (no trimming of URLs or prefixes), and duplicates are fetched twice. limit/offset only page the returned rows; every call re-fetches all given IDs, so for a next page resend the same ids with offset = nextOffset. EXAMPLE: {"ids":["GHSA-35jh-r3h4-6jhm"]} -> lodash command injection, fixed in 4.17.21.

Input Schema

NameRequiredDescriptionDefault
idsYesRequired. 1-25 OSV advisory IDs, 3-100 chars each, pattern ^[A-Za-z0-9][A-Za-z0-9._:-]{2,99}$ (letters, digits, . _ : -). Formats: GHSA-xxxx-xxxx-xxxx, PYSEC-YYYY-N, GO-YYYY-NNNN, RUSTSEC-YYYY-NNNN, CVE-YYYY-NNNNN. Example: ["GHSA-35jh-r3h4-6jhm","PYSEC-2021-9","GO-2022-0969"]
limitNoOptional page size: items to return, integer 1-25 (default 25). Example: 25
offsetNoOptional zero-based number of items to skip, integer 0-1000000 (default 0); pass nextOffset from the previous response, e.g. 100

Output Schema

NameRequiredDescriptionDefault
metaNoTool-specific context (summary counts, cost notes, ...)
countYesNumber of items in this page
itemsYesResult rows for this page
totalYesTotal items before paging
offsetYesOffset of the first item in this page
hasMoreYesTrue if more items exist after this page
nextOffsetYesOffset to pass for the next page, or null

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / ids / description
      Previous value: -"Required. 1-25 IDs (3-100 chars, letters/digits/.-_:), e.g. [\"GHSA-35jh-r3h4-6jhm\",\"PYSEC-2021-9\",\"GO-2022-0969\"]"New value: +"Required. 1-25 OSV advisory IDs, 3-100 chars each, pattern ^[A-Za-z0-9][A-Za-z0-9._:-]{2,99}$ (letters, digits, . _ : -). Formats: GHSA-xxxx-xxxx-xxxx, PYSEC-YYYY-N, GO-YYYY-NNNN, RUSTSEC-YYYY-NNNN, CVE-YYYY-NNNNN. Example: [\"GHSA-35jh-r3h4-6jhm\",\"PYSEC-2021-9\",\"GO-2022-0969\"]"
    • changedInput schema / properties / limit / description
      Previous value: -"Page size: items to return, integer 1-25 (default 25)"New value: +"Optional page size: items to return, integer 1-25 (default 25). Example: 25"
    • changedInput schema / properties / offset / description
      Previous value: -"Items to skip for paging, integer >= 0 (default 0); pass nextOffset from the previous response"New value: +"Optional zero-based number of items to skip, integer 0-1000000 (default 0); pass nextOffset from the previous response, e.g. 100"
  2. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations cover read-only/idempotent/open-world/destructive, but the description goes well beyond them: one parallel HTTPS call per ID, <2s typical and 20s timeout, 25-ID cap, two distinct error classes with different retryability (VULN_NOT_FOUND non-retryable vs OSV_FETCH_FAILED retryable per-ID), and the fact that pagination re-fetches every ID.

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?

Labelled sections (WHAT/WHEN/WHEN NOT/COST/RETURNS/BEHAVIOR/PARAMETERS/EXAMPLE) make a long description scannable and front-loaded. It is slightly verbose, with minor repetition (the free/no-token cost is stated in the title, COST line and WHEN NOT).

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

Completeness5/5

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

For a 3-param, single-resource fetch tool with rich annotations and an output schema, the description covers everything an agent needs: scope, cost, timing, error taxonomy, ID format guidance, and pagination mechanics. No material gap remains.

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

Parameters5/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds real semantics: IDs are fetched individually and yield one row in input order, matching is literal with no URL/prefix trimming, duplicates are fetched twice, ecosystem/GHSA IDs are preferred over CVE IDs, and next-page calls must resend the same ids with offset=nextOffset.

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 WHAT line names a specific verb (Fetch) and resource (full OSV records for advisory IDs from api.osv.dev), and even enumerates the fields returned. It explicitly distinguishes itself from osv_query_packages and osv_audit_dependencies, so an agent can route without opening any schema.

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?

WHEN states the precondition ('you have IDs... and need details or the fixed version') and WHEN NOT names both alternatives with their selection condition (query by package version vs whole manifest) plus their cost model. Nothing is left to inference.

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

Deploy Server

Other Tools