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

fairquery-agent-trust-mcp

Official

Audit dependencies/manifests with fix recommendations (paid)

osv_audit_dependencies
Read-onlyIdempotent

Audit dependency manifests or package lists against OSV to identify vulnerabilities, with per-package severity, fixed versions, and recommended upgrades.

Instructions

WHAT: Runs the Fairquery Apify Actor osv-dependency-vulnerability-check: parses package.json, package-lock.json (v1-v3), requirements.txt or go.mod (or a package list), checks OSV, and returns per-package max severity/CVSS, fixed versions, a recommended upgrade version and one row per vulnerability (deduped aliases). WHEN: Only for manifests, severity filtering or fix recommendations: full project audits from a pasted manifest, CI-style reports; for a few exact versions use osv_query_packages (free). WHEN NOT: Quick checks of a few exact versions (osv_query_packages, free) or one advisory (osv_get_vulnerability, free). COST: Paid, billed to YOUR Apify account via your APIFY_TOKEN: $0.0005 per package + $0.0015 per vulnerability found (+ $0.00005/run). Use minSeverity="HIGH" to cut vuln rows. lodash+django (2 pkgs, 41 vulns) ~ $0.06. RETURNS: Paged rows type="package" (vulnerable, vuln_count, max_severity, fixed_versions, recommended_version), type="vulnerability" (id, cve_ids, severity, cvss_score, fixed_versions, osv_url) or type="error". Tool errors: INPUT_EMPTY, APIFY_TOKEN_MISSING, APIFY_TOKEN_INVALID, APIFY_PAYMENT_REQUIRED, APIFY_ACTOR_RUN_FAILED, APIFY_TIMEOUT. BEHAVIOR: Makes network calls: runs an Apify Actor (querying OSV.dev) in your account; latency seconds to minutes (300 s timeout). Up to 1000 packages or a 2,000,000-char manifest. PARAMETERS: packages or manifestText = input (one required); manifestType = format, default auto-detect; minSeverity = only report at/above ALL|LOW|MEDIUM|HIGH|CRITICAL (default ALL); includeDevDependencies (default true); limit = page size (default 100, max 1000); offset = items to skip for paging (default 0). EXAMPLE: {"manifestText":"django==3.2.0\nrequests==2.19.0","minSeverity":"HIGH"}

Input Schema

NameRequiredDescriptionDefault
limitNoOptional page size: items to return, integer 1-1000 (default 100). Example: 50
offsetNoOptional zero-based number of items to skip, integer 0-1000000 (default 0); pass nextOffset from the previous response, e.g. 100
packagesNoOptional if manifestText is given (at least one is required). 0-1000 {ecosystem, name, version} objects with exact versions; billed per package. Example: [{"ecosystem":"npm","name":"lodash","version":"4.17.20"}]
minSeverityNoOptional, one of "ALL" | "LOW" | "MEDIUM" | "HIGH" | "CRITICAL", default "ALL". Only emit (and bill) vulnerability rows at or above this severity; package rows are always emitted. Example: "HIGH"ALL
manifestTextNoOptional if packages is given. Raw file content (<= 2,000,000 chars) of package.json, package-lock.json (v1-v3), requirements.txt (== pins) or go.mod; parsed packages are added to packages. Example: "django==3.2.0\nrequests==2.19.0"
manifestTypeNoOptional, one of "auto" | "package.json" | "package-lock.json" | "requirements.txt" | "go.mod", default "auto" (detect from content). Set it when detection fails (MANIFEST_UNDETECTED)auto
includeDevDependenciesNoOptional boolean, default true. false skips devDependencies (package.json) and dev packages (package-lock.json); no effect on requirements.txt / go.mod

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. Changed10 schema fields changed
    • changedInput schema / properties / includeDevDependencies / description
      Previous value: -"Include dev dependencies (default true)"New value: +"Optional boolean, default true. false skips devDependencies (package.json) and dev packages (package-lock.json); no effect on requirements.txt / go.mod"
    • changedInput schema / properties / limit / description
      Previous value: -"Page size: items to return, integer 1-1000 (default 100)"New value: +"Optional page size: items to return, integer 1-1000 (default 100). Example: 50"
    • changedInput schema / properties / manifestText / description
      Previous value: -"Raw package.json / package-lock.json / requirements.txt / go.mod content (<= 2,000,000 chars)"New value: +"Optional if packages is given. Raw file content (<= 2,000,000 chars) of package.json, package-lock.json (v1-v3), requirements.txt (== pins) or go.mod; parsed packages are added to packages. Example: \"django==3.2.0\\nrequests==2.19.0\""
    • changedInput schema / properties / manifestType / description
      Previous value: -"Manifest format (default auto-detect)"New value: +"Optional, one of \"auto\" | \"package.json\" | \"package-lock.json\" | \"requirements.txt\" | \"go.mod\", default \"auto\" (detect from content). Set it when detection fails (MANIFEST_UNDETECTED)"
    • changedInput schema / properties / minSeverity / description
      Previous value: -"Only emit vulns at/above this severity (default ALL)"New value: +"Optional, one of \"ALL\" | \"LOW\" | \"MEDIUM\" | \"HIGH\" | \"CRITICAL\", default \"ALL\". Only emit (and bill) vulnerability rows at or above this severity; package rows are always emitted. Example: \"HIGH\""
    • 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"
    • changedInput schema / properties / packages / description
      Previous value: -"Up to 1000 exact versions. Optional if manifestText given"New value: +"Optional if manifestText is given (at least one is required). 0-1000 {ecosystem, name, version} objects with exact versions; billed per package. Example: [{\"ecosystem\":\"npm\",\"name\":\"lodash\",\"version\":\"4.17.20\"}]"
    • changedInput schema / properties / packages / items / properties / ecosystem / description
      Previous value: -"npm, PyPI, Go, Maven, crates.io, RubyGems, NuGet, Packagist, Pub, Hex (aliases pip/cargo/gem accepted)"New value: +"Required, 1-40 chars, case-insensitive. One of npm, PyPI, Go, Maven, crates.io, RubyGems, NuGet, Packagist, Pub, Hex; aliases node, pip, python, golang, java, cargo, rust, gem, ruby, composer accepted. Example: \"npm\""
    • changedInput schema / properties / packages / items / properties / name / description
      Previous value: -"Package name, e.g. \"lodash\", \"django\", \"org.apache.logging.log4j:log4j-core\""New value: +"Required, 1-300 chars. Package name exactly as published: npm \"lodash\" or \"@scope/pkg\", PyPI \"django\", Go module path \"github.com/gin-gonic/gin\", Maven \"groupId:artifactId\" e.g. \"org.apache.logging.log4j:log4j-core\""
    • changedInput schema / properties / packages / items / properties / version / description
      Previous value: -"Exact version, e.g. \"4.17.20\" (no ranges)"New value: +"Required, 1-100 chars. One exact version without range operators or \"v\" prefix, e.g. \"4.17.20\" (not \"^4.17.0\"); Go uses \"v1.9.0\""
  2. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare readOnly/idempotent/openWorld, and the description adds substantial context beyond them: full pricing model ($0.0005/pkg + $0.0015/vuln + $0.00005/run) billed to the caller's Apify account, network calls to an Apify Actor, seconds-to-minutes latency with a 300s timeout, input caps (1000 packages / 2M chars), and an enumerated error-code list. This is exactly the extra burden a cost-incurring tool requires.

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?

Heavily structured with WHAT/WHEN/WHEN NOT/COST/RETURNS/BEHAVIOR/PARAMETERS/EXAMPLE labels and the key purpose front-loaded. It is long, but for a paid multi-mode tool nearly every line carries decision-relevant information; minor trimming is possible but nothing is wasted.

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?

An output schema exists, yet the description still summarizes the row types and error codes, covers cost, latency, and limits, and clarifies mode selection. Nothing an agent needs to invoke this correctly and safely is missing.

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 the baseline is 3. The description nonetheless adds billing-relevant semantics not obvious from the schema (e.g. 'Use minSeverity=HIGH to cut vuln rows' and that only matching rows are billed), plus a worked EXAMPLE and the packages-or-manifestText mutual-requirement.

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 ('parses package.json/requirements.txt/go.mod... checks OSV... returns per-package max severity/CVSS, fixed versions, recommended upgrade'), and explicitly distinguishes the manifest-based audit from the single/lookup siblings. An agent can tell exactly what this does versus osv_query_packages.

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?

Has explicit WHEN ('full project audits from a pasted manifest, CI-style reports') and WHEN NOT ('quick checks of a few exact versions or one advisory') sections, each naming the specific free alternative (osv_query_packages, osv_get_vulnerability). Routing is unambiguous.

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