Skip to main content
Glama

Fairquery Agent Trust & Data Safety

Pre-check an MCP server (free scan on this Worker)

mcp_server_precheck
Read-onlyIdempotent

WHAT: Pre-install check for one MCP server. Scans tool names, descriptions and parameter text you pass for injection phrasing, concealed characters, hidden markup and cross-server shadowing. WHEN: Before installing or enabling an MCP server, once you have a tools/list result to pass as tools or toolsListJson. WHEN NOT: For a dependency audit with no tool list, call osv_audit_dependencies. For a few exact versions, call osv_query_packages. This tool does not install, start or execute the package. COST: The scan is free and runs on this Fairquery-hosted Worker (Cloudflare), not on the caller's machine; tool names and descriptions you send leave the client. This Worker's code is designed not to store them and does not forward them to Apify. path and packageName are refused (PATH_NOT_ALLOWED) because this Worker has no disk, so auditDependencies=true cannot read a manifest and does not start the OSV Actor. To audit a manifest, call osv_audit_dependencies (paid: $0.50 per 1,000 packages + $1.50 per 1,000 vulnerabilities found). RETURNS: Paged "finding" rows (rule, severity, tool, field, evidence). If auditDependencies is true, one "dependency_audit" row with status no_manifest on this Worker (no disk). meta.risk_level is none, low, medium, high, critical or not_assessed. meta.shared_externally.tool_names_and_descriptions is always false, which means the scan does not forward that text to npm or Apify; the text is still received by this Worker. Errors: INPUT_EMPTY, INVALID_JSON, INVALID_PACKAGE_NAME, PATH_NOT_ALLOWED, INPUT_TOO_LARGE. BEHAVIOR: Default auditDependencies=false: no further network call and no process spawn. Scans only tools or toolsListJson you pass. path and packageName return PATH_NOT_ALLOWED and nothing is read. This Worker has no disk, so it does not read package.json, lockfiles, manifest.json, or server.json, and it does not follow symlinks. auditDependencies=true does not call registry.npmjs.org or the OSV Actor from this Worker, because a manifest is never loaded. PARAMETERS: Pass tools or toolsListJson (neither, and no path or packageName -> INPUT_EMPTY). tools: structured tools/list entries. toolsListJson: raw JSON of a tools/list result, an MCPB manifest or a tools array; invalid JSON -> INVALID_JSON. path and packageName always fail on this Worker (no disk): an invalid packageName is INVALID_PACKAGE_NAME, and any other path or packageName is PATH_NOT_ALLOWED. Nothing is read or downloaded. Use the npm server @fairquery/agent-trust-mcp for a path or packageName scan. Each field is scanned up to 20,000 characters and the raw total must be <= 500,000. auditDependencies defaults to false and does not start a paid run here. minSeverity and includeDevDependencies are unused on this Worker. limit/offset page the combined rows. EXAMPLE: {"tools":[{"name":"sum","description":"Add two numbers."}]} -> risk_level "none", shared_externally.tool_names_and_descriptions false. A poisoned description returns finding rows and a higher risk_level.

Input Schema

NameRequiredDescriptionDefault
pathNoRefused on this hosted Worker: any path returns PATH_NOT_ALLOWED (no disk). Pass tools or toolsListJson. Example: "/tmp/some-mcp"
limitNoOptional page size: items to return, integer 1-1000 (default 100). Example: 50
toolsNoOptional if toolsListJson, path or packageName is given. 0-400 tools, as returned by tools/list. Example: [{"name":"sum","description":"Add two numbers."}]
offsetNoOptional zero-based number of items to skip, integer 0-1000000 (default 0); pass nextOffset from the previous response, e.g. 100
minSeverityNoOptional, one of "ALL" | "LOW" | "MEDIUM" | "HIGH" | "CRITICAL", default "ALL". Forwarded to the OSV Actor only when auditDependencies is trueALL
packageNameNoRefused on this hosted Worker. An invalid npm name returns INVALID_PACKAGE_NAME; any other packageName returns PATH_NOT_ALLOWED (no disk, and the package is not downloaded). Pass tools or toolsListJson. Example: "some-mcp"
toolsListJsonNoOptional if tools, path or packageName is given. Raw JSON (<= 2,000,000 chars) of a tools/list result, {"tools":[...]}, an MCPB manifest, or a tools array. Example: "{\"tools\":[{\"name\":\"sum\",\"description\":\"Add two numbers.\"}]}"
auditDependenciesNoOptional boolean, default false. On this Worker a manifest is not read, so true does not start the OSV Actor; the audit row is no_manifest. Use osv_audit_dependencies for a pasted manifest. Example: false
includeDevDependenciesNoOptional boolean, default true. Forwarded to the OSV Actor only when auditDependencies is true; false skips devDependencies

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.8/5.0
Behavior5/5

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

Far beyond the annotations: it discloses that the scan is free, runs on a hosted Cloudflare Worker rather than the caller's machine, that tool names and descriptions leave the client, that the Worker is designed not to store or forward them to Apify, and that durable scans elsewhere are paid ($0.50/1,000 packages). It also discloses the no-disk constraint that makes path/packageName fail and that no network call or process spawn occurs at defaults — consistent with openWorldHint=true.

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?

Strongly front-loaded with WHAT/WHEN/WHEN NOT and scannable section labels, and each section earns its place. It loses a point for repetition — the 'path and packageName refused, no disk' point is restated in COST, BEHAVIOR and PARAMETERS, and the paid-pricing detail appears twice.

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?

Given 9 optional parameters, a hostile-input domain and a real output shape, the description covers preconditions, cost, data handling, error codes, return-row structure, risk_level values and paging. An output schema exists, so leaving return-value detail light is appropriate and it still summarizes the finding rows and meta fields.

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% and the schema already documents per-parameter refusals, so the baseline is 3. The description adds genuine cross-parameter semantics not in the schema: tools/toolsListJson mutual exclusion yielding INPUT_EMPTY, the 20,000-char per-field and 500,000-char total scan caps, minSeverity and includeDevDependencies being inert on this Worker, and the example payload.

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 states a specific verb and resource ('pre-install check for one MCP server') and enumerates exactly what it scans: tool names, descriptions, parameter text, for injection phrasing, concealed characters, hidden markup and cross-server shadowing. It explicitly distinguishes itself from osv_audit_dependencies and osv_query_packages, so an agent can route without opening a 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 names the precondition (before installing/enabling, once you have a tools/list result) and WHEN NOT names two concrete alternatives with their selecting conditions (dependency audit with no tool list, a few exact versions). It also states a hard boundary: it does not install, start or execute the package.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources