Skip to main content
Glama

unreal_performance_cancel

Cancel an ongoing performance timing capture in Unreal Engine, preserving partial results for analysis.

Instructions

Cancel an owned timing capture and preserve its partial result.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
job_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Beyond the annotations, the description reveals the key behavioral trait that cancellation is non-destructive because it preserves partial results. It does not explain retry behavior or what happens to finalized captures, but the preservation detail adds real value over the structured fields.

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?

One sentence with no wasted words; the action, resource, ownership constraint, and result-preservation behavior are all packed in eleven words. Front-loaded and easy to scan.

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?

Given only one parameter, an output schema, and supporting sibling tools, the description covers the essential semantics of cancellation. It could mention prerequisites such as the capture being owned and in-progress, but the core information an agent needs to invoke it correctly is present.

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?

The schema has 0% description coverage and only one parameter, job_id. The description does not explicitly define job_id, though the noun phrase 'timing capture' and the parameter name make the mapping inferable. A short note about where the ID comes from would have compensated for the missing schema description.

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 uses specific verb 'Cancel', resource 'timing capture', and scope 'owned', and adds 'preserve its partial result' to distinguish from simple cancellation. This clearly separates it from sibling tools like unreal_performance_start, unreal_performance_job, and unreal_performance_compare.

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?

It establishes the clear context: call when you own a timing capture and need to stop it while keeping partial data. It does not explicitly name alternatives or exclusions, but the sibling names and 'owned' constraint provide enough routing context for the agent.

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