Skip to main content
Glama

_delimit_secret_impl

Manage just-in-time credential access through the local Delimit secrets broker. Store, retrieve, list, revoke, or audit credentials with scope enforcement and access logging.

Instructions

Unified secrets-broker entry point — dispatches to one of five actions.

Manages just-in-time credential access through the local Delimit secrets broker (ai.secrets_broker) instead of bare environment variables or .env files: store a credential once with an access scope, fetch it at execution time with every read recorded to an audit trail, inventory credential metadata without exposing values, revoke on rotation/leak, and read the access log.

When to use: as the single MCP-registered secrets surface (delimit_secret) when the caller wants to pick the operation by name in one call rather than choosing a specific delimit_secret_* alias. When NOT to use: from internal code paths — prefer the specific alias (delimit_secret_store, delimit_secret_get, delimit_secret_list, delimit_secret_revoke, delimit_secret_access_log) so each operation's docstring and arg schema show up at the right call site. Do not use the broker as a general key/value store — it is credential-scoped and every read is audited.

Sibling contrast: each delimit_secret_ wrapper below is a thin alias over this implementation; they exist so the action's docstring lives at the right name. This is the dispatch core. Versus delimit_context_* / delimit_memory_*: those persist plans and notes; this persists access-controlled credentials with a read audit trail.

Storage & access model: credentials are persisted to the local broker store under ~/.delimit/secrets/ (encoded at rest) and returned in cleartext to an authorized caller — the host filesystem is the trust boundary, so protect it accordingly. Scope is enforced at READ time: scope="all" permits any caller; otherwise the requester's agent_type or tool must appear in the credential's comma-separated allow-list. The access log records who/what/when and whether access was granted — it never stores the credential value, and "list" returns metadata only, never values.

Side effects (per action):

  • "store": WRITES/overwrites the credential under ~/.delimit/secrets/ with its scope and description. A same-name store overwrites silently; there is no version history.

  • "get": returns the credential value to an authorized requester and appends an access-log entry (granted true/false); on success it updates the credential's access counter / last-accessed timestamp. A scope denial, a missing name, or a revoked credential is logged and returns without a value.

  • "list": READ-ONLY. Returns credential metadata (name, scope, description, created_by, access_count, revoked, timestamps) — never values. Wrapped via _with_next_steps.

  • "revoke": WRITES a revoked flag + timestamp and appends a revoke entry to the access log; subsequent "get" calls are denied. Does NOT hard-delete the stored file.

  • "access_log": READ-ONLY. Returns the access trail (newest first), optionally filtered to one credential name. Wrapped via _with_next_steps. No action is license-gated. Errors are deterministic ({"error": "..."}): a missing required argument or an unknown action short-circuits before the backend call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionNoWhich secret operation to perform. One of "store", "get", "list", "revoke", "access_log". Default "list". Case- insensitive (lowered + stripped). Other values return a deterministic error.list
nameNoCredential name / key. Required for "store", "get", "revoke"; optional filter for "access_log" (empty = all); ignored for "list". Sanitized for filesystem safety.
valueNoThe credential to store. Required for action="store"; ignored otherwise. Never echoed back by "store".
scopeNoComma-separated agent/tool identities permitted to read this credential, or "all" for any requester. Used only by action="store". Default "all". Enforced at read time.all
descriptionNoHuman-readable description (action="store" only). Optional but recommended; surfaces in "list" and the audit trail.
agent_typeNoIdentity of the requesting agent (action="get" only), checked against scope.
toolNoName of the requesting tool (action="get" only), checked against scope.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

No annotations provided; description carries full burden. It details side effects per action, storage model under ~/.delimit/secrets/, scope enforcement, audit trail behavior, and error handling. Every action's read/write nature and consequences are described.

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?

Well-structured with clear sections: purpose, when to use, sibling contrast, storage model, side effects. Sentences are informative and not redundant. Despite length, every sentence adds necessary detail for a complex 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 7 parameters, no required params, and output schema exists, the description is complete. It covers all operations, side effects, storage, scope, audit, and error behavior. Agent has enough information to use this tool correctly.

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

Parameters5/5

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

Schema description coverage is 100%, but description adds significant value beyond schema: action is case-insensitive, name is sanitized for filesystem safety, value is never echoed back, scope is enforced at read time, agent_type and tool are checked against scope. Provides context that aids correct invocation.

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 clearly states it is a unified entry point for five secret operations, distinguishing from sibling tools by explaining that aliases exist for each action and contrasting with other delimit_* tools like delimit_context_* and delimit_memory_*. The verb 'dispatches' and resource 'secrets-broker entry point' are specific.

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?

Explicitly states when to use (as single MCP-registered secrets surface) and when NOT to use (from internal code paths, prefer specific alias) and not to use as general key/value store. Provides clear alternative: use specific delimit_secret_* aliases for each action.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/delimit-ai/delimit-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server