The JamJet server provides a comprehensive management interface for agent-native workflow runtimes, enabling you to run, monitor, and control durable AI agent workflows and multi-agent systems.
Run Workflows (jamjet_run_workflow): Start a workflow execution with input data, workflow ID, and optional version parameters
Monitor Executions (jamjet_get_execution, jamjet_list_executions): Retrieve execution status/details and browse paginated execution history with filtering by status (running, paused, completed, failed)
Get Event Logs (jamjet_get_events): Retrieve the full event timeline/audit log for any execution, supporting observability and replay
Cancel Executions (jamjet_cancel_execution): Terminate running workflow executions
Human-in-the-Loop (jamjet_approve): Approve or reject paused executions waiting for human intervention, with an optional comment
List Agents (jamjet_list_agents): Browse registered agents with filtering by skill, status, or protocol
Discover Remote Agents (jamjet_discover_agent): Register new remote agents into the JamJet registry by URL, enabling dynamic agent discovery and routing
Multi-tenancy: All operations support tenant isolation via tenant_id parameters
Enables integrating Brave Search as an MCP tool within agent workflows to provide web search and information retrieval capabilities.
The action-control plane for AI agents. One policy file. One audit trail. Across hooks, guardrails, MCP gateways, SDKs, and custom runtimes.
jamjet.dev · Quickstart · Docs · Examples · Blog · Discord
Write the safety policy once. Run it everywhere your agents can act.
JamJet sits underneath your agent (Claude Code, OpenAI Agents SDK, MCP clients, LangChain, CrewAI, ADK, Spring AI, custom code) and enforces what prompts cannot:
🛡️ Block unsafe tool calls at runtime: database deletes, payments, file writes
✋ Pause for human approval on risky actions, durably
💸 Cap cost per agent, per run, per project
📒 Record an audit trail that survives a regulator's review
⏪ Replay or resume crashed runs from the last checkpoint
Keep your agent framework. Add JamJet where tool calls need control.
pip install jamjet
jamjet demo unsafe-tool-callNo API key. No Docker. No cloud account. The model is mocked; the enforcement path is real. Three more demos run the same way:
jamjet demo approval # pause-for-approval flow
jamjet demo budget-cap # $0.05 cost cap
jamjet demo mcp-tool-policy # MCP-shaped policy (preview of JamJet Gateway)Works alongside Claude Code · OpenAI Agents SDK · MCP clients · LangChain · CrewAI · ADK · Spring AI · LangChain4j.
Related MCP server: task-orchestrator
Spring AI and LangChain4j teams get the same layer without writing glue code. The Spring Boot starter auto-injects JamJet advisors into your ChatClient: every call becomes durable and audited, with no changes to your application code.
<dependency>
<groupId>dev.jamjet</groupId>
<artifactId>jamjet-spring-boot-starter</artifactId>
<version>0.1.0</version>
</dependency>spring.jamjet.runtime-url=http://localhost:7700
spring.jamjet.approval.enabled=true # opt-in human-in-the-loop approvalCrash recovery, event sourcing, and a REST endpoint to approve or reject held actions. Falls back gracefully if the runtime is unreachable.
Prefer no sidecar at all? JamJet Java Runtime embeds durable execution directly in your JVM process: Java 21, no Docker, 8.9× faster than calling out to a REST sidecar (benchmark and launch post). Works with Spring AI, LangChain4j, and Google ADK.
→ See a Spring Boot agent survive kill -9 mid-run in examples/loan-underwriter-agent: resumes from disk checkpoints, gates disbursement on human approval, emits a signed receipt bundle.
Every agent toolchain is inventing its own safety layer. JamJet gives you one policy file and one audit trail across all of them.
Adapter | Install | Host |
| Claude Code PreToolUse hook | |
| Any MCP client (Claude Desktop, Cursor, …) | |
| OpenAI Agents SDK tool guardrail (TS) | |
| OpenAI Agents SDK tool guardrail (Python) | |
| Python SDK + runtime | |
Maven / Gradle | Spring AI ChatClient advisors | |
| TypeScript SDK + shared engine | |
| Unified |
All adapters load the same policy.yaml. All emit conformant audit JSONL to ~/.jamjet/audit/. Run jamjet audit show to tail every decision across every adapter in one chronological view.
JamJet does not replace the hook points these platforms give you. It makes them do more: Claude Code's PreToolUse hook gets a real policy engine, approval flow, and audit trail, and the same rules carry unchanged to OpenAI Agents SDK, MCP clients, Spring AI, and your own Python or TypeScript code.
# ~/.jamjet/policy.yaml
version: 1
rules:
- { match: "*delete*", action: block }
- { match: "payments.*", action: require_approval }
- { match: "shell.exec", action: block }Drop this file in ~/.jamjet/. Every adapter listed above uses it automatically.
Prompts are not a security boundary. The runtime is.
→ Read When AI Deletes the Database for why this is a runtime architecture problem, not a model problem. → See the deeper durability demo at jamjet.dev/demo for what happens when an agent crashes mid-tool-call.
Drop a policy beside your agent code. The runtime intercepts any matching tool call before it leaves the agent's process: blocked_tools are refused outright, require_approval_for pauses execution durably and waits for an out-of-band decision. Crashes don't lose the approval; execution resumes when it arrives.
# workflow.yaml
policy:
blocked_tools:
- "*delete*"
- "payments.refund"
require_approval_for:
- "database.*"
- "payment.transfer"
- "user.suspend"Python, with the hosted control plane:
import jamjet
jamjet.cloud.configure(api_key="jj_...", project="my-agent")
jamjet.cloud.policy("block", "*delete*")
jamjet.cloud.policy("require_approval", "database.*")
# Every OpenAI / Anthropic call in this process is now policy-gated.→ Runnable approval workflow in examples/hitl-approval · Cloud Quickstart
Your Agent / Framework
(LangChain · CrewAI · ADK · custom · MCP client)
│
▼
┌───────────────────────────────────────────────┐
│ JamJet Safety Layer │
│ policy · approval · budget · audit · replay │
└───────────────────────────────────────────────┘
│
▼
Tools · MCP servers · APIs · DBs · Agentscall MCP servers or arbitrary tools
write to a database
send emails or Slack messages
trigger payments or external API calls
access customer data or PII
run for minutes/hours and needs to survive crashes
spend real model budget at scale
delegate to other agents
Without JamJet | With JamJet |
Agent crashes lose progress | Resume from the last checkpoint |
Tool calls rely on scattered app logic | Runtime policy blocks unsafe actions |
Human approval is custom glue | Approval is a durable workflow step |
Costs are discovered after the bill | Budgets enforced per agent / per run |
Audit evidence is stitched from logs | Append-only event log, signed export |
Memory is framework-specific | Pair with Engram for portable memory (MCP · REST · Python · Java) |
Frameworks stay siloed | MCP + A2A connect tools and agents |
The safety layer runs on a durable, event-sourced execution engine. When you want more than enforcement, it's already there:
Durable execution. Event log, snapshots, crash recovery, deterministic replay. agent.run_durable(...) in examples/react-agent-durable.
Sessions and memory. Persistent Session threads across runs and restarts, with a governed Engram retrieve/record loop. examples/session-memory.
Multi-agent. Sequential, Parallel, coordinator Team, and Loop; each sub-agent runs as its own governed durable execution. examples/team-multi-agent. Declare whole fleets in YAML with cron schedules: examples/fleet.
Evaluation. Batch eval with LLM-judge scoring (examples/eval-harness) and trajectory regression diffs (examples/trajectory-eval).
Deploy. agent.deploy(runtime="local" | "self-host" | "cloud") ships the same compiled IR to any runtime. examples/deploy-an-agent.
Dev loop. jamjet create scaffolds a project; jamjet dev runs the whole local stack with one command.
Web Companion. A UI embedded in the runtime binary: graph view, timeline, state inspector, replay and fork controls.
JamJet does not replace LangChain, LangGraph, CrewAI, Google ADK, Spring AI, or your custom agent code. Use those to build agent behavior. Use JamJet to control what happens at runtime.
You're using | Keep it for | JamJet adds |
LangChain · LangGraph · CrewAI · Google ADK · AutoGen | Authoring agent behavior | Runtime safety: policy, audit, replay, approvals |
LangSmith · Arize · Weights & Biases | Observability and evaluation | Active enforcement (block at runtime) + durable recovery |
Temporal · Orkes · DBOS | General durable workflows | Agent-native primitives: policy on tool calls, MCP/A2A, memory |
Google · AWS · Azure agent platforms | Cloud-native ecosystems | Open-source, cloud-neutral governance that works on-prem |
Want to build the official integration for your framework? Claim a slot: 8 slots open, the first 10 merged contributors get JamJet swag.
Example | What it shows |
A destructive tool call blocked before execution | |
Human approval as a first-class workflow primitive | |
A ReAct agent on the durable engine: event log, replay, park-on-429 | |
Multi-agent Teams, each sub-agent its own governed run | |
Spring Boot agent that survives | |
Insurance pipeline: 4 specialist agents + HITL + audit | |
Batch evaluation with LLM judge scoring |
Engram is the JamJet ecosystem's memory layer for agents. Where JamJet provides durable execution (process can crash and resume), Engram provides durable memory (facts persist across runs and version cleanly via supersede()). Temporal knowledge graph, hybrid retrieval, conflict detection. Ships as a Rust crate (also bundled into the Rust runtime above), an MCP server (Docker · GHCR), a standalone Python library (github.com/jamjet-labs/engram, 71% on LongMemEval-S), a Python client for the MCP server, and a Spring AI ChatMemoryRepository. Comparison with Mem0/Zep → java-ai-memory.dev.
┌──────────────────────────────────────────────────────────┐
│ Authoring Layer │
│ Python SDK | Java SDK | TypeScript SDK | YAML │
├──────────────────────────────────────────────────────────┤
│ Compilation / Validation │
│ Graph IR | Schema | Policy lint │
├────────────────────────────┬─────────────────────────────┤
│ Rust Runtime Core │ Protocol Layer │
│ Scheduler | State SM │ MCP Client | MCP Server │
│ Event log | Snapshots │ A2A Client | A2A Server │
│ Workers | Timers │ │
├────────────────────────────┴─────────────────────────────┤
│ Enterprise Services │
│ Policy | Audit | PII Redaction | OAuth | mTLS │
├──────────────────────────────────────────────────────────┤
│ Runtime Services │
│ Model Adapters | Tool Execution | Engram Memory │
├──────────────────────────────────────────────────────────┤
│ Storage │
│ Postgres (production) | SQLite (local) │
└──────────────────────────────────────────────────────────┘"Engram Memory" here is the in-process distribution bundled with the Rust runtime. Engram also ships standalone; see Engram.
Full docs at jamjet.dev
Quickstart · Concepts · Python SDK · Java SDK · YAML Workflows · REST API · MCP · A2A · Eval · Enterprise · Observability · CLI · Deployment
Contributions welcome. See CONTRIBUTING.md.
Looking for a starter task?
Build a framework integration: 8 slots open, first 10 contributors get JamJet swag
Browse good first issues
Join the conversation in Discord
GitHub Discussions · Issues · Discord
Apache 2.0. See LICENSE.
Hosted control plane available at app.jamjet.dev: traces, approval queue, audit retention, team projects. Optional. The runtime, all SDKs, and Engram are Apache-2.0 with no usage limits.
Built by Sunil Prakash · © 2026 JamJet Labs · jamjet.dev · Apache 2.0
Submit an approval or rejection decision for a workflow execution that is paused and waiting for human review. Use this when jamjet_list_executions shows a 'paused' execution or jamjet_get_events shows an ApprovalRequested event. Side effects: appends an ApprovalReceived event to the event log (with user_id 'mcp-client') and, if the execution is paused, resumes it to 'running' status so the next node can proceed. The decision is recorded in the immutable audit trail. Returns a JSON object with execution_id and accepted: true. Fails if execution_id is not found, if decision is not exactly 'approved' or 'rejected', or if nothing is pending approval (or node_id does not match a pending approval). Related: use jamjet_get_events to see the ApprovalRequested event details before deciding.
| Name | Required | Description | Default |
|---|---|---|---|
| comment | No | Optional free-text comment explaining the decision. Recorded in the audit trail alongside the approval event. | |
| node_id | No | ID of the node that requested approval. Helps correlate the decision with the correct approval gate when a workflow has multiple. | |
| decision | Yes | The approval decision. Must be exactly 'approved' or 'rejected'. 'approved' resumes the workflow; 'rejected' records the rejection. | |
| tenant_id | No | Tenant partition. Defaults to 'default'. Must match the tenant used when the execution was created. | |
| execution_id | Yes | Execution ID of the paused workflow awaiting approval. Accepts 'exec_<uuid>' or bare UUID format. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully discloses side effects: appends ApprovalReceived event, resumes execution if paused, records decision in audit trail. Also details return value and failure conditions, exceeding typical transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is well-structured, front-loading purpose then side effects and failures. Every sentence adds value, though slightly verbose; could be more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, description details return format (JSON with execution_id and accepted: true) and covers failure cases. With 5 parameters all documented in schema and contextual usage guidance, the description is fully complete for agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 value by explaining that decision must be exact, comment optional, node_id correlates, tenant_id defaults, execution_id accepts formats. This extra context justifies above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool submits an approval or rejection decision for a paused workflow execution. It uses specific verb 'submit' and resource description, and distinguishes from siblings by referencing related tools like jamjet_list_executions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use: when jamjet_list_executions shows 'paused' or jamjet_get_events shows ApprovalRequested. Provides context on related tools, though lacks explicit when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel a running or paused workflow execution. This is an irreversible, destructive operation. Side effects: appends a WorkflowCancelled event to the execution's event log and sets the status to 'cancelled'. The execution cannot be resumed after cancellation — start a new execution with jamjet_run_workflow if needed. Use this when a workflow is stuck, no longer needed, or was started with incorrect input. Returns a JSON object with execution_id and status 'cancelled'. Fails if the execution is already in a terminal state (completed, failed, or cancelled) or if the execution_id is not found.
| Name | Required | Description | Default |
|---|---|---|---|
| tenant_id | No | Tenant partition. Defaults to 'default'. Must match the tenant used when the execution was created. | |
| execution_id | Yes | Execution ID to cancel. Accepts 'exec_<uuid>' or bare UUID format. The execution must be in 'running' or 'paused' state. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description fully carries the burden. Clearly labels it as 'irreversible, destructive operation', lists side effects (appends event, sets status), states it cannot be resumed, and describes return value and failure conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph but well-structured, covering all critical information without unnecessary words. Could be slightly improved with bullet points, but still concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are 2 parameters and no output schema, the description covers side effects, return value, failure cases, usage context, and even mentions a sibling tool. Very complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions, so baseline is 3. The description adds extra context for execution_id (format acceptance, state requirement) and tenant_id (default, must match), surpassing baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action ('Cancel') and the resource ('workflow execution'). Distinguishes from siblings by mentioning that to resume, use jamjet_run_workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use it: when a workflow is stuck, no longer needed, or started with incorrect input. Also describes when it fails, implying not to use on already terminal executions. Provides an alternative (jamjet_run_workflow).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Discover and register a remote agent by fetching its Agent Card from the given URL. Side effects: makes an outbound HTTP request to the URL to retrieve the agent's metadata (Agent Card), then registers the agent in the local runtime registry so it becomes available for routing and invocation. Use this to onboard external agents (A2A, MCP, or REST) before they can appear in jamjet_list_agents or be routed to by a Coordinator. Returns the full JSON Agent Card of the newly registered agent, including its ID, name, skills, protocol, and endpoint. Fails if the URL is unreachable, does not serve a valid Agent Card, or if a network error occurs. This operation is idempotent — discovering the same URL again updates the existing registration.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | HTTPS URL of the remote agent to discover. The agent must serve an Agent Card (A2A/.well-known/agent.json or equivalent metadata endpoint). Example: 'https://agents.example.com/research-agent'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses side effects (outbound HTTP request), idempotency, and failure modes, exceeding the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each serving a purpose: main action, side effect, usage context, failure conditions. Slightly verbose but well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, no output schema, the description covers return value, idempotency, and error cases, making it fully informative for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, and the description adds format (HTTPS), content requirement (Agent Card), and an example, providing value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the action (discover and register), the resource (remote agent via URL), and distinguishes from siblings like jamjet_list_agents by stating this is a prerequisite for listing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (onboard external agents before listing or routing) and failure conditions, but no explicit when-not or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the full, ordered event log for a workflow execution. Read-only, no side effects. Use this to debug execution behavior, understand which nodes ran and in what order, or inspect approval decisions. Returns a JSON object with an 'events' array. Each event has: execution_id, sequence (monotonic counter), timestamp, and kind (one of: WorkflowStarted, NodeScheduled, NodeStarted, NodeCompleted, NodeFailed, ApprovalRequested, ApprovalReceived, WorkflowCompleted, WorkflowCancelled, WorkflowFailed). Events are returned in sequence order (oldest first) and represent the complete, immutable audit trail. For a high-level status summary, use jamjet_get_execution instead.
| Name | Required | Description | Default |
|---|---|---|---|
| tenant_id | No | Tenant partition to query. Defaults to 'default'. Must match the tenant used when the execution was created. | |
| execution_id | Yes | Execution ID to retrieve events for. Accepts 'exec_<uuid>' or bare UUID format. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the burden. It declares read-only, no side effects, returns an immutable audit trail in sequence order (oldest first). It details each event's fields and the enumeration of possible 'kind' values, providing comprehensive behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy but each sentence serves a purpose. It is front-loaded with the core function, then usage guidance, then output structure, then alternative tool. While efficient, a slight reduction in detail (e.g., the full kind enum) could maintain clarity while being more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description must explain return values. It thoroughly describes the return type (JSON object with 'events' array) and each event's fields, including the allowed values for 'kind'). It also clarifies ordering and immutability. For a debug tool, this is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes both parameters with 100% coverage. The description adds extra value by specifying the accepted format for execution_id ('exec_<uuid>' or bare UUID) and noting the tenant_id default and requirement to match the execution's tenant, which clarifies proper usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the full, ordered event log for a workflow execution. It specifies it is read-only with no side effects, and distinguishes itself from sibling jamjet_get_execution (which provides a high-level status summary), using specific verbs and resource identification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool: 'to debug execution behavior, understand which nodes ran and in what order, or inspect approval decisions.' It also directly provides an alternative: 'For a high-level status summary, use jamjet_get_execution instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the full details of a single workflow execution. Read-only, no side effects. Use this to check an execution's current status, inspect its state, or confirm completion after running jamjet_run_workflow. Returns a JSON object with: execution_id, workflow_id, workflow_version, status (one of: running, paused, completed, failed, cancelled), initial_input, current_state, started_at, updated_at, and completed_at (null if still running). Fails with 'execution not found' if the ID does not exist in the specified tenant. For the full event history, use jamjet_get_events instead.
| Name | Required | Description | Default |
|---|---|---|---|
| tenant_id | No | Tenant partition to query. Defaults to 'default'. Must match the tenant used when the execution was created. | |
| execution_id | Yes | Execution ID returned by jamjet_run_workflow. Accepts either 'exec_<uuid>' or bare UUID format. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully covers behavioral traits: read-only, no side effects, failure case ('execution not found'), ID format requirements, tenant constraints, and return field descriptions including status enum.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Five concise sentences with front-loaded purpose, no redundant phrases. Every sentence provides necessary context: purpose, usage, response structure, error handling, alternative tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given simple parameters and no output schema, description is complete: covers return fields, status enum, error condition, and directs to alternative tool for events. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 value by specifying acceptance of two ID formats, default tenant and matching constraint, though schema already covered basic descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Retrieve the full details of a single workflow execution' with specific verb and resource. Distinguishes from siblings like jamjet_get_events and jamjet_list_executions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use (check status, inspect state, confirm completion after jamjet_run_workflow) and when not (for full event history, use jamjet_get_events).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all agents registered in the runtime, with optional filters by status, skill, or protocol. Read-only, no side effects. Use this to discover which agents are available before routing work, or to check the health/status of registered agents. Returns a JSON object with an 'agents' array. Each entry includes the agent's ID, name, description, skills, protocol, status, and Agent Card metadata. All filter parameters are optional and can be combined — omit all to list every registered agent. Returns an empty array if no agents match the filters. Related: use jamjet_discover_agent to register a new remote agent before listing.
| Name | Required | Description | Default |
|---|---|---|---|
| skill | No | Filter to agents that declare this skill (e.g., 'data-analysis', 'translation'). Matches against the agent's skills list. | |
| status | No | Filter agents by lifecycle status. Allowed values: 'registered' (known but not started), 'active' (running and available), 'paused' (temporarily offline), 'deactivated' (permanently removed). Omit to return all statuses. | |
| protocol | No | Filter to agents using this protocol (e.g., 'a2a', 'mcp', 'rest'). Useful for finding agents reachable via a specific communication method. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Explicitly states 'Read-only, no side effects' and describes the return format in detail (JSON with agents array and fields). Covers edge case of empty array. No annotations to contradict.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with front-loaded purpose and safety. Some redundancy but every sentence adds value. Could be slightly more concise but still effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description thoroughly covers return format, safety, use cases, filtering, edge case (empty array), and related tool. Complete for a list tool with 3 optional params.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers descriptions for all 3 parameters. Description adds value by explaining filters are optional and combinable, and that omitting all lists everything. Reinforces usage beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists all registered agents with optional filters. Differentiates from sibling 'jamjet_discover_agent' by mentioning its registration purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete use cases: discovering agents before routing work or checking health/status. Explains filters are optional and combinable. Lacks explicit 'when not to use' but still strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List workflow executions with optional status filtering and pagination. Read-only, no side effects. Use this to find executions that need attention — for example, filter by 'paused' to find executions awaiting approval via jamjet_approve, or filter by 'running' to monitor active workflows. Returns a JSON object with an 'executions' array, where each entry has the same fields as jamjet_get_execution. Results are ordered by creation time (newest first). Supports offset-based pagination via limit and offset parameters. All parameters are optional — calling with no arguments returns the 50 most recent executions across all statuses.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of executions to return. Defaults to 50. Use with offset for pagination through large result sets. | |
| offset | No | Number of executions to skip before returning results. Defaults to 0. Combine with limit for pagination (e.g., offset=50, limit=50 for page 2). | |
| status | No | Filter to a specific status. Allowed values: 'running', 'paused', 'completed', 'failed'. Omit to return all statuses. | |
| tenant_id | No | Tenant partition to query. Defaults to 'default'. Only executions in this tenant are returned. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only nature, no side effects, ordering by creation time, pagination offset/limit behavior, default limit, and return format referencing jamjet_get_execution. No annotations provided, so description carries full burden and meets it well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Seven sentences, each earning its place: purpose, read-only assertion, usage examples, return format, ordering, pagination, and optionality. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers all essential aspects: what it does, when to use, how it behaves (ordering, pagination), parameter details, return structure. No output schema, but description sufficiently clarifies return format by referencing another tool. Could mention error handling, but not required for basic completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% so baseline 3. Description adds value by stating parameters are optional and giving usage examples (e.g., filter by status). Also explains combined pagination behavior beyond schema's individual descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it lists workflow executions with optional filtering and pagination. Distinguishes from siblings by mentioning usage for finding paused executions (to approve via jamjet_approve) or running ones, implying contrast with single-execution tool jamjet_get_execution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use: to find executions needing attention, e.g., paused for approval or running for monitoring. Implicitly suggests alternatives via mention of jamjet_approve. Does not explicitly state when not to use it (e.g., for single execution), 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.
Start a new durable workflow execution. Use this to kick off a workflow that has already been registered with the runtime. Side effects: creates a new execution record, appends WorkflowStarted and NodeScheduled events to the event log, and enqueues a work item for the first node — the workflow begins processing immediately. Returns a JSON object with the execution_id (format: exec_) that you can pass to jamjet_get_execution, jamjet_get_events, jamjet_cancel_execution, or jamjet_approve. This operation is not reversible — use jamjet_cancel_execution to stop a running workflow. Fails if the workflow_id + version combination is not registered. No authentication required (local-only server).
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Initial state data passed to the workflow's first node. Shape must match the workflow's state_schema. | |
| tenant_id | No | Tenant partition for multi-tenant isolation. Defaults to 'default'. Execution and events are scoped to this tenant. | |
| workflow_id | Yes | ID of a registered workflow to execute. Must match a workflow previously loaded into the runtime. | |
| workflow_version | No | Semantic version of the workflow to run. Defaults to '1.0.0' if omitted. Use when multiple versions are registered. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Lists side effects (creates execution record, appends events, enqueues work item), states it is not reversible, suggests jamjet_cancel_execution to stop, notes authentication (none), and failure condition. Very thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph with well-structured information: purpose first, then side effects, return value, reversible note, failure condition, authentication. No wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description explains return object and execution_id format. Covers side effects, failure conditions, and references sibling tools. Complete for a complex tool starting a durable workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). Description adds context beyond schema: for input, explains it must match state_schema; for tenant_id, adds default and scoping; for workflow_version, adds default value. Adds clarification about execution_id format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Start a new durable workflow execution' with a specific verb and resource. It distinguishes from sibling tools like jamjet_get_execution and jamjet_cancel_execution by specifying the action of kicking off a workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this to kick off a workflow that has already been registered' and lists the returned execution_id for use with other tools. Mentions failure condition if workflow not registered. Could be more explicit about when not to use, but provides good context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.8.2jamjet_approvejamjet_cancel_executionjamjet_discover_agentjamjet_get_eventsjamjet_get_executionjamjet_list_agentsjamjet_list_executionsjamjet_run_workflowv0.8.1jamjet_approvejamjet_cancel_executionjamjet_discover_agentjamjet_get_eventsjamjet_get_executionjamjet_list_agentsjamjet_list_executionsjamjet_run_workflowv0.1.1jamjet_approve6 fields changedInput schema / properties / comment / descriptionPrevious value: -"Optional comment"New value: +"Optional free-text comment explaining the decision. Recorded in the audit trail alongside the approval event."Input schema / properties / decision / descriptionPrevious value: -"approved or rejected"New value: +"The approval decision. Must be exactly 'approved' or 'rejected'. 'approved' resumes the workflow; 'rejected' records the rejection."Input schema / properties / decision / enumAdded value: +[
+ "approved",
+ "rejected"
+]Input schema / properties / execution_id / descriptionPrevious value: -"Execution ID"New value: +"Execution ID of the paused workflow awaiting approval. Accepts 'exec_<uuid>' or bare UUID format."Input schema / properties / node_id / descriptionPrevious value: -"Node that requested approval"New value: +"ID of the node that requested approval. Helps correlate the decision with the correct approval gate when a workflow has multiple."Input schema / properties / tenant_id / descriptionPrevious value: -"Tenant ID (default: default)"New value: +"Tenant partition. Defaults to 'default'. Must match the tenant used when the execution was created."jamjet_cancel_execution2 fields changedInput schema / properties / execution_id / descriptionPrevious value: -"Execution ID"New value: +"Execution ID to cancel. Accepts 'exec_<uuid>' or bare UUID format. The execution must be in 'running' or 'paused' state."Input schema / properties / tenant_id / descriptionPrevious value: -"Tenant ID (default: default)"New value: +"Tenant partition. Defaults to 'default'. Must match the tenant used when the execution was created."jamjet_discover_agent1 field changedInput schema / properties / url / descriptionPrevious value: -"URL of the remote agent to discover"New value: +"HTTPS URL of the remote agent to discover. The agent must serve an Agent Card (A2A/.well-known/agent.json or equivalent metadata endpoint). Example: 'https://agents.example.com/research-agent'."jamjet_get_events2 fields changedInput schema / properties / execution_id / descriptionPrevious value: -"Execution ID"New value: +"Execution ID to retrieve events for. Accepts 'exec_<uuid>' or bare UUID format."Input schema / properties / tenant_id / descriptionPrevious value: -"Tenant ID (default: default)"New value: +"Tenant partition to query. Defaults to 'default'. Must match the tenant used when the execution was created."jamjet_get_execution2 fields changedInput schema / properties / execution_id / descriptionPrevious value: -"Execution ID (exec_<uuid> or bare UUID)"New value: +"Execution ID returned by jamjet_run_workflow. Accepts either 'exec_<uuid>' or bare UUID format."Input schema / properties / tenant_id / descriptionPrevious value: -"Tenant ID (default: default)"New value: +"Tenant partition to query. Defaults to 'default'. Must match the tenant used when the execution was created."jamjet_list_agents4 fields changedInput schema / properties / protocol / descriptionPrevious value: -"Filter by protocol"New value: +"Filter to agents using this protocol (e.g., 'a2a', 'mcp', 'rest'). Useful for finding agents reachable via a specific communication method."Input schema / properties / skill / descriptionPrevious value: -"Filter by skill"New value: +"Filter to agents that declare this skill (e.g., 'data-analysis', 'translation'). Matches against the agent's skills list."Input schema / properties / status / descriptionPrevious value: -"Filter by status: registered, active, paused, deactivated"New value: +"Filter agents by lifecycle status. Allowed values: 'registered' (known but not started), 'active' (running and available), 'paused' (temporarily offline), 'deactivated' (permanently removed). Omit to return all statuses."Input schema / properties / status / enumAdded value: +[
+ "registered",
+ "active",
+ "paused",
+ "deactivated"
+]jamjet_list_executions5 fields changedInput schema / properties / limit / descriptionPrevious value: -"Max results (default 50)"New value: +"Maximum number of executions to return. Defaults to 50. Use with offset for pagination through large result sets."Input schema / properties / offset / descriptionPrevious value: -"Offset for pagination"New value: +"Number of executions to skip before returning results. Defaults to 0. Combine with limit for pagination (e.g., offset=50, limit=50 for page 2)."Input schema / properties / status / descriptionPrevious value: -"Filter by status: running, paused, completed, failed"New value: +"Filter to a specific status. Allowed values: 'running', 'paused', 'completed', 'failed'. Omit to return all statuses."Input schema / properties / status / enumAdded value: +[
+ "running",
+ "paused",
+ "completed",
+ "failed"
+]Input schema / properties / tenant_id / descriptionPrevious value: -"Tenant ID (default: default)"New value: +"Tenant partition to query. Defaults to 'default'. Only executions in this tenant are returned."jamjet_run_workflow4 fields changedInput schema / properties / input / descriptionPrevious value: -"Input data for the workflow"New value: +"Initial state data passed to the workflow's first node. Shape must match the workflow's state_schema."Input schema / properties / tenant_id / descriptionPrevious value: -"Tenant ID (default: default)"New value: +"Tenant partition for multi-tenant isolation. Defaults to 'default'. Execution and events are scoped to this tenant."Input schema / properties / workflow_id / descriptionPrevious value: -"ID of the workflow to run"New value: +"ID of a registered workflow to execute. Must match a workflow previously loaded into the runtime."Input schema / properties / workflow_version / descriptionPrevious value: -"Workflow version (default: 1.0.0)"New value: +"Semantic version of the workflow to run. Defaults to '1.0.0' if omitted. Use when multiple versions are registered."v0.1.0jamjet_approvejamjet_cancel_executionjamjet_discover_agentjamjet_get_eventsjamjet_get_executionjamjet_list_agentsjamjet_list_executionsjamjet_run_workflowEach tool targets a distinct operation: approval decisions, cancellation, agent discovery, event retrieval, execution details, listing agents, listing executions, and starting workflows. No two tools overlap in purpose, and descriptions clearly differentiate them.
All tools use the prefix 'jamjet_' followed by a verb or verb_noun pattern (e.g., jamjet_approve, jamjet_cancel_execution). However, 'jamjet_approve' lacks a noun object, unlike the others, creating a minor inconsistency. Overall, the pattern is clear and easy to follow.
8 tools is well-scoped for a workflow orchestration MCP server. It covers essential operations for both execution lifecycle (run, get, list, cancel, approve, events) and agent management (list, discover) without unnecessary bloat.
The tool set covers core execution lifecycle and agent discovery. However, there is no tool to register or update workflow definitions, and agent management lacks a removal tool. These are minor gaps given the stated domain, as the server may rely on out-of-band registration.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Hosted runtime for persistent agent teams, durable workflows, memory, schedules, and goals.
Agent-native collaboration network: orchestrate a team of long-running agents from any MCP client.
Persistent, inspectable memory for AI agents with lineage, correction, and a hosted MCP endpoint.
MCP server for AI agents to plan, verify, and deploy Cloudflare-native apps.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jamjet-labs/jamjet'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
