JamJet

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.8.5
Disambiguation5/5
Each 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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 4.7/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 1 of 1 community issues answered or closed in the last 6 months
- 137 commits in the last 12 weeks
- Last stable release on June 29, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds 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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). Description adds 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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness4/5
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.
Completeness5/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, 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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds 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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![jamjet MCP server](https://glama.ai/mcp/servers/jamjet-labs/jamjet/badges/card.svg)](https://glama.ai/mcp/servers/jamjet-labs/jamjet)

Score Badge

Copy to your README.md:

[![jamjet MCP server](https://glama.ai/mcp/servers/jamjet-labs/jamjet/badges/score.svg)](https://glama.ai/mcp/servers/jamjet-labs/jamjet)

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/jamjet-labs/jamjet'

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