What can you do with this server?

Impri provides a human-approval inbox for AI agents, enabling human oversight of agent actions and automated monitoring of external sources. Action Approval Workflow * Submit actions for approval (impri_push_action): Push a proposed action (e.g., sending an email, posting a comment) with a title, formatted preview, optional context URL, and editable fields so reviewers can tweak content before approving. Supports idempotent submissions to prevent duplicates on retry. * Await a human decision (impri_await_decision): Poll until the human approves, rejects, or the action expires — returns the final decision along with any edits made by the reviewer. * Report execution result (impri_report_result): After attempting an approved action, report whether it succeeded or failed, closing the audit loop. * Check inbox queue depth (impri_inbox_status): See how many actions are pending to avoid flooding the inbox and causing approvals to expire. Watcher / Monitoring * Create a custom watcher (impri_create_watcher): Set up recurring monitors on external sources (RSS feeds, Reddit, URL diffs, GitHub releases, etc.) with keyword filters, deduplication, and configurable schedules — delivering matches to the inbox or a webhook. * List active watchers (impri_list_watchers): View all configured watchers, their status (active, paused, degraded), and IDs. * Discover watcher presets (impri_list_watcher_presets): Browse 18+ pre-built templates for common sources like Hacker News, Reddit, GitHub releases, npm, YouTube, arXiv, and more. * Create a watcher from a preset (impri_create_watcher_from_preset): Instantly spin up a watcher by choosing a preset and supplying minimal parameters (e.g., a subreddit name or GitHub repo). Additional Capabilities * Notification channels: Integrate with Slack, Discord, Telegram, or email for pending approval alerts. * Audit log: Maintains a full trail of events, decisions, and execution results for transparency. * CLI: A dedicated command-line interface for managing the inbox, approving/rejecting actions, and managing watchers and API keys. * Self-hosting: Deploy via Docker Compose or a local dev setup, with a full REST API and OpenAPI spec.

Which integrations are available for this server?

Provides a watcher preset to monitor arXiv for new papers and request human approval before taking action. Integrates with CrewAI to incorporate approval steps into multi-agent workflows. Sends notifications to Discord channels for pending actions requiring approval. Provides watcher presets to monitor GitHub releases and events, enabling approval-gated actions. Integrates with LangChain to add human approval gating in AI agent workflows. Integrates with Make to add human approval steps in automated scenarios. Integrates with n8n to enable approval-based workflows in automation pipelines. Provides a watcher preset to monitor npm package releases and request approval for related actions. Sends push notifications via ntfy for pending actions, enabling quick human review. Integrates with OpenAI Agents to require human approval before executing agent actions. Provides watcher presets to monitor Reddit posts and comments, with approval workflows for responses. Sends notifications to Slack channels and allows approval decisions via Slack integration. Sends notifications and provides in-chat Approve/Reject buttons via a Telegram bot for fast approvals. Integrates with Zapier to connect approval workflows with hundreds of other apps.

Impri

by sekera-radim

Overview Schema Source Related Servers Discussions Admin

Hybrid

Impri provides a human-approval inbox for AI agents, enabling human oversight of agent actions and automated monitoring of external sources.

Action Approval Workflow

Submit actions for approval (impri_push_action): Push a proposed action (e.g., sending an email, posting a comment) with a title, formatted preview, optional context URL, and editable fields so reviewers can tweak content before approving. Supports idempotent submissions to prevent duplicates on retry.
Await a human decision (impri_await_decision): Poll until the human approves, rejects, or the action expires — returns the final decision along with any edits made by the reviewer.
Report execution result (impri_report_result): After attempting an approved action, report whether it succeeded or failed, closing the audit loop.
Check inbox queue depth (impri_inbox_status): See how many actions are pending to avoid flooding the inbox and causing approvals to expire.

Watcher / Monitoring

Create a custom watcher (impri_create_watcher): Set up recurring monitors on external sources (RSS feeds, Reddit, URL diffs, GitHub releases, etc.) with keyword filters, deduplication, and configurable schedules — delivering matches to the inbox or a webhook.
List active watchers (impri_list_watchers): View all configured watchers, their status (active, paused, degraded), and IDs.
Discover watcher presets (impri_list_watcher_presets): Browse 18+ pre-built templates for common sources like Hacker News, Reddit, GitHub releases, npm, YouTube, arXiv, and more.
Create a watcher from a preset (impri_create_watcher_from_preset): Instantly spin up a watcher by choosing a preset and supplying minimal parameters (e.g., a subreddit name or GitHub repo).

Additional Capabilities

Notification channels: Integrate with Slack, Discord, Telegram, or email for pending approval alerts.
Audit log: Maintains a full trail of events, decisions, and execution results for transparency.
CLI: A dedicated command-line interface for managing the inbox, approving/rejecting actions, and managing watchers and API keys.
Self-hosting: Deploy via Docker Compose or a local dev setup, with a full REST API and OpenAPI spec.

Impri — Approval Inbox for AI Agents

The imprimatur for your AI agents. Watchers watch the world, the Approval Inbox holds the agent's hands until a human says yes.

Quickstart

Two ways to run Impri — pick one. Both give you an API key and an inbox URL in under 5 minutes.

Cloud (no install)

curl -s -X POST https://api.impri.dev/v1/signup \
  -H "Content-Type: application/json" \
  -d '{"name": "my-agent"}'
# → { "key": "im_...", "project_id": "proj_...", ... }

Or skip curl and click Create an API key at app.impri.dev — same result. Your inbox is at app.impri.dev, the API base URL is https://api.impri.dev/v1. It's early beta but is the fastest way to try Impri with no Docker required.

Docker Compose (self-host, < 5 minutes)

git clone https://gitlab.com/sekera.radim/impri.git
cd impri
docker compose up

Open http://localhost:8080 in your browser.

On first start the server prints the bootstrap Admin API key to the logs:

╔══════════════════════════════════════════════════════╗
║            IMPRI — FIRST RUN BOOTSTRAP               ║
╠══════════════════════════════════════════════════════╣
║  Admin API Key: im_...                               ║
║  Project ID:    proj_...                             ║
║  Store this key securely — it will not be shown again.║
╚══════════════════════════════════════════════════════╝

Copy the key, paste it into the login screen, and you're in.

Dev mode (hot-reload, self-host)

Terminal 1 — server:

cd server
npm install
npm run dev
# Server starts on http://localhost:8484

Terminal 2 — UI:

cd ui
npm install
npm run dev
# UI starts on http://localhost:5173
# /v1 requests are proxied to localhost:8484

Related MCP server: MIDAS

API at a glance

Base URL: https://api.impri.dev/v1 (cloud) or http://localhost:8484/v1 (self-host)
Auth: Authorization: Bearer im_<key>

Method	Path	Description
POST	`/v1/actions`	Push a new action for approval
GET	`/v1/actions`	List actions (`?status=pending&q=…&kind=…&since=…`)
GET	`/v1/actions/:id`	Get action detail + decision
POST	`/v1/actions/:id/decision`	Approve or reject (single)
POST	`/v1/actions/bulk-decision`	Approve or reject up to 50 actions at once
POST	`/v1/actions/:id/result`	Report execution result
GET	`/v1/openapi.json`	OpenAPI spec

Push an action (curl example)

curl -X POST https://api.impri.dev/v1/actions \
  -H "Authorization: Bearer im_..." \
  -H "Content-Type: application/json" \
  -d '{
    "kind": "reddit.comment",
    "title": "Reply to: Why is resume advice so conflicting?",
    "preview": {
      "format": "markdown",
      "body": "The advice conflicts because..."
    },
    "target_url": "https://reddit.com/r/jobs/comments/...",
    "expires_in": 86400,
    "editable": ["preview.body"]
  }'

Self-hosting instead? Swap the URL for http://localhost:8484/v1/actions.

MCP server (Claude Code / agents)

npx @impri/mcp
# cloud:      IMPRI_API_KEY=im_...  IMPRI_BASE_URL=https://api.impri.dev
# self-host:  IMPRI_API_KEY=im_...  IMPRI_BASE_URL=http://localhost:8484

Project structure

server/   TypeScript + Fastify + SQLite — REST API (port 8484)
mcp/      MCP server (stdio) — thin wrapper over the REST API
ui/       Vue 3 + Vuetify — web inbox (port 5173 dev / 8080 Docker)
docker/   Dockerfiles (server.Dockerfile)
docs/     Research, ADRs

CLI

The impri CLI lets humans manage the inbox from a terminal — approve, reject, tail pending actions, add watchers, and manage keys — without writing any code.

# Build and install (local, pre-npm)
cd sdk/typescript && npm install && npm run build
cd ../cli && npm install && npm run build
npm install -g ./cli

# Connect to your instance
impri init --cloud --signup   # or: impri init (self-hosted)

# Common commands
impri inbox                   # pending actions
impri tail                    # live-tail new actions
impri approve act_abc123
impri watch add github-releases --param owner=fastify --param repo=fastify

CLI reference

SDKs & integrations

v0.1, pre-release — both cloud and self-host work today; expect rough edges either way.

Package	Location	Language
CLI	`cli/`	Node 18+
Python SDK	`sdk/python/`	Python 3.10+
TypeScript SDK	`sdk/typescript/`	Node 18+ (native fetch)
MCP server	`mcp/` / `npx @impri/mcp`	Any MCP client

pip install -e sdk/python          # Python SDK (local, pre-PyPI)
npm install ./sdk/typescript       # TS SDK (local, pre-npm)
npx @impri/mcp                     # MCP server (published)

Python SDK reference
TypeScript SDK reference
Integrations — LangChain, OpenAI Agents, CrewAI, n8n, Make, Zapier, webhook receivers
Cookbook — recipes for email approval, SQL gating, social posts, idempotent batches, webhook verification, key rotation

Documentation

Web docs: https://impri.dev/docs
CLI reference — install, impri init, every command with examples, config + env precedence
Quickstart — signup → first approved action in < 5 min
Example agent — a complete, dependency-free agent that proposes an action, waits for approval, then acts and reports back
How to add human approval to an AI agent
Self-hosting — Docker, env vars, backups, reverse proxy
Webhooks — HMAC verification, retries, polling fallback
Inbox UX & Bulk API — keyboard shortcuts, bulk approve/reject, search/filter parameters, POST /v1/actions/bulk-decision reference
Watcher presets — 18 ready-to-use templates (HN, Reddit, GitHub, npm, arXiv, …); REST + SDK + MCP usage
Notification channels — Slack, Discord, Telegram, ntfy, email, and generic webhook; digest window, auto-disable, SSRF protection
Telegram Approval Bot — in-chat Approve / Reject buttons; setup, security model, troubleshooting
Audit log — event types, query API (GET /v1/audit), export (NDJSON/CSV), retention, and security model
llms.txt — machine-readable index for AI assistants

Self-hosting notes

SQLite data is persisted in a Docker volume (impri-data).
Set WEBHOOK_SECRET env var to a random string for HMAC webhook signing.
BASE_URL should match the public URL of your deployment (used in inbox_url links).

License

MIT — see LICENSE. Self-host the full core freely; the hosted cloud and team features are the paid offering (see MONETIZATION.md).

Available Tools

8 tools

impri_await_decisionA

Poll until the human approves, rejects, or the timeout elapses.

Checks GET /actions/:id every 5 seconds and returns as soon as the action leaves the pending state.

Decision meanings: "approved" — proceed with the action; any reviewer edits are included in preview/payload "rejected" — abort; respect the decision and do not proceed "expired" — the approval window closed; create a new action if the task is still relevant

On timeout the action stays pending in the inbox. Call impri_inbox_status to check queue depth and consider pausing further submissions.

Typical usage:

impri_push_action → get action_id
impri_await_decision(action_id) → wait for human decision
If approved: execute the action, then impri_report_result(action_id, "executed")

ParametersJSON Schema

Name	Required	Description	Default
`action_id`	Yes	The id returned by impri_push_action.
`timeout_s`	No	Maximum seconds to wait before returning (default 300 — 5 minutes). After timeout the action is still pending; retry or call impri_inbox_status.

TDQS

A4.9/5.0

Behavior5/5

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

No annotations provided, so description carries full burden. It discloses polling interval (5 seconds), decision meanings (approved, rejected, expired), timeout behavior (stays pending), and suggests follow-up calls. No contradictions.

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: summary first, then details on polling, decisions, timeout, and typical usage. Every sentence adds value, no redundancy, and front-loaded.

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 complexity (polling, multiple outcomes, workflow integration) and no output schema, the description is complete. Covers what, when, how to interpret, and what to do on timeout.

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% (baseline 3). Description adds meaning: action_id is 'returned by impri_push_action' and timeout_s explains default (300s) and behavior after timeout. This goes beyond the schema.

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 states 'Poll until the human approves, rejects, or the timeout elapses.' The verb 'poll' and resource 'human decision' are specific. It distinguishes from siblings like impri_push_action (push action) and impri_inbox_status (queue depth).

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?

Provides a 'Typical usage' sequence (push → await → execute/report) and alternatives on timeout (impri_inbox_status). Clearly tells when to use and when not to (after push, before execution).

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

impri_create_watcherA

Create a watcher that monitors external sources (RSS feeds, Reddit, URL diffs) and delivers matching items to the approval inbox or a webhook.

The watcher runs on the schedule you specify, deduplicates items by URL/content-hash, and delivers only new matches. The first run establishes a baseline and does not generate alerts.

Example — watch an RSS feed for AI-related news: spec: { name: "AI launches radar", kind: "rss", config: { url: "https://openai.com/news/rss.xml" }, keywords: ["launch", "gpt-", "voice"], keywords_none: ["funding", "benchmark"], min_score: 1, schedule: { every: "8h", jitter: "4h" } }

Returns { watcher_id, name, kind, status, next_run_at }.

ParametersJSON Schema

Name	Required	Description	Default
`spec`	Yes	Watcher specification (name, kind, config, keywords, keywords_none, min_score, schedule). See SPEC.md §3.2 for the full schema.

TDQS

A4.5/5.0

Behavior4/5

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

Discloses key behaviors: first run establishes baseline (no alerts), deduplication by URL/content-hash, delivery to inbox/webhook, and return object. Without annotations, this is a good level of transparency.

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?

Description is concise and well-structured: purpose, details, then example. Every sentence adds value with no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers creation, scheduling, deduplication, first-run behavior, and return value. Lacks error handling or permission requirements, but overall complete for a create tool given no output schema.

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 only describes 'spec' as a backup reference to SPEC.md. The description adds a detailed example with all fields (name, kind, config, keywords, etc.), significantly enhancing understanding beyond the schema.

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?

Description clearly states the verb 'Create' and resource 'watcher', and distinguishes from sibling tools like 'impri_list_watchers' and 'impri_create_watcher_from_preset'. The example and return value further clarify the purpose.

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

Usage Guidelines4/5

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

Description explains when to use this tool (monitor external sources) and provides details on scheduling and deduplication. It does not explicitly mention when not to use it or alternatives, but the sibling tools imply a differentiation.

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

impri_create_watcher_from_presetA

Create a watcher from a preset template by supplying the preset id and param values.

Presets handle all watcher config construction — URL building, keyword setup, SSRF validation — so you only provide the param values listed by impri_list_watcher_presets.

The schedule defaults to the preset's recommended interval but can be overridden. The name defaults to "{preset title}: {primary param value}" if omitted.

Returns { watcher_id, name, kind, status, next_run_at }.

Examples:

Watch the HN front page (no params needed): preset_id: "hn-front-page" params: {}

Watch a subreddit for new posts: preset_id: "reddit-subreddit" params: { subreddit: "MachineLearning" }

Watch a GitHub repo for new releases, check every 2 hours: preset_id: "github-releases" params: { owner: "fastify", repo: "fastify" } schedule: { every: "2h" }

Watch HN for keyword with a custom min_points threshold: preset_id: "hn-keyword" params: { keyword: "rust programming", min_points: "25" }

ParametersJSON Schema

Name	Required	Description
`name`	No	Optional display name for the watcher. Defaults to "{preset title}: {primary param value}" when omitted.
`params`	Yes	Key/value map of param values as strings. Required params must be present; optional params may be omitted to use preset defaults.
`schedule`	No	Optional schedule override. Omit to use the preset's default schedule.
`preset_id`	Yes	Preset identifier from impri_list_watcher_presets (e.g. "hn-front-page", "reddit-subreddit", "github-releases").

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description fully discloses behavior: schedule/naming defaults, SSRF validation, config construction by presets, and return structure. No contradictions.

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: summary, details, then four diverse examples. Every sentence adds value, no fluff.

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?

For 4 params with nested objects and no output schema, description covers return fields, defaults, and parameter behavior comprehensively with examples.

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% (baseline 3). Description adds meaning by explaining param type (key/value map of strings), requirement rules, and schedule override semantics.

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?

Clearly states it creates a watcher from a preset template, specifies what presets handle (URL building, keyword setup, SSRF validation), and differentiates from siblings like impri_create_watcher and impri_list_watcher_presets.

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

Usage Guidelines4/5

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

Explains when to use the tool (have a preset ID and params) and references impri_list_watcher_presets for param definitions, but lacks explicit when-not-to-use or direct mention of alternative tools.

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

impri_inbox_statusA

Check how many actions are waiting for human decisions.

Returns the pending count and a brief list of pending action titles. Call this before starting a large batch of tasks — if the inbox is backed up, pause and let the operator catch up to avoid actions expiring before they are reviewed.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior3/5

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

No annotations provided, so description carries full burden. It discloses return values and suggests impact of backlog. However, it lacks details on scope (e.g., whose inbox) and does not explicitly state it is read-only or mention auth/rate limits. Adequate but not rich.

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?

Two sentences, no fluff. First sentence states purpose, second gives usage advice. Every part is relevant and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, so description should fully explain return values. It mentions pending count and titles but does not specify format (e.g., numeric, list of strings). For a simple tool, acceptable but could be more precise.

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?

No parameters exist, so baseline is 4. Description adds context about output and usage beyond the empty schema, meeting expectations.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the tool checks how many actions are waiting for human decisions and returns count and titles. It is a specific verb+resource but does not explicitly distinguish from sibling tools, though the purpose is distinct.

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

Usage Guidelines4/5

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

Provides explicit when to use: 'Call this before starting a large batch of tasks' and advises on handling backlog. Does not mention alternatives or when not to use, but gives clear context.

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

impri_list_watcher_presetsA

List all available watcher presets with their parameters.

Presets are pre-configured watcher templates for common sources (Hacker News, Reddit, GitHub, npm, YouTube, arXiv, etc.). Each preset has an id, a human-readable title, required and optional params, and a default schedule.

Call this first to discover which preset fits your monitoring goal, then use impri_create_watcher_from_preset to create the watcher by supplying only the preset_id and param values. No deep knowledge of watcher config schemas is needed.

Example output: Community: - hn-front-page: "Hacker News Front Page" (rss) — no params required - reddit-keyword: "Reddit – Keyword Search" (reddit_search) — params: query, [subreddit]

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.7/5.0

Behavior4/5

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

No annotations provided, but description explains what a preset is and provides an example output. It implies a safe read operation without side effects. The behavioral context is adequate for a simple listing tool.

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?

Description is concise (4 sentences plus a helpful example). Every sentence adds value; no fluff.

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?

Tool is simple with no parameters and no output schema. Description fully explains purpose, presets structure, workflow, and related tool. Complete for this complexity level.

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?

No parameters in input schema (coverage 100%). Description does not need to add parameter information. Baseline score of 4 for zero parameters.

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 verb 'list' and the resource 'watcher presets'. It distinguishes itself from the sibling tool 'impri_create_watcher_from_preset' by indicating it is a prerequisite step.

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 says 'Call this first to discover which preset fits your monitoring goal, then use impri_create_watcher_from_preset'. Provides clear when-to-use and alternative.

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

impri_list_watchersA

List all configured watchers, optionally filtered by status.

Returns the watcher count and a summary line per watcher (id, name, kind, status). Use this to audit what is being monitored, check for degraded watchers, or find a watcher_id for further operations.

ParametersJSON Schema

Name	Required	Description	Default
`status`	No	Filter watchers by status. Omit to return all watchers regardless of status.

TDQS

A4.3/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden. It describes the output structure (count and summary line with id, name, kind, status) and optional filtering. No contradictions.

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?

Two sentences, front-loaded with purpose. Every sentence adds value without fluff.

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?

For a simple list tool with one optional parameter and no output schema, the description covers purpose, usage guidelines, and output structure completely.

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%, and the schema already describes the 'status' parameter with enum and description. The description reinforces filtering but adds no new semantic detail beyond the schema.

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 verb 'List' and the resource 'configured watchers', with optional status filtering. It distinguishes from sibling tools like impri_create_watcher and impri_list_watcher_presets.

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

Usage Guidelines4/5

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

Explicit usage scenarios are provided: 'audit what is being monitored, check for degraded watchers, or find a watcher_id'. No exclusions or alternatives are mentioned, but the context is clear.

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

impri_push_actionA

Submit an action to the Impri human-approval inbox.

The action appears in the operator's web and mobile inbox as a card with a title, formatted preview, and optional tap-to-edit fields. The operator approves or rejects with one tap; you poll for the decision with impri_await_decision.

Returns { action_id, status: "pending", inbox_url }. Save action_id — you need it for all follow-up calls.

Example — send a draft Reddit reply for review: kind: "reddit.comment" title: "Reply: Why is resume advice so conflicting?" preview: { format: "markdown", body: "The advice conflicts because different advisors optimise for different audiences..." } target_url: "https://reddit.com/r/cscareerquestions/comments/..." editable: ["preview.body"] // lets the reviewer tweak wording before approving

ParametersJSON Schema

Name	Required	Description
`kind`	Yes	Taxonomy label used for inbox filtering (e.g. 'reddit.comment', 'email.send', 'blog.publish'). Free-form; choose a consistent scheme.
`title`	Yes	Short headline shown in the inbox card. Keep it under 120 characters.
`payload`	No	Opaque data echoed back in the webhook callback — useful for storing context (e.g. Reddit post id, draft id, queue position). Not shown to the reviewer.
`preview`	Yes	The content the reviewer reads before deciding.
`editable`	No	Dot-notation fields the reviewer may edit before approving (e.g. ['preview.body']). The final edited values are echoed back in the approved action.
`expires_in`	No	Seconds until the action auto-expires (default 86400 = 24 h). After expiry the status becomes 'expired' and no decision can be made.
`target_url`	No	URL the reviewer can open for context (e.g. the Reddit thread, the email draft). Optional but strongly recommended.
`idempotency_key`	No	Stable key to prevent duplicate submissions on retry. The same key within 24 h returns the original action instead of creating a new one.

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, description covers action lifecycle (submission, pending, approval/rejection, expiry), return values, and editable fields. Good detail on behavior beyond creation.

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?

Well-structured with intro, return value, and example. Efficient but could be slightly shorter; no wasted sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 8-parameter submission tool without output schema, description covers key aspects: return shape, idempotency, expiry, preview format, and editable fields. Adequate for agent to invoke correctly.

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 has 100% coverage, description adds value by explaining workflow, providing example mapping, clarifying editable dot-notation, and noting idempotency. Does not repeat schema but enriches context.

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?

Clear verb 'Submit an action' and specific resource 'Impri human-approval inbox'. Differentiates from sibling impri_await_decision by noting polling, and example shows concrete usage.

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

Usage Guidelines4/5

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

Explicitly describes use case for human approval, mentions polling for decision, and provides example. Lacks explicit 'when not to use' instructions but context is clear.

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

impri_report_resultA

Report whether you successfully executed an approved action.

Closes the audit loop — the operator sees 'executed' or 'execute_failed' in the inbox alongside the original action and decision. Always call this after attempting an approved action, even on failure.

Statuses: "executed" — action was carried out successfully "execute_failed" — execution attempt failed (include the error in detail)

ParametersJSON Schema

Name	Required	Description
`detail`	No	Optional message — error description on failure, short confirmation on success.
`status`	Yes	Outcome of executing the approved action.
`action_id`	Yes	The id returned by impri_push_action.

TDQS

A4/5.0

Behavior3/5

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

Discloses the inbox effect and status options, which is adequate for a simple reporting tool. However, no annotations exist, so the description carries the full burden. It does not mention idempotency, error handling for invalid action_id, or any side effects beyond the inbox update.

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?

Extremely concise: two short paragraphs with clear front-loading of purpose. Every sentence adds value, no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no nested objects, the description explains the tool's role in the audit loop lifecycle. It covers the statuses and when to call. Minor gap: does not specify if the report can be called multiple times, but overall sufficient for a simple result-reporting tool.

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%, so baseline is 3. Description adds minimal value beyond schema: restates enum values and clarifies detail usage for error vs success. Does not provide formatting or constraints beyond schema.

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?

Clearly states the tool reports execution outcome of an approved action. Distinguishes from siblings like impri_push_action (which submits action) and impri_await_decision (which waits for decision) by targeting the post-approval reporting step.

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

Usage Guidelines4/5

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

Explicitly instructs to call after attempting an approved action, even on failure. Provides context of closing the audit loop and operator visibility. Lacks explicit alternatives or when-not-to-use, but sufficiently narrows usage to post-approval reporting.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

8 tool updatesJul 12, 2026
- First observedimpri_await_decision
- First observedimpri_create_watcher
- First observedimpri_create_watcher_from_preset
- First observedimpri_inbox_status
- First observedimpri_list_watcher_presets
- First observedimpri_list_watchers
- First observedimpri_push_action
- First observedimpri_report_result

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Scored 2026-07-12 20:45 across 8 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: watcher creation (two variants), listing, action pushing, decision awaiting, result reporting, and inbox status. No overlapping functionality.

Naming Consistency5/5

All tools use the 'impri_' prefix and follow a consistent verb_noun or verb_noun_noun pattern (e.g., create_watcher, push_action, list_watcher_presets). The naming is predictable and uniform.

Tool Count5/5

With 8 tools, the server covers two main domains—watcher management and action approval—without being bloated or sparse. Each tool serves a necessary role in the workflow.

Completeness4/5

The action lifecycle is well-covered (push, await, report, inbox status). For watchers, creation and listing are present, but missing update/delete operations are minor gaps that agents can work around.

Maintenance

ActivityActive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

pendnt
dev.pendnt
Human approvals, notifications, inbound webhooks, wake-ups for headless agents. Free trial: /try
1
Lassare
com.lassare
Human-in-the-loop for AI coding agents — ask questions, get approvals via Slack.
Communication Coding Agents Autonomous Agents
25
e2a — email for AI agentsOAuth
io.github.Mnexa-AI
Authenticated email gateway for AI agents — per-agent inboxes, HITL approval, SPF/DKIM verified.
Email Autonomous Agents
2187
e2a — email for AI agentsOAuth
dev.e2a
Authenticated email gateway for AI agents — per-agent inboxes, HITL approval, SPF/DKIM verified.
Email Communication AI & Machine Learning
1187

Related MCP Servers

final-approval
Autonomous Agents Agent Orchestration
finalapproval
A
license
A
quality
D
maintenance
Human-in-the-loop approval gate for AI agents. Your agent calls submit_approval before any irreversible action; a human reviews on a branded page; a signed webhook fires back with the decision.
Updated 5 months ago (2026-04-19 13:44 UTC)
1
1
MIT
MIDAS
Autonomous Agents Command Line
omarkhandji-commits
A
license
Not graded
quality
C
maintenance
Local-first AI agent for approval-gated automation and verifiable LLM workflows.
Updated a month ago (2026-07-31 18:35 UTC)
1
MIT
gotoHuman MCP Server
Autonomous Agents App Automation
ampcome-mcps
A
license
Not graded
quality
D
maintenance
Enables AI agents to request human approvals with customizable forms, webhooks, and team features.
Updated a year ago (2025-07-15 07:03 UTC)
29
MIT
AgentGate
Agent Orchestration Security
agentkitai
A
license
A
quality
A
maintenance
Human-in-the-loop approval gateway for agent tool calls: agents request, policies decide, humans approve via Slack/Discord/web — with an OWASP-LLM-Top-10-tagged audit trail. Self-hostable.
Updated 12 days ago (2026-08-30 20:13 UTC)
10
18
33
MIT