Skip to main content
Glama

Fairquery Agent Trust & Data Safety

by com.getfairquery
OverviewDiscussionsAdmin

Audit dependencies/manifests with fix recommendations (paid)

osv_audit_dependencies
Read-onlyIdempotent

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.50 per 1,000 packages + $1.50 per 1,000 vulnerabilities found (+ $0.05 per 1,000 runs). 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: Called from this Fairquery-hosted Worker, which forwards your input and Apify token to Apify and waits 20 s (APIFY_TIMEOUT if the run has not finished). This Worker's code is designed not to store them. The Actor in your account queries OSV.dev. 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. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations only cover the safety profile (readOnly, idempotent, non-destructive); the description adds substantial context beyond that: per-package/per-vulnerability pricing billed to the caller's Apify account, a 20 s timeout with APIFY_TIMEOUT as the failure mode, a concrete cost example, an enumerated error-code list (APIFY_PAYMENT_REQUIRED, APIFY_TOKEN_MISSING, etc.), and input size ceilings. The privacy note about token forwarding is hedged ('designed not to store') but is volunteered rather than omitted.

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

Conciseness5/5

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

Labeled sections (WHAT/WHEN/WHEN NOT/COST/RETURNS/BEHAVIOR/PARAMETERS/EXAMPLE) front-load purpose and routing before cost and mechanics. Dense but every block carries information an agent needs for a paid, third-party-hosted call; nothing is filler.

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 7-parameter, paid, open-world tool with an output schema, the definition covers invocation requirements (token), cost model, failure modes, size limits and paging. The RETURNS block duplicates the output schema but the duplication is harmless and the rest leaves no ambiguity about how to call it correctly.

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 already 100%, so the description's parameter block is largely restatement; however it does add decision-relevant meaning, notably that minSeverity also suppresses vulnerability rows for billing purposes and that limit/offset drive paging (offset maps to nextOffset). It doesn't document the packages-vs-manifestText precedence beyond 'one required', which the schema already handles.

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 concrete verb and resource (parses manifests, checks OSV, returns per-package max severity/CVSS and fixed versions) and enumerates the exact manifest formats handled. It also names the sibling tools it is not (osv_query_packages, osv_get_vulnerability), so an agent can route without opening either 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 and WHEN NOT sections: use this for full project audits / CI-style reports, use osv_query_packages for a few exact versions, osv_get_vulnerability for one advisory. The cost trade-off is stated as the deciding factor, which is exactly what an agent needs to choose between a paid and free sibling.

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

All Fairquery Agent Trust & Data Safety toolsInspect
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