Skip to main content
Glama
Sign In
fr0ster

mcp-abap-adt

by fr0ster
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

GetATCRunStatus

Checks whether an ATC run identified by run_id has finished and returns its server-reported status, so you can poll asynchronous runs started with wait=false.

Instructions

[read-only] Answers whether the ATC run named by run_id has ended (a run started with wait=false answers its run_id). Answers the status the server reports and whether it is finished — finished means ended, whatever the checks found. The run's findings are read by its worklist_id. Recordable: in batch mode a call is recorded under the next number and answers with empty content; its answer is read by number after the batch ends.

Input Schema

NameRequiredDescriptionDefault
run_idYesRun identifier an ATC run started with wait=false answered.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv20.1.0
    • changedInput schema / properties / run_id / description
      Previous value: -"Run identifier answered by RunATC when wait was false."New value: +"Run identifier an ATC run started with wait=false answered."
  2. Addedv16.0.0

TDQS

A4.8/5.0
Behavior5/5

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

Since no annotations were provided, the description carries a heavy burden, which it fulfills excellently. It explicitly defines the behavior of 'finished' (meaning ended) and details complex system behaviors like how findings are accessed via worklist_id and the specific response pattern during batch processing.

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 tool is necessary verbose due to the complex nature of ATC run states and batch processing. However, the structure is logical: purpose first, followed by status definition, and ending with niche batch processing details.

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 an output schema, the description provides all necessary contextual detail. It thoroughly explains the functional semantics, including the difference between 'finished' and 'ended,' and the system implications of batch mode.

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%, which is a high baseline. However, the description adds critical semantic context, specifically defining that the run must be one started with wait=false to successfully answer using the provided run_id.

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 function: answering whether an ATC run has ended. It is highly specific, focusing on status reporting and differentiating it from run execution or findings retrieval siblings.

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 provides explicit usage conditions, stating that the run must have started with wait=false to answer via run_id. It also details how the tool behaves conditionally in batch mode, dictating when the result can be accessed.

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