fairquery-agent-trust-mcp

Official

by fairquery

Overview Schema Source Related Servers Discussions Admin

TypeScript

Hybrid

Check package versions for known vulnerabilities (free, OSV.dev)

osv_query_packages

Read-onlyIdempotent

Query exact package versions against OSV.dev from your machine to identify which are vulnerable and get advisory IDs.

Instructions

WHAT: Query the public OSV.dev database (api.osv.dev querybatch) directly from your machine for exact package versions; returns which are vulnerable and the advisory IDs. WHEN: Quick "is lodash 4.17.20 vulnerable?" checks for up to 200 packages; then osv_get_vulnerability for details of specific IDs. WHEN NOT: Parsing manifests/lockfiles, severity filtering, fixed/recommended versions in one shot -> osv_audit_dependencies (paid). COST: Free. Direct HTTPS to api.osv.dev only (Google-run public API); no token, nothing sent to Fairquery or Apify. 20 s timeout. RETURNS: Paged items {type:"package",ecosystem,name,version,vulnerable,vuln_count,vuln_ids[],osv_url} or {type:"error",code:INVALID_ECOSYSTEM}; meta.vulnerable_count. Tool errors: OSV_FETCH_FAILED (retryable). EXAMPLE: {"packages":[{"ecosystem":"npm","name":"lodash","version":"4.17.20"}]} -> vulnerable true, vuln_ids ["GHSA-35jh-r3h4-6jhm",...].

Input Schema

TableJSON Schema

Name	Required	Description
`limit`	No	Page size: items to return, integer 1-200 (default 100)
`offset`	No	Items to skip for paging, integer >= 0 (default 0); pass nextOffset from the previous response
`packages`	Yes	Required. 1-200 exact package versions. Example: [{"ecosystem":"npm","name":"lodash","version":"4.17.20"}]

Output Schema

TableJSON Schema

Name	Required	Description
`meta`	No	Tool-specific context (summary counts, cost notes, ...)
`count`	Yes	Number of items in this page
`items`	Yes	Result rows for this page
`total`	Yes	Total items before paging
`offset`	Yes	Offset of the first item in this page
`hasMore`	Yes	True if more items exist after this page
`nextOffset`	Yes	Offset to pass for the next page, or null

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 17, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Goes well past the annotations (readOnly, idempotent, openWorld, non-destructive) by disclosing cost (free), network path (direct HTTPS to api.osv.dev, no token, nothing sent to Fairquery/Apify), a 20s timeout, and retryable error code OSV_FETCH_FAILED. That operational detail is exactly the kind of context annotations cannot express.

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 WHAT/WHEN/WHEN NOT/COST/RETURNS/EXAMPLE labeling is highly scannable and front-loads the purpose. The RETURNS block partially duplicates the existing output schema, which is mild redundancy, but every other line earns its place.

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?

With a rich output schema and strong annotations, the description supplies everything else an agent needs — cost, privacy posture, timeout, error semantics, and routing to alternatives. Nothing required to call it correctly is missing.

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 all three parameters are already documented in the schema, including the ecosystems list, the exact-version constraint, and the paging fields. The description's EXAMPLE merely repeats the schema's own example, adding no new parameter syntax or format detail. Baseline 3 applies when the schema does the heavy lifting.

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?

States a specific verb and resource (query the OSV.dev database for exact package versions) and names the two siblings it is not — osv_get_vulnerability for details and osv_audit_dependencies for manifest-level auditing. An agent can distinguish it from its siblings 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?

Explicit WHEN (quick 'is lodash 4.17.20 vulnerable?' checks for up to 200 packages) and WHEN NOT (manifest/lockfile parsing, severity filtering, fixed versions -> use the paid sibling), with each alternative named. 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