What can you do with this server?

AgentGate is a human-in-the-loop approval gateway for AI agents, enabling policy-based governance, multi-channel approvals, and full audit trails. Approval Request Management * Submit requests — Create approval requests for agent actions (e.g., send_email, make_purchase) with optional parameters, context, and urgency level (low, normal, high, critical) * Check status — Retrieve the current status of any request by ID * List requests — Browse all requests with filtering by status (pending, approved, denied, expired) * Make decisions — Approve or deny pending requests with an optional reason and decision-maker identity Policy Management * List, create, update, and delete policies — Define rules to automatically approve, deny, or route agent requests to humans based on action, parameters, and priority Audit & Observability * Full audit trail — Query logs with filters for date range, actor, action, request ID, status, and event type, with pagination support * Get audit actors — Retrieve all unique actor identifiers from audit logs Additional Capabilities * API Key Management — Create and manage keys with specific scopes and per-key rate limits * Multi-channel Notifications — Webhooks, Slack, and Discord integrations for real-time approval notifications * Agent Integration — TypeScript SDK and MCP-compatible client support (e.g., Claude Desktop) * Self-Hosting — Deploy via Docker Compose, configurable via environment variables, with a web dashboard, CLI, or API

Which integrations are available for this server?

Allows agents to request approvals that human operators can approve or deny directly from Discord via a bot. Allows agents to request approvals that human operators can approve or deny directly from Slack via a bot.

AgentGate

by agentkitai

Overview Schema Related Servers Score Discussions

TypeScript

Remote

Your AI agent wants to send an email, delete a file, or deploy to production. Should it? AgentGate lets you define policies that auto-approve safe actions, auto-deny dangerous ones, and route everything else to a human — via dashboard, Slack, Discord, or email.

✨ Highlights

🛡️ Policy engine — auto-approve, auto-deny, or route to humans based on rules
👥 Multi-channel approvals — Slack, Discord, email, or web dashboard
🔌 TypeScript SDK + MCP — works with any agent framework or Claude Desktop
🪝 Webhooks with retry — real-time notifications with exponential backoff
📝 Full audit trail — every request, decision, and action logged, each policy decision tagged with the OWASP LLM Top-10 risk it mitigates (compliance evidence)
🐳 Docker-ready — one docker-compose up for the full stack
🔐 Production-hardened — SSRF protection, ReDoS defense, structured logging, graceful shutdown
🔗 One-click decision links — approve or deny directly from notification emails and webhooks
♿ Accessible UI — keyboard-navigable approval modals, focus trapping, ARIA labels
💀 Skeleton loading — smooth loading states across every dashboard page
⚡ Fast & lightweight — Hono server, SQLite or PostgreSQL

Quickstart

# Self-host the full stack (server + dashboard + Postgres):
docker compose up

# …or from source:
pnpm install && pnpm --filter @agentkitai/agentgate-server db:migrate && pnpm --filter @agentkitai/agentgate-server bootstrap && pnpm dev

Drop AgentGate into an MCP client (Claude Desktop / Cursor / VS Code) — point it at the gateway:

{ "mcpServers": { "agentgate": { "command": "npx", "args": ["@agentkitai/agentgate-mcp"] } } }

Dashboard

See all pending requests at a glance, color-coded by urgency so you know what needs attention first.

Dashboard

Approval Requests

Review, approve, or deny requests — filter by status to focus on what matters.

Requests

Audit Log

Search through every decision with filters for event type, action, actor, and date range.

Audit Log

Request Detail

Drill into any request to see parameters, context, timeline, and audit trail — with one-click Approve/Deny buttons.

Request Detail

API Keys

Manage API keys with fine-grained scopes, rate limits, and usage tracking. Create, edit, or revoke keys from the dashboard.

API Keys

Webhooks

Configure webhook endpoints for real-time notifications. Add URLs, pick events, and let AgentGate handle retries automatically.

Webhooks

Related MCP server: agent-sudo-mcp

Quick Start

1. Install dependencies

pnpm install

2. Run database migrations

pnpm --filter @agentkitai/agentgate-server db:migrate

3. Bootstrap (create admin API key)

pnpm --filter @agentkitai/agentgate-server bootstrap

Save the API key - it's shown once only! Set it in your environment:

export AGENTGATE_API_KEY="agk_..."

4. Start the development environment

# Start server (port 3000) and dashboard (port 5173)
pnpm dev

5. Run the demo

In a new terminal (with API key set):

export AGENTGATE_API_KEY="agk_..."
pnpm demo

6. Open the dashboard

Visit http://localhost:5173 to view and manage approval requests.

Architecture

┌─────────────────────────────────────────────────────────────────┐
│                         AI Agents                                │
│  (use @agentkitai/agentgate-sdk or MCP to request approvals)               │
└───────────────────────────┬─────────────────────────────────────┘
                            │ HTTP API (authenticated)
                            ▼
┌─────────────────────────────────────────────────────────────────┐
│                    AgentGate Server                              │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐          │
│  │ Policy Engine│  │ Request Store│  │ Audit Logger │          │
│  ├──────────────┤  ├──────────────┤  ├──────────────┤          │
│  │  API Keys    │  │  Webhooks    │  │  MCP Server  │          │
│  └──────────────┘  └──────────────┘  └──────────────┘          │
└───────────────────────────┬─────────────────────────────────────┘
                            │
              ┌─────────────┼─────────────┐
              ▼             ▼             ▼
┌────────────────┐ ┌────────────────┐ ┌────────────────┐
│  Web Dashboard │ │   Slack Bot    │ │  Discord Bot   │
│(React+Tailwind)│ │(approve in DM) │ │(approve in ch) │
└────────────────┘ └────────────────┘ └────────────────┘
              │             │             │
              └─────────────┼─────────────┘
                            ▼
                      ┌──────────┐
                      │  Humans  │
                      └──────────┘

Packages

Package	Description	Docs
`@agentkitai/agentgate-core`	Types, schemas, policy engine	-
`@agentkitai/agentgate-server`	Hono API server	-
`@agentkitai/agentgate-sdk`	TypeScript SDK for agents	README
`@agentkitai/agentgate-cli`	Command-line interface	-
`@agentkitai/agentgate-mcp`	MCP server for Claude Desktop	-
`@agentkitai/agentgate-slack`	Slack bot integration	README
`@agentkitai/agentgate-discord`	Discord bot integration	README
`@agentkitai/agentgate-dashboard`	React web dashboard	-

SDK Usage

import { AgentGateClient } from '@agentkitai/agentgate-sdk';

// Create client with API key
const client = new AgentGateClient({
  baseUrl: 'http://localhost:3000',
  apiKey: process.env.AGENTGATE_API_KEY,
});

// Request approval
const request = await client.request({
  action: 'send_email',
  params: {
    to: 'customer@example.com',
    subject: 'Order shipped!',
  },
  urgency: 'normal',
});

// Wait for human decision
const decided = await client.waitForDecision(request.id, {
  timeout: 60000, // 1 minute
});

if (decided.status === 'approved') {
  // Execute the action
  await sendEmail(decided.params);
} else {
  console.log('Action denied:', decided.decisionReason);
}

CLI

AgentGate includes a command-line interface for managing approval requests.

Installation

# From the monorepo
pnpm --filter @agentkitai/agentgate-cli build

# Or install globally (when published)
npm install -g @agentkitai/agentgate-cli

Configuration

Configure the CLI with your server URL and API key:

# Set server URL
agentgate config set serverUrl http://localhost:3000

# Set API key
agentgate config set apiKey agk_your_api_key

# View current config
agentgate config show

Configuration is stored in ~/.agentgate/config.json. You can also use environment variables:

export AGENTGATE_URL=http://localhost:3000
export AGENTGATE_API_KEY=agk_...

Commands

Command	Description
`agentgate config show`	Show current configuration
`agentgate config set <key> <value>`	Set a configuration value
`agentgate request <action>`	Create a new approval request
`agentgate status <id>`	Get status of a request
`agentgate list`	List approval requests
`agentgate approve <id>`	Approve a pending request
`agentgate deny <id>`	Deny a pending request

Examples

# Create a request
agentgate request send_email \
  --params '{"to": "user@example.com", "subject": "Hello"}' \
  --urgency high

# List pending requests
agentgate list --status pending

# Approve a request
agentgate approve req_abc123 --reason "Looks good"

# Deny a request
agentgate deny req_abc123 --reason "Not authorized"

# Output as JSON
agentgate list --json

MCP Integration

AgentGate includes a Model Context Protocol (MCP) server for integration with Claude Desktop and other MCP-compatible clients.

Claude Desktop Configuration

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "agentgate": {
      "command": "npx",
      "args": ["@agentkitai/agentgate-mcp"],
      "env": {
        "AGENTGATE_URL": "http://localhost:3000",
        "AGENTGATE_API_KEY": "agk_..."
      }
    }
  }
}

Available MCP Tools

Tool	Description
`agentgate_request`	Submit a new approval request
`agentgate_get`	Get the status of an approval request by ID
`agentgate_list`	List approval requests with optional filters
`agentgate_decide`	Approve or deny a pending request
`agentgate_list_policies`	List all policies ordered by priority
`agentgate_create_policy`	Create a new policy with rules
`agentgate_update_policy`	Replace an existing policy
`agentgate_delete_policy`	Delete a policy by ID
`agentgate_list_audit_logs`	List audit log entries with filters and pagination
`agentgate_get_audit_actors`	Get unique actor values from audit logs

Authentication

AgentGate uses API keys for authentication. All API requests (except /health) require a valid API key.

API Key Scopes

Scope	Description
`admin`	Full access to all operations
`request:create`	Create new approval requests
`request:read`	Read approval requests
`request:decide`	Approve or deny requests
`webhook:manage`	Create/update/delete webhooks

Using API Keys

HTTP Header:

curl -H "Authorization: Bearer agk_..." http://localhost:3000/api/requests

SDK:

const client = new AgentGateClient({
  baseUrl: 'http://localhost:3000',
  apiKey: process.env.AGENTGATE_API_KEY,
});

Creating Additional API Keys

// Via API (requires admin scope)
POST /api/api-keys
{
  "name": "My Agent",
  "scopes": ["request:create", "request:read"]
}

API Endpoints

Method	Endpoint	Description	Required Scope
`POST`	`/api/requests`	Create approval request	`request:create`
`GET`	`/api/requests`	List requests (with filters)	`request:read`
`GET`	`/api/requests/:id`	Get request by ID	`request:read`
`POST`	`/api/requests/:id/decide`	Submit approval/denial	`request:decide`
`GET`	`/api/requests/:id/audit`	Get audit trail	`request:read`
`GET`	`/api/policies`	List policies	`admin`
`POST`	`/api/policies`	Create policy	`admin`
`PUT`	`/api/policies/:id`	Update policy	`admin`
`DELETE`	`/api/policies/:id`	Delete policy	`admin`
`POST`	`/api/api-keys`	Create API key	`admin`
`GET`	`/api/api-keys`	List API keys	`admin`
`PATCH`	`/api/api-keys/:id`	Update API key	`admin`
`DELETE`	`/api/api-keys/:id`	Revoke API key	`admin`
`GET`	`/api/webhooks`	List webhooks	`webhook:manage`
`POST`	`/api/webhooks`	Create webhook	`webhook:manage`
`DELETE`	`/api/webhooks/:id`	Delete webhook	`webhook:manage`
`GET`	`/health`	Health check	(none)

Rate Limiting

AgentGate supports per-API-key rate limiting to prevent abuse and ensure fair usage.

How It Works

Rate limits use a sliding window algorithm (requests per minute)
Limits are configured per API key
When exceeded, requests return 429 Too Many Requests
Rate limit headers are included in all authenticated responses

Rate Limit Headers

Header	Description
`X-RateLimit-Limit`	Maximum requests per minute
`X-RateLimit-Remaining`	Remaining requests in current window
`X-RateLimit-Reset`	Seconds until window resets

Configuring Rate Limits

Set rate limits when creating or updating API keys:

// Via API (requires admin scope)
POST /api/api-keys
{
  "name": "My Agent",
  "scopes": ["request:create", "request:read"],
  "rateLimit": 60  // 60 requests per minute
}

// null = unlimited
{
  "name": "Internal Service",
  "scopes": ["admin"],
  "rateLimit": null
}

Dashboard

Rate limits can also be managed from the web dashboard under Settings → API Keys.

Webhooks

AgentGate can notify external systems when request events occur.

Setting Up Webhooks

// Create a webhook via API
POST /api/webhooks
{
  "url": "https://your-server.com/webhook",
  "events": ["request.created", "request.decided"],
  "secret": "optional-signing-secret"
}

Webhook Events

Event	Description
`request.created`	A new approval request was created
`request.decided`	A request was approved or denied
`request.expired`	A request expired without decision

Webhook Payload

{
  "event": "request.decided",
  "timestamp": "2024-01-15T10:30:00Z",
  "data": {
    "id": "abc123",
    "action": "send_email",
    "status": "approved",
    "decidedBy": "admin@example.com"
  }
}

Webhook Signatures

If you provide a secret, requests are signed with HMAC-SHA256:

X-AgentGate-Signature: sha256=...

Verify by computing HMAC-SHA256(secret, body) and comparing.

Webhook Retry

Failed webhook deliveries are retried automatically with exponential backoff. The server scans for pending deliveries and retries them with increasing delays (2^attempts * 1000ms) until successful or the maximum retry count is reached.

Configuration

Environment Variables

Variable	Default	Description
`PORT`	`3000`	Server port
`DATABASE_URL`	`./data/agentgate.db`	SQLite database path
`AGENTGATE_API_KEY`	-	API key for SDK/CLI
`SLACK_BOT_TOKEN`	-	Slack bot token (for Slack integration)
`SLACK_SIGNING_SECRET`	-	Slack signing secret
`DISCORD_BOT_TOKEN`	-	Discord bot token (for Discord integration)
`DISCORD_DEFAULT_CHANNEL`	-	Default Discord channel for notifications

File-Based Secrets (`_FILE` suffix)

For Docker secrets or Kubernetes secret mounts, AgentGate supports a _FILE suffix convention. Instead of setting a secret directly in an environment variable, point to a file containing the value:

Variable	Reads secret from file
`ADMIN_API_KEY_FILE`	Sets `ADMIN_API_KEY`
`JWT_SECRET_FILE`	Sets `JWT_SECRET`
`DATABASE_URL_FILE`	Sets `DATABASE_URL`
`REDIS_URL_FILE`	Sets `REDIS_URL`
`SLACK_BOT_TOKEN_FILE`	Sets `SLACK_BOT_TOKEN`
`SLACK_SIGNING_SECRET_FILE`	Sets `SLACK_SIGNING_SECRET`
`DISCORD_BOT_TOKEN_FILE`	Sets `DISCORD_BOT_TOKEN`
`SMTP_PASS_FILE`	Sets `SMTP_PASS`

Behavior:

File contents are trimmed of leading/trailing whitespace
If both the env var and the _FILE variant are set, the explicit env var takes precedence
Missing or unreadable files produce a warning but do not crash the server

Example with Docker Compose:

services:
  agentgate:
    environment:
      ADMIN_API_KEY_FILE: /run/secrets/admin_api_key
      JWT_SECRET_FILE: /run/secrets/jwt_secret
    secrets:
      - admin_api_key
      - jwt_secret

secrets:
  admin_api_key:
    file: ./secrets/admin_api_key.txt
  jwt_secret:
    file: ./secrets/jwt_secret.txt

Policy Configuration

Policies are stored in the database and can be managed via API:

// Example: Auto-approve low-risk emails
{
  name: "auto-approve-emails",
  priority: 10,
  enabled: true,
  rules: [
    {
      match: { action: "send_email" },
      decision: "auto_approve"
    }
  ]
}

Docker Deployment

AgentGate provides Docker images for easy self-hosted deployments.

Quick Start

Copy the example environment file:

cp .env.example .env

Generate secure credentials:

# Generate admin API key (required)
echo "ADMIN_API_KEY=$(openssl rand -hex 32)" >> .env

# Generate JWT secret (recommended for production)
echo "JWT_SECRET=$(openssl rand -hex 32)" >> .env

Start all services:

docker-compose up -d

Access the services:

Dashboard: http://localhost:3003
API Server: http://localhost:3002
Health Check: http://localhost:3002/health

Host ports are configurable via SERVER_PORT (default 3002) and DASHBOARD_PORT (default 3003); both map to the container's internal port 3000/80.

Services

Service	Description	Host Port
`server`	AgentGate API server	3002
`dashboard`	Web dashboard (nginx)	3003
`postgres`	PostgreSQL database	internal only*
`redis`	Redis (rate limiting, queues)	internal only*

* PostgreSQL and Redis are on an internal Docker network (agentgate-internal) and are not exposed to the host by default. During development, docker-compose.override.yml is auto-loaded and exposes them on ports 5432/6379. For production, run docker-compose -f docker-compose.yml up -d to skip the override.

With Slack or Discord Bots

To include the bot services, use the bots profile:

# Set required bot credentials in .env first
docker-compose --profile bots up -d

Configuration

All configuration is done via environment variables. See .env.example for all options.

Required variables:

ADMIN_API_KEY — Admin API key (min 16 characters)

Recommended for production:

JWT_SECRET — JWT signing secret (min 32 characters)
CORS_ALLOWED_ORIGINS — Restrict to your domain(s)
POSTGRES_PASSWORD — Use a strong password

Building Images

Build all images locally:

docker-compose build

Build a specific service:

docker-compose build server
docker-compose build dashboard

Database Migrations

Migrations run automatically when the server starts. For manual control:

# Run migrations inside the container
docker-compose exec server node -e "
  import('./dist/db/migrate.js').then(m => m.runMigrations())
"

Viewing Logs

# All services
docker-compose logs -f

# Specific service
docker-compose logs -f server

# Last 100 lines
docker-compose logs --tail=100 server

Stopping Services

# Stop all
docker-compose down

# Stop and remove volumes (WARNING: deletes data)
docker-compose down -v

Production Considerations

Use a reverse proxy (nginx, Caddy, Traefik) for TLS termination
Set strong passwords for PostgreSQL
Restrict CORS origins to your domain
Use Docker secrets for sensitive values in production
Set up backups for PostgreSQL data volume
Monitor health endpoints for uptime checks

Development

# Install dependencies
pnpm install

# Run migrations
pnpm --filter @agentkitai/agentgate-server db:migrate

# Bootstrap (create admin key)
pnpm --filter @agentkitai/agentgate-server bootstrap

# Start development (server + dashboard)
pnpm dev

Testing

AgentGate uses Vitest for testing across all packages.

# Run all tests
pnpm test

# Run tests with coverage report
pnpm test:coverage

# Run tests in watch mode (single package)
pnpm --filter @agentkitai/agentgate-server test:watch

# Run a specific test file
pnpm --filter @agentkitai/agentgate-server test -- src/__tests__/integration.test.ts

Coverage reports are generated per-package and include line, branch, and function coverage.

Code Quality

# Build all packages
pnpm build

# Type checking
pnpm typecheck

# Lint (ESLint)
pnpm lint

# Fix lint issues
pnpm lint:fix

# Format code (Prettier)
pnpm format

# Check formatting
pnpm format:check

Project Structure

agentgate/
├── packages/
│   ├── core/           # Shared types, schemas, policy engine
│   ├── server/         # Hono API server
│   ├── sdk/            # TypeScript SDK
│   ├── cli/            # Command-line interface
│   ├── mcp/            # MCP server for Claude Desktop
│   ├── slack/          # Slack bot
│   ├── discord/        # Discord bot
│   └── dashboard/      # React dashboard
├── apps/
│   └── demo/           # Demo application
├── docker-compose.yml  # Docker deployment
└── package.json        # Monorepo root

Contributing

Contributions are welcome! To get started:

Fork the repository
Clone and install dependencies (pnpm install)
Follow the Development section above to set up your local environment
Create a feature branch and make your changes
Run pnpm build && pnpm test to verify everything works
Open a pull request

Please make sure all tests pass and code is formatted (pnpm format:check && pnpm lint) before submitting.

🧰 AgentKit Ecosystem

Project	Description
AgentLens	Observability & audit trail for AI agents
Lore	Cross-agent memory and lesson sharing
AgentGate	Human-in-the-loop approval gateway	⬅️ you are here
FormBridge	Agent-human mixed-mode forms
AgentEval	Testing & evaluation framework
agentkit-cli	Unified CLI orchestrator

License

MIT

Available Tools

10 tools

agentgate_create_policyC

Create a new policy with rules.

ParametersJSON Schema

Name	Required	Description
`name`	Yes	Policy name
`rules`	Yes	Array of policy rules with match conditions and decisions
`enabled`	No	Whether policy is enabled (default true)
`priority`	No	Policy priority (default 100)

TDQS

C2.6/5.0

Behavior1/5

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

No annotations provided, and the description does not disclose behavioral traits such as idempotency, permission requirements, or side effects. It merely states the action without any constraints or consequences.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence, which is concise but lacks structure. It is front-loaded with purpose, but its brevity sacrifices completeness.

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

Completeness2/5

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

For a creation tool with no output schema, no annotations, and 4 parameters, the description does not provide enough context about return values, error conditions, or dependencies. It is insufficient for an AI agent to fully understand the tool's behavior.

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 the schema already describes parameters. The description adds no meaningful detail beyond 'with rules,' which is already in the schema description for the rules parameter. Baseline 3 applies.

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?

The description clearly states the action (create), the resource (policy), and the scope (with rules). It distinguishes from sibling tools like update_policy or delete_policy.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like agentgate_update_policy or prerequisites for creation. The description implies basic usage but lacks explicit context.

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

agentgate_decideA

Approve or deny a pending request. Use when you are the designated approver.

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Request ID
`reason`	No	Reason for decision (optional)
`decision`	Yes	Your decision
`decidedBy`	No	Who is making this decision (default: "mcp:user")

TDQS

A3.7/5.0

Behavior2/5

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

No annotations are provided, and the description does not disclose behavioral traits such as destructive nature, authorization requirements, or side effects. It only states the action without additional context on what changes occur or prerequisites needed.

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 with two sentences, front-loaded with the primary action and usage condition. Every sentence is necessary and no redundant information.

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?

With no output schema and minimal behavioral clues, the description lacks completeness about return values, error states, or prerequisites (e.g., the request must exist and be pending). The parameter details are well-covered by the schema, but the overall context for a decision action is only partially addressed.

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 description coverage is 100%, so the descriptions already define each parameter. The tool description adds minimal extra meaning beyond restating the purpose; no additional syntax or format details are provided.

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 action (approve or deny) and the resource (pending request). Distinguishes from siblings by specifying 'Use when you are the designated approver,' which sets it apart from request creation tools like agentgate_request.

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 says when to use it ('Use when you are the designated approver'), providing clear context. However, it does not specify when not to use or mention alternatives, though the sibling list offers some contrast.

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

agentgate_delete_policyB

Delete a policy by ID.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Policy ID

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description must fully disclose behavior. It only states 'delete', implying destructiveness, but omits details on reversibility, cascading effects, permissions, or error conditions.

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?

The description is a single, front-loaded sentence with no unnecessary words, making it highly concise and easy to parse.

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?

While the tool is simple (one parameter, no output schema), the description lacks behavioral context such as whether deletion is permanent or what happens on success/failure, making it marginally adequate.

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%, with the 'id' parameter already described as 'Policy ID'. The tool description adds no extra meaning beyond what the input schema provides, so baseline score of 3 is appropriate.

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 'Delete a policy by ID' clearly states the verb (delete) and resource (policy) with a specific identifier, distinguishing it from sibling tools like agentgate_create_policy or agentgate_list.

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

Usage Guidelines2/5

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

No context is provided about when to use this tool versus alternatives, no prerequisites or conditions for deletion, nor any exclusion criteria. The agent must infer usage solely from the tool name and description.

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

agentgate_getB

Get the current status of an approval request by ID.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	Request ID

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of disclosing behavioral traits like read versus write, permissions, rate limits, or side effects. The description only states it retrieves status, but does not clarify if the call is idempotent, what happens if the ID doesn't exist, or any authentication requirements. This is insufficient for a tool with no annotation support.

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?

The description is a single sentence that is front-loaded with the core action and resource. There is no extraneous text, and every word contributes to understanding the tool's purpose.

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

Completeness2/5

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

Given the tool has a single parameter, no output schema, and no annotations, the description is too minimal. It does not explain what 'status' means, what the response looks like, or any error conditions. For a retrieval tool, return value context is critical, and this is missing.

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?

The input schema has 100% coverage with a single parameter 'id' described as 'Request ID'. The description adds no additional semantics beyond what the schema provides—it does not explain the format or source of the ID. Baseline score of 3 is appropriate since schema already documents the parameter.

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 'Get the current status of an approval request by ID' uses a specific verb ('Get') and resource ('status of an approval request'), clearly distinguishing it from sibling tools like agentgate_list (which likely lists requests) and agentgate_request (which likely creates a request). The scope is well-defined.

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

Usage Guidelines3/5

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

The description does not explicitly state when to use this tool versus alternatives. While the verb 'Get' implies retrieval of a single item, there is no guidance on when to use agentgate_list over this, or what prerequisites exist (e.g., request must exist). The context is implied but not explicit.

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

agentgate_get_audit_actorsB

Get unique actor values from audit logs.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior3/5

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

No annotations are provided, so the description must fully disclose behavioral traits. It indicates a read-like operation (getting values) but does not mention side effects, idempotency, or permission requirements. For a simple query tool with no parameters, this is minimally adequate but lacks depth.

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?

The description is extremely concise at six words, with no superfluous information. It is front-loaded and every word adds value. Given the tool's simplicity, this level of conciseness is ideal.

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?

The description is short and covers the basic function, but it does not describe the return format or any pagination behavior. Since there is no output schema, more context about the output (e.g., an array of strings) would improve completeness. However, for a simple tool with no parameters, it is partially adequate.

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?

The input schema has no parameters, and schema description coverage is 100%. The description adds no parameter information, which is unnecessary. The baseline for zero-parameter tools is 4, as the description doesn't need to add meaning beyond the schema.

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?

The description clearly states the tool's purpose: to retrieve unique actor values from audit logs. It uses a specific verb ('Get') and resource ('unique actor values'). However, it does not explicitly distinguish itself from sibling tools like 'agentgate_list_audit_logs', which might also return actor information.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. For example, it's unclear if 'agentgate_list_audit_logs' could also provide actor data or how they differ. No when-to-use or when-not-to-use conditions are mentioned.

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

agentgate_listA

List approval requests with optional filters.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max results (default 10)
`status`	No	Filter by status

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are provided, and the description only states a basic list operation with filters, lacking details on behavior like ordering, pagination, or side effects.

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?

The description is a single sentence that is concise and front-loaded with the key purpose and optional filters.

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?

Given no output schema and simple parameters, the description omits details like default ordering, pagination, or return fields, which would be useful for a list 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%, and the description adds no extra meaning beyond what the schema already provides for status and limit 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 tool lists approval requests with optional filters, distinguishing it from sibling tools like agentgate_list_audit_logs and agentgate_list_policies.

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

Usage Guidelines3/5

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

The description mentions optional filters but provides no guidance on when to use this tool versus alternatives or any prerequisites.

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

agentgate_list_audit_logsB

List audit log entries with optional filters and pagination.

ParametersJSON Schema

Name	Required	Description
`to`	No	End date (ISO format)
`from`	No	Start date (ISO format)
`actor`	No	Filter by actor
`limit`	No	Max results (default 50, max 100)
`action`	No	Filter by action
`offset`	No	Offset for pagination
`status`	No	Filter by status
`eventType`	No	Filter by event type
`requestId`	No	Filter by request ID

TDQS

B3.2/5.0

Behavior2/5

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

With no annotations, the description must fully disclose behavioral traits. It only states the tool lists entries with filters and pagination, omitting details like default limit (50), max limit (100), sorting behavior, or timezone handling.

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?

A single sentence with no wasted words. It efficiently conveys the core action and key features (filters, pagination).

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

Completeness2/5

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

Despite simple functionality, the description lacks context on pagination mechanics, date range handling, authentication requirements, and connection to sibling tools. No output schema further reduces completeness.

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% with all parameters described. The description adds no extra meaning beyond summarizing 'optional filters and pagination,' so baseline score of 3 is appropriate.

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 lists audit log entries with optional filters and pagination, distinguishing it from sibling tools that create policies, decide, delete, get single items, etc.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives like agentgate_get for a single entry or agentgate_list for generic listing. The description implies usage for filtered/paginated listings but does not specify exclusions.

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

agentgate_list_policiesA

List all policies ordered by priority.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic function but omits details about permissions, rate limits, return format, or ordering direction (ascending/descending).

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?

The description is a single, concise sentence that effectively communicates the tool's purpose with no unnecessary words.

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?

While the description is adequate for a simple list tool, it lacks details on return format, ordering direction, and potential limitations. Given no output schema, more context could be beneficial.

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?

The input schema has no parameters (100% coverage baseline 4). The description adds value by confirming no parameters are needed and specifying that all policies are returned ordered by priority.

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 action (List), the resource (policies), and a specific detail (ordered by priority). This distinguishes it from sibling tools like agentgate_list and agentgate_list_audit_logs.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives, such as agentgate_list or agentgate_list_audit_logs. The description lacks any usage context or exclusions.

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

agentgate_requestC

Submit an approval request. Returns request ID and initial status.

ParametersJSON Schema

Name	Required	Description
`action`	Yes	Action being requested (e.g., "send_email", "make_purchase")
`params`	No	Action parameters (e.g., { to: "user@example.com", subject: "..." })
`context`	No	Additional context for the approver
`urgency`	No	Request urgency

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are present, and the description omits behavioral details such as whether the operation is idempotent, what side effects occur, or permission requirements. The only added context is that it returns a request ID and status.

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 very concise with two sentences, both front-loaded with essential information. No extraneous content, though it could be slightly expanded without harming conciseness.

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

Completeness2/5

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

Given the absence of annotations and output schema, the description lacks completeness. It does not explain the approval workflow, how the request is processed, or how this fits with sibling tools. For a tool with four parameters and nested objects, more context is needed.

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 the schema already describes each parameter. The description does not add any additional meaning or constraints beyond the schema, meeting the baseline expectation.

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?

The description clearly states the tool submits an approval request and specifies the return value (request ID and initial status). However, it does not distinguish itself from siblings like agentgate_decide or agentgate_create_policy, which could also involve approval workflows.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusion criteria for using agentgate_request.

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

agentgate_update_policyC

Replace an existing policy (all fields required).

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Policy ID
`name`	Yes	Policy name
`rules`	Yes	Array of policy rules
`enabled`	No	Whether policy is enabled
`priority`	No	Policy priority

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are provided, so the description must carry full behavioral disclosure. It only says 'Replace' without explaining side effects (e.g., whether it overwrites all fields, what happens to unspecified optional fields, or authorization requirements). This is insufficient for a mutation operation.

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 a single sentence that is front-loaded with the verb and resource. It is concise, though the content is incomplete; every word serves a purpose, but critical details are missing.

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

Completeness2/5

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

Given the lack of output schema, no annotations, and 5 parameters including required and optional ones, the description fails to provide sufficient context. It does not explain the return value, error conditions, or the effect on existing policy data, making it incomplete for an agent to reliably use.

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

Parameters1/5

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

The input schema covers all 5 parameters with descriptions, achieving 100% schema coverage. However, the description claims 'all fields required' while the schema marks only id, name, and rules as required; priority and enabled are optional. This contradiction misleads the agent about parameter requirements.

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?

The description clearly states 'Replace an existing policy', indicating the action and resource. It distinguishes this from sibling tools like 'agentgate_create_policy' or 'agentgate_delete_policy', though it could be more explicit about it being a full replacement.

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

Usage Guidelines3/5

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

The description notes 'all fields required', which provides usage guidance that the operation expects a complete definition. However, it does not specify when to use this tool versus alternatives like creating or partially updating, nor does it mention any prerequisites or context.

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. Dates show when Glama detected each change.

10 tool updatesv1.0.0Jun 24, 2026
- First observedagentgate_create_policy
- First observedagentgate_decide
- First observedagentgate_delete_policy
- First observedagentgate_get
- First observedagentgate_get_audit_actors
- First observedagentgate_list
- First observedagentgate_list_audit_logs
- First observedagentgate_list_policies
- First observedagentgate_request
- First observedagentgate_update_policy

Install Server

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

TDQS

A3.5/5.0

Disambiguation5/5

Each tool targets a distinct operation: policy CRUD, request submission, decision, status retrieval, and auditing. No two tools overlap in purpose, making it clear which tool to use for each action.

Naming Consistency4/5

All tools share the 'agentgate_' prefix and most follow a verb_noun pattern (e.g., create_policy, list_policies). However, 'decide' and 'request' lack an explicit object, and 'get' and 'list' are generic without the object in the name, causing slight inconsistency.

Tool Count5/5

With 10 tools covering policy management, request handling, and auditing, the count is well-scoped for the domain. Each tool serves a clear purpose without redundancy.

Completeness5/5

The tool set provides full CRUD for policies, complete lifecycle for approval requests (submit, list, view, decide), and audit capabilities. No obvious gaps in the core approval workflow.

Maintenance

ActivitySlowing

ResponsivenessResponsive

Resources

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

agentlock
io.github.Olum289
Security gateway for AI agents: policy, approval, and audited execution, no secrets shared.
Security Agent Orchestration
2
IdentArk Gateway
io.identark
Zero-secret MCP gateway for AI agents: risk-scored, audited calls with human-in-the-loop approval.
Security Agent Orchestration
29
AxioRank: Zero-Trust for AI Agents A
com.axiorank
Zero-trust gateway for AI agents: score tool calls, verify agent cards, enforce policy, audit.
Security Observability
222
acp-mcp-serverOAuth
com.agenticcontrolplane
See, price, and control every tool call your AI agents make: policy checks, cost, and audit tools.
Agent Orchestration Monitoring Security
1

Related MCP Servers

aegis
Agent Orchestration Autonomous Agents Security
Acacian
A
license
A
quality
A
maintenance
Policy-based governance for AI agent tool calls. YAML policies, approval gates, risk assessment, and audit logging across LangChain, OpenAI, Anthropic, and MCP.
Updated 8 days ago (2026-08-29 14:36 UTC)
5
15
MIT
agent-sudo-mcp
Security Autonomous Agents
Kisyntra
A
license
A
quality
A
maintenance
Local zero-trust permission gateway for AI agents. Enforces policy-based tool authorization, human approvals, scoped permissions, and cryptographically verifiable audit logs.
Updated a month ago (2026-08-10 11:23 UTC)
4
5
Apache 2.0
Impri
Agent Orchestration Communication
sekera-radim
A
license
A
quality
C
maintenance
Human-in-the-loop approval inbox for AI agents: an agent proposes an action (send email, post comment, run a command), a human approves, rejects, or edits it from a web, mobile, or Slack/Discord/Telegram inbox, and the agent only runs on approval. Full audit trail, self-hostable (MIT).
Updated a day ago (2026-09-05 06:20 UTC)
8
2
MIT
permitd MCP Server
Security Autonomous Agents
hbar-systems
A
license
Not graded
quality
C
maintenance
Gates agent tool execution with human approval, audit trails, and replay-resistant permits, enabling safe use of tools in agent loops.
Updated a month ago (2026-07-30 20:12 UTC)
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/agentkitai/agentgate'

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

✨ Highlights

Quickstart

Dashboard

Approval Requests

Audit Log

Request Detail

API Keys

Webhooks

Login

Table of Contents

Quick Start

1. Install dependencies

2. Run database migrations

3. Bootstrap (create admin API key)

4. Start the development environment

5. Run the demo

6. Open the dashboard

Architecture

Packages

SDK Usage

CLI

Installation

Configuration

Commands

Examples

MCP Integration

Claude Desktop Configuration

Available MCP Tools

Authentication

API Key Scopes

Using API Keys

Creating Additional API Keys

API Endpoints

Rate Limiting

How It Works

Rate Limit Headers

Configuring Rate Limits

Dashboard

Webhooks

Setting Up Webhooks

Webhook Events

Webhook Payload

Webhook Signatures

Webhook Retry

Configuration

Environment Variables

File-Based Secrets (_FILE suffix)

Policy Configuration

Docker Deployment

Quick Start

Services

With Slack or Discord Bots

Configuration

Building Images

Database Migrations

Viewing Logs

Stopping Services

Production Considerations

Development

Testing

Code Quality

Project Structure

Contributing

🧰 AgentKit Ecosystem

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

File-Based Secrets (`_FILE` suffix)