Skip to main content
Glama

Presend MCP Server

by io.github.presendapp
OverviewDiscussionsAdmin

supply_chain_check

Read-onlyIdempotent

Call this before installing or adding a package (npm install, pip install, a new entry in a manifest), especially one whose name you recalled or that a model suggested. One-call risk check: combines vulnerability_check (OSV.dev), typosquat_check, maintainer_change_check (npm only) and repo_health_check (when the GitHub repo can be resolved) into one overall verdict. A package that does not exist on npm or PyPI gets overall_risk 'package_not_found': the name may be invented, do not install it. A package first published less than 30 days ago gets the 'new_package' flag and overall_risk 'review_recommended': new packages are where invented and look-alike names get registered, so confirm the name against the project's own documentation before installing (on PyPI the age is that of the oldest release still published; being new does not make a package malicious). Use the individual tools to investigate one signal. Vulnerabilities are checked for the given version, or the latest published one (version_checked, version_source). If a check could not run (rate limit, upstream error), it is listed in unavailable_checks and overall_risk is 'incomplete', never 'no_signals_found'.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
packageYesPackage name to check.
versionNoExact version to check for known vulnerabilities. Optional: defaults to the latest published version (npm and PyPI).
ecosystemYesPackage ecosystem, e.g. npm. maintainer-change-check only runs for npm.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / version
      Added value: +{
+  "description": "Exact version to check for known vulnerabilities. Optional: defaults to the latest published version (npm and PyPI).",
+  "type": "string"
+}
  2. Added

TDQS

A4.6/5.0
Behavior4/5

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

With readOnlyHint/idempotentHint already covering the safety profile, the description still adds substantial behavior: it enumerates the possible overall_risk outcomes (package_not_found, review_recommended, incomplete, no_signals_found), the 30-day new_package threshold, the PyPI oldest-release nuance, and version_checked/version_source semantics for when a check could not run. It leaks some of its own vocabulary, but the agent gains a clear picture of failure modes and verdicts.

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?

Well front-loaded: the call-to-action ('call this before installing...') opens the description. The prose is dense with load-bearing detail rather than filler, though the parenthetical on PyPI age and the 'being new does not make it malicious' caveat stretch the length beyond the essential triggers.

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?

There is no output schema, yet the description documents the return contract in enough detail for an agent to act on it: what package_not_found implies (do not install), what new_package/review_recommended mean, and how a partial run surfaces as incomplete. Nothing needed to call or interpret the tool correctly 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, but the description adds real meaning beyond the schema by explaining how version is resolved (version_checked, version_source, latest fallback) and that maintainer_change_check only runs for npm. That is more than the schema's bare field descriptions offer.

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 ('risk check') and resource (package supply chain) and explicitly defines itself as an aggregate of four named sibling tools (vulnerability_check, typosquat_check, maintainer_change_check, repo_health_check). An agent can distinguish it from the individual signal tools 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?

States the trigger condition precisely ('before installing or adding a package... especially one whose name you recalled or that a model suggested') and names the alternative path ('Use the individual tools to investigate one signal'). It routes the agent between aggregate and per-signal usage without inference.

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

All Presend MCP Server 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