Skip to main content
Glama
Sign In
Arsel MCP Server

Arsel MCP Server

Official
by Arsel-SA
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

Get Automation Run

get-automation-run
Read-onlyIdempotent

Retrieve an automation run to inspect what triggered it and each step's completed, skipped, or failed status, explaining why a contact did or did not receive a message.

Instructions

Get one run: what started it and each step it went through, completed, skipped (with the reason a message was not sent, e.g. no_email or suppressed) or failed. Use it to explain why a contact did or did not get a message.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "id": "<id>",
      "run_id": "<run_id>"
    },
    "name": "get-automation-run"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesThe automation id.
run_idYesThe run id.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.2.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare this as a safe, idempotent, non-destructive read, so safety needs no explanation. The description goes beyond them by sketching the returned content — step-level statuses and skip reasons such as no_email or suppressed — which is genuinely useful since there is no output schema.

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?

Two sentences, front-loaded with purpose and then the recommended use case, with no filler or repetition of annotations. Slightly dense phrasing ("what started it and each step it went through") but nothing that could be cut without losing information.

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

Completeness4/5

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

For a simple two-uuid read with no nested objects and no output schema, the description covers purpose, the shape of the result, and the reason to call it. A note on what happens when the run is not found, or a pointer to list-automation-runs to obtain a run_id, would make it complete.

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

Parameters3/5

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

Both parameters (id, run_id) are fully documented in the schema with UUID format and patterns, so the schema carries the burden. The description adds no semantics about either parameter, which is acceptable at 100% coverage but earns only the baseline.

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

Purpose4/5

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

States a specific verb and resource ("Get one run") and immediately characterizes the payload: the trigger ("what started it") and per-step outcomes ("each step it went through"). This implicitly separates it from list-automation-runs, but never names that sibling or any other, so the differentiation is inferred rather than stated.

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?

Gives an explicit use case — "Use it to explain why a contact did or did not get a message" — which is a real decision context an agent can match against. It stops short of saying when not to use it (e.g., that you need list-automation-runs first to obtain a run_id).

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

Deploy Server

Other Tools