Skip to main content
Glama
Sign In
Hiper-AI

Pinright

Official
by Hiper-AI
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Documentation for the version you will use (security-checked)

get-docs

Returns documentation sections that answer a question for a package at a specified version, including a security notice and safe-version docs when the release has known advisories.

Instructions

Returns the documentation sections that answer your question, taken from the package at a specific version (its published files and its repo at the release tag) and the project site. Without a version it documents the newest version with no known advisories. With a vulnerable version it starts with a SECURITY NOTICE and documents the safe version on the same release line, so the code you write keeps working after the upgrade.

Input Schema

NameRequiredDescriptionDefault
nameNoPackage name with ecosystem, as check-package takes them, instead of libraryId.
queryNoThe question or task, e.g. "protect routes with middleware". Without it: setup and main API.
tokensNoApproximate size of the answer in tokens (default 2500; raise it only when the answer was cut short).
versionNoVersion the project uses or pins, if any. Overrides the one in libraryId.
ecosystemNoRegistry, when the id does not say it or says the wrong one; overrides the id.
libraryIdNoId from find-library, e.g. "npm:next" or "npm:next@15.1.0". A GitHub repo ("/vercel/next.js") also works. Or pass name and ecosystem instead.
packageNameNoRegistry package name, when it differs from the id; overrides the id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the security-notice prefix, the fallback to the safe version on the same release line, and the sources consulted. It omits failure behavior (unknown package, no matching sections) and any rate or auth constraints, keeping it below 5.

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?

Three sentences, front-loaded with what is returned and immediately followed by the version-dependent behavior. Every clause carries distinct information with no repetition of schema or title text.

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?

Seven optional parameters with full schema descriptions and no output schema; the description supplies the one thing the schema cannot, namely the version-resolution and security behavior. An agent has enough to call this correctly without further explanation.

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 for the version parameter: absence means newest advisory-free version, and a vulnerable version triggers a security notice plus safe-version docs. That clarifies semantics beyond the schema's terse 'Version the project uses or pins'.

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 ('Returns the documentation sections that answer your question') plus the exact source basis (published files, repo at release tag, project site). This clearly separates it from check-package, find-library, and upgrade-guide, which do not return documentation content.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description establishes the context of use (you have a question about a package's API) and conditional behavior for missing or vulnerable versions, but never states when to prefer this over siblings like upgrade-guide or to call find-library first. Usage routing is implied rather than explicit.

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

Deploy Server

Other Tools