klanex-mcp
Server Details
Reliable async execution for agent tool calls: schema-gate hallucinated payloads before they run, absorb rate limits and outages with retries and circuit breakers, and add idempotency, human approval gates, encrypted credentials, and signed-webhook results. Failed calls return an llm_hint the agent can self-correct from.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 6 of 6 tools scored.
Each tool has a clearly distinct purpose: execute for submitting calls, get_execution for checking status, get_usage for quota, list_connections for credentials, list_executions for history, and replay_execution for re-running. No overlap.
Most tools follow verb_noun pattern (get_execution, list_connections, etc.). The 'execute' tool is a verb-only name but still clearly maps to its action. Overall consistent style.
6 tools cover the core workflows of async HTTP execution, monitoring, and credential management. Not too many or too few for the domain.
Covers submit, check, list, replay, quota, and connection listing. Minor gaps: no connection create/update/delete, no cancel for pending executions, but core async execution lifecycle is well-supported.
Available Tools
6 toolsexecuteAInspect
Submit an HTTP call to a third-party API for reliable asynchronous execution. klanex validates the payload (optionally against payload_schema), stores credentials encrypted, executes with automatic retries/backoff/circuit breakers, and keeps an audit trail — you submit once and never retry transient failures yourself.
Call this instead of making a direct HTTP request whenever the call has side effects (payments, messages, tickets, writes) or the target may be flaky. Prefer connection_id over headers for credentials. Always set idempotency_key for side-effecting calls so resubmitting can never double-execute. Set wait_seconds to block for the result; otherwise poll get_execution with the returned execution_id.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | absolute http(s) URL of the target endpoint | |
| method | No | HTTP method: GET, POST, PUT, PATCH, or DELETE (default POST) | |
| headers | No | request headers, typically third-party credentials; encrypted at rest and never readable back. Prefer connection_id so secrets never pass through your context | |
| payload | No | JSON body to send to the target | |
| seal_url | No | set true when the URL itself is a secret (webhook URL, presigned URL); it is encrypted and reads back redacted | |
| timeout_ms | No | per-attempt timeout in milliseconds (default 30000) | |
| max_attempts | No | maximum delivery attempts, 1-10 (default 5) | |
| wait_seconds | No | block up to this many seconds (max 55) for a terminal result instead of returning immediately after queueing | |
| connection_id | No | ID of a stored credential connection (con_...) to authenticate the call; see list_connections | |
| payload_schema | No | JSON Schema to validate payload against before anything executes; mismatches are rejected synchronously with a correction hint | |
| idempotency_key | No | stable key (max 255 chars) making this submit safe to retry; the same key returns the original execution instead of creating a new one. Always set this for side-effecting calls | |
| requires_approval | No | pause for a human approve/reject decision before anything executes; use for destructive or high-stakes actions |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavioral traits: async execution, automatic retries/backoff/circuit breakers, audit trail, encrypted storage, validation, idempotency, blocking mode, and approval pause. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is multi-sentence but each sentence adds unique value. First sentence defines purpose, second explains features, third provides actionable guidance. No redundancies, though slightly longer than minimal.
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 12 parameters and no output schema, the description covers major aspects: submission, retries, idempotency, blocking, approvals, and reference to get_execution for results. Could mention error handling but complete enough.
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), but the description adds significant context beyond schema descriptions: e.g., 'prefer connection_id over headers so secrets never pass through your context', 'always set idempotency_key for side-effecting calls', 'set wait_seconds to block for the result'.
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 states 'Submit an HTTP call to a third-party API for reliable asynchronous execution' using a specific verb and resource. It clearly distinguishes from siblings like get_execution (polling) by describing this as the submission point.
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 specifies when to use: 'for side effects (payments, messages, tickets, writes) or the target may be flaky'. Provides alternatives: 'poll get_execution with the returned execution_id' and clear directives like 'always set idempotency_key' and 'prefer connection_id over headers'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_executionAInspect
Fetch the current state of an execution by ID: status (PENDING_APPROVAL|QUEUED|RUNNING|RETRYING|SUCCEEDED|FAILED), attempts, the target response on success, or a classified error on failure. Retryable failures need no action from you — klanex is still retrying. Header values always read back REDACTED.
| Name | Required | Description | Default |
|---|---|---|---|
| execution_id | Yes | the execution ID (exe_...) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses that header values are redacted and retryable failures are handled automatically. It lists possible statuses. No side effects or auth requirements are mentioned, but for a read-only fetch, the provided details are sufficient.
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 two sentences, front-loaded with the core action and returned fields. Every sentence adds value: first sentence lists return content, second clarifies retry behavior and redaction. No redundancy.
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?
For a tool with one parameter and no output schema, the description covers the output structure (status, attempts, response, error), redaction, and retry behavior. It could mention that execution_id must be a valid ID, but the schema already constrains it. The description is sufficiently complete for an agent to use the tool correctly.
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 execution_id, with a clear description in the schema. The tool description only repeats 'by ID' and does not add additional meaning or format details 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 clearly states 'Fetch the current state of an execution by ID', specifying the verb (Fetch) and resource (execution state). It lists the fields returned (status, attempts, response, error) and distinguishes from siblings like list_executions (list) and execute (create).
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 says 'Retryable failures need no action from you—klanex is still retrying,' guiding the agent to not intervene. It implies usage for checking progress after executing. However, it does not explicitly contrast when to use this vs. list_executions or replay_execution.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_usageAInspect
Report the account's plan and execution usage for the current calendar month: used, included_executions, remaining, and whether overage is allowed. Check this before large batches to avoid hitting a hard quota.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes a read-only report with no destructive hints. Mentions overage behavior, which is a key behavioral trait. No annotations provided, but description adequately covers the tool's operation.
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?
Two concise sentences with no wasted words. First sentence states purpose and output, second sentence provides usage guidance.
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, the description lists exact data returned (used, included_executions, remaining, overage allowed). Provides temporal scope (current calendar month). Sufficient for a read-only query tool.
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?
No parameters exist; schema coverage is 100%. Description adds no parameter information (unnecessary), baseline is 4 for zero-parameter tools.
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 reports account plan and execution usage for the current month, listing specific fields (used, included_executions, remaining, overage allowed). Distinguishes from siblings like execute, get_execution, 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 recommends checking before large batches to avoid hitting a hard quota. Provides actionable context, though does not mention when not to use or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_connectionsAInspect
List the account's stored credential connections (token vault). Reference a ready connection by its ID in execute's connection_id instead of passing raw headers — the credential is injected at execution time and never passes through your context. Secrets are never returned.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that secrets are never returned and that credentials are injected at execution time. No annotations exist, so the description carries the burden; it does a good job but misses details like rate limits or authentication.
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?
Two concise sentences, front-loaded with purpose, and every sentence adds value.
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?
The tool is simple with no parameters. The description covers purpose and usage adequately, though it does not describe the return format (no output schema).
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 schema has no parameters, so the description need not add parameter info. Baseline 4 is appropriate.
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 lists stored credential connections (token vault). It distinguishes itself from siblings like 'execute' by focusing on managing connections for 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?
It explains when to use the tool: to reference a connection ID for execute's connection_id instead of passing raw headers. It provides security context but does not explicitly list when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_executionsAInspect
List this account's executions, newest first, optionally filtered by status or a created_at time range. Returns next_cursor when a page is full; pass it back as cursor for the next page.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | page size, 1-100 (default 20) | |
| since | No | only executions created at or after this RFC3339 timestamp | |
| until | No | only executions created before this RFC3339 timestamp | |
| cursor | No | opaque next_cursor value from a previous page | |
| status | No | filter by status: QUEUED, RUNNING, RETRYING, SUCCEEDED, or FAILED |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses pagination behavior and ordering, but does not mention authentication needs, rate limits, or effect on system state (though likely read-only). A 3 is adequate given the simplicity of the operation.
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?
Two sentences, front-loaded with purpose and key features (ordering, filters, pagination). No unnecessary words, every sentence adds value.
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, the description explains the cursor-based pagination mechanism sufficiently. It covers essential usage for listing, though could add return value structure or error handling hints.
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 the description adds no additional meaning beyond what is already in the input schema. It summarizes filters and pagination but does not enhance semantic understanding.
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 'List this account's executions' with a specific verb and resource, and distinguishes from siblings like get_execution (single) and execute (create) by context. It also adds ordering and filter details.
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 implies usage for listing executions with pagination and filters, but does not explicitly contrast with alternatives (e.g., get_execution for a single execution). Context is clear but exclusions are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
replay_executionAInspect
Re-run a terminal (SUCCEEDED or FAILED) execution as a brand-new execution: same target, byte-exact original payload, same sealed credentials, fresh attempt counter. This is the outage-recovery path — failed calls can be re-executed without regenerating the payload. Each call creates a new execution (deliberately not idempotent).
| Name | Required | Description | Default |
|---|---|---|---|
| execution_id | Yes | the execution ID (exe_...) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that each call creates a new execution (not idempotent), uses same target, payload, credentials, and fresh attempt counter. However, it lacks details on authorization needs, side effects on original execution, or error behavior.
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?
Two sentences, no fluff. First defines action and components, second gives purpose and non-idempotent warning. Every word earns its place.
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?
Simple tool with one parameter, the description covers purpose, usage, and behavioral traits adequately. Lacks explicit mention of return value or response structure, but given no output schema, this is a minor gap.
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 description coverage is 100% with a clear description of execution_id. The tool description adds no new constraints or format beyond 'execution ID', achieving the baseline for high coverage without extra semantics.
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 re-runs a terminal execution with the same payload and credentials, differentiating it from siblings like 'execute' (which runs a new command) and 'get_execution' (which reads). The verb 're-run' and resource 'terminal execution' are specific.
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 positions this as the outage-recovery path for re-executing failed or succeeded calls without regenerating payload, providing clear when-to-use context. It does not explicitly state when not to use, but the purpose is well-scoped.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!