Skip to main content
Glama
Seidl-Family

ncrypted-mcp

by Seidl-Family
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Ask the user for a secret

ncrypted_request

Request passwords, API keys, or tokens via a single-use link so users enter them in their browser, encrypted to a local key, and the agent never sees the secret.

Instructions

When you need a password, API key or token from the user, call this instead of asking them to paste it into chat. Returns a link for the user; they paste the value on that page, where it's encrypted in their browser to a key that only exists on this machine. Give the user the link and END YOUR TURN so they can open it; once they say they've submitted it, call ncrypted_request_fulfill to deliver it (e.g. to a Vercel env var) without ever seeing it. Free.

Input Schema

NameRequiredDescriptionDefault
labelYesWhat you need and why, shown to the user, e.g. 'Stripe secret key for the billing project (Vercel production)'.
ttl_minutesNoHow long the request stays open. Default 60.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.2

TDQS

A4.4/5.0
Behavior4/5

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

Since there are no annotations, the description carries the full burden of transparency. It explicitly discloses critical security traits: the data is 'encrypted in their browser' and 'encrypted on this machine,' guaranteeing the AI never sees the secret. This is highly valuable behavioral context.

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?

The description is long, but every part serves a crucial functional or security purpose (e.g., the instructions on ending the turn). While a bit verbose, it prioritizes instruction over brevity, which is appropriate for a complex, multi-step tool.

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 the zero-annotation context, the description is exceptionally complete. It covers the entire security mechanism, the user interaction flow, and the necessary subsequent steps, leaving no practical question for the agent to ask before use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, meaning the schema already defines the parameters. The description adds no specific linguistic semantics beyond restating the purpose of the tool, thus meeting the baseline requirement for high coverage.

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 description is extremely clear and specific: it is used when 'you need a password, API key or token from the user.' It states exactly what the tool initiates: returning a secure link to collect the secret.

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?

The description provides extremely detailed, step-by-step usage instructions, including explicitly telling the agent to 'END YOUR TURN' and referencing the subsequent tool (ncrypted_request_fulfill) to complete the workflow. This eliminates ambiguity about the entire interaction flow.

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