Skip to main content
Glama
Sign In
N0moreher0

venira-mcp-coding

by N0moreher0
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Manage secrets

project_secret
DestructiveIdempotent

Store encrypted API tokens or credentials with expiry and rotation metadata, then inject them into commands without exposing plaintext; expired secrets are refused.

Instructions

Manage API tokens/credentials without leaking them: values are encrypted at rest and never returned by default. Inject them into commands with project_shell_run secret_env=["NAME"] instead of pasting them into a command line. Rotation metadata (expiry, last use, use count) is tracked by default and expired secrets are refused. Use when: storing a token (action=set), checking whether one exists or is due for rotation (action=get / action=list), removing one (action=delete). Then use secret_env on project_shell_run or the built-in GitHub tools. Avoid when: the value is a normal, non-secret config (put it in .env or the config file); or you need the plaintext printed (only with reveal=true + VENIRA_SECRET_ALLOW_REVEAL=1). Speed: fast; encrypted AES-256-GCM store, atomic writes, values decrypted only when injected. Expiry/use fields are metadata only. Output: secret_set: name, length, sha256_12, updated_at, expires_at, days_left, created, rotated; secret_get/list: metadata only (expires_at, expired, days_left, last_used_at, use_count, rotated_at); secret_delete: deleted. Batch-safe: no

Input Schema

NameRequiredDescriptionDefault
nameNoEnv-var style name, e.g. GITHUB_TOKEN (required for get/set/delete).
valueNoSecret value for action=set. Prefer value_env so it never appears in the transcript.
actionNolist
reasonNoWhy this change is made (e.g. "sua loi null pointer o dong 45"). Recorded in the audit trail so later sessions know the intent. Single line, max 400 chars, secrets are redacted.
revealNoaction=get: return the plaintext value. Requires VENIRA_SECRET_ALLOW_REVEAL=1 on the host; prefer secret_env injection.
value_envNoRead the value from this host environment variable instead of `value` (never logged).
expires_atNoaction=set: absolute expiry (epoch ms or ISO-8601), instead of expires_in_days.
expires_in_daysNoaction=set: expiry in days (e.g. 90 for quarterly rotation). Expired secrets are not injected.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.5.4

TDQS

A4.8/5.0
Behavior5/5

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

Annotations declare a destructive, non-read-only tool, and the description supplies the context they cannot: AES-256-GCM encryption at rest, values never returned by default, expired secrets refused, atomic writes, and that expiry/use fields are metadata only. It also discloses the host env-var gate on reveal and the audit-trail implications, all beyond what annotations convey.

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?

Front-loaded purpose sentence followed by labeled Use/Avoid/Speed/Output blocks, so an agent can scan to what it needs. It is dense rather than padded, though the 'Speed' sentence mixes performance claims with storage details and could be trimmed.

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?

With 8 parameters, an action enum, and no output schema, the description compensates by enumerating the return fields per action (secret_set, secret_get/list, secret_delete) and by spelling out rotation/expiry behavior. Nothing an agent needs to call this 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 already 88%, yet the description adds real semantics: that value_env is preferred over value so the secret never enters the transcript, and that reveal is gated by a host flag. It doesn't explain 'reason' beyond what the schema already states, so it adds value but not exhaustively.

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 ('Manage API tokens/credentials') plus the defining constraint ('without leaking them'), and enumerates the four actions in one place. No sibling tool covers secrets, so the description alone makes the tool's role unmistakable.

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 'Use when' clauses map each action (set/get/list/delete) to an intent, and an 'Avoid when' clause rules out non-secret config and plaintext retrieval. It also names the preferred alternative workflow (project_shell_run with secret_env) and the escape hatch (reveal=true + VENIRA_SECRET_ALLOW_REVEAL=1).

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