Skip to main content
Glama

register_hook

Register shell commands, HTTP webhooks, or process signals that automatically trigger when secrets are written, deleted, or rotated to keep external systems in sync.

Instructions

[hooks] Register a side-effect (shell command, HTTP webhook, or process signal) that fires automatically when a matching secret is written, deleted, or rotated. Use to keep external systems in sync (restart a service after rotation, post to Slack on delete, kick a build); prefer agent_remember for storing facts an agent should recall later, and register_hook is not the right tool for time-based scheduled rotation (use agent_scan for that). Mutates the hook registry on disk. At least one match criterion (key, keyPattern, or tag) is required — calls without any return an error. Returns JSON of the registered hook entry including its assigned id (use that id with remove_hook).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
keyNoTrigger only on this exact key name. Pick at most one of `key` / `keyPattern` / `tag` (or combine for stricter matching).
tagNoTrigger on any secret carrying this exact tag. Combinable with key/keyPattern as an AND filter.
urlNoRequired when type='http'. Full URL to POST a JSON body `{ id, key, scope, action, timestamp }` to (the value itself is never sent).
typeYesHook delivery mechanism. 'shell' runs a local command, 'http' POSTs JSON to a URL, 'signal' sends an OS signal to a named process.
scopeNoRestrict the hook to secrets in this scope. Omit to fire across both global and project secrets.
actionsNoWhich lifecycle actions trigger this hook. Defaults to all three.
commandNoRequired when type='shell'. The literal shell command to run; q-ring exposes the matching key as $QRING_HOOK_KEY and action as $QRING_HOOK_ACTION.
keyPatternNoTrigger on any key matching this glob pattern. Examples: 'DB_*', 'STRIPE_*'.
signalNameNoSignal name to send (e.g. 'SIGHUP', 'SIGUSR1'). Defaults to SIGHUP, which most daemons treat as 'reload config'.SIGHUP
descriptionNoFree-text human-readable description, surfaced by `list_hooks` and the dashboard.
signalTargetNoRequired when type='signal'. Either a numeric PID or a process name resolvable via `ps`.
Behavior5/5

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

No annotations provided, but the description fully discloses mutation side-effect ('Mutates the hook registry on disk'), return value ('Returns JSON...including its assigned `id`'), and error behavior. Explains trigger mechanism and delivery details.

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: starts with purpose, then usage guidelines, then behavioral details. No redundant sentences; each sentence adds value. Appropriate length given tool complexity.

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?

Despite no output schema or annotations, the description covers purpose, behavior, error conditions, return value, and parameter relationships. Complete for a complex tool with 11 parameters.

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% with detailed descriptions, so baseline is 3. The description adds extra context by explaining conditional requirements (e.g., 'Pick at most one of...') and combining filters, justifying a 4.

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 the tool registers a side-effect hook that fires on secret lifecycle events. It distinguishes from siblings like `agent_remember` and `agent_scan` by specifying different use cases.

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 guidance on when to use this tool vs alternatives (e.g., 'prefer `agent_remember` for storing facts...'). Also notes the requirement for at least one match criterion.

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/I4cTime/quantum_ring'

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