Skip to main content
Glama
Sign In
Catalyst MCP for FiveM

Catalyst MCP for FiveM

by Geckomacabre
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

ptfx_edit

Edits GTA V .ypt.xml particle effects in place or to an output file by applying ordered operations for properties, keyframes, scaling, tinting, textures, renaming, duplication, and deletion.

Instructions

Edit a .ypt.xml (in place or to out). ops, applied in order: {op:'set', kind, name, path:'DurationMax' | 'CreationDomainObj/DomainType' | 'AllBehaviours/Colour/RGBAMaxEnable' | 'EventEmitters/0/StartRatio', value}; {op:'keys', kind, name, prop:'ptxu_Colour:m_rgbaMinKFP', keys:[[t,x,y,z,w],...]} (t 0..1 over life/duration); {op:'scale', kind, name, prop:'ptxEmitterRule:m_spawnRateOverTimeKFP', factor: f | [fx,fy,fz,fw]}; {op:'rename'|'duplicate'|'delete', kind, name, to}; {op:'tint', name: effect, min:[r,g,b,a], max:[r,g,b,a]}; {op:'texture', name: particle, texture, var:'diffusetex2', external: bool, dds: path to your own .dds}; {op:'dict_name', to}. kind defaults to particle. ptfx_info detail=true lists the prop names.

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": {
      "xml": "<xml>",
      "ops": "<ops>"
    },
    "name": "ptfx_edit"
  }
}

Input Schema

NameRequiredDescriptionDefault
opsYes
outNo
xmlYesabsolute path

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=false and openWorldHint=false, so the description carries most of the burden and does add real context: in-place versus `out` write targets, sequential application of operations ('applied in order'), the default for `kind`, and the normalized 0..1 time axis for keys. It stops short of stating failure behavior, whether in-place edits are reversible, or what is returned.

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 purpose and the file-target semantics are front-loaded, and nearly every clause conveys a distinct fact about the op grammar, so there is little wasted wording. The cost is formatting: the op list is a single semicolon-delimited block that is slow to scan while debugging a call.

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

Completeness3/5

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

For a tool whose real complexity lives in a 9-op DSL with no output schema, the description covers the op vocabulary well and points to ptfx_info for prop discovery. It is still incomplete on `out` path expectations, error/partial-application behavior, and the meaning of individual undocumented op fields, which matters given the tool mutates files.

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 description coverage is only 33% — `xml` is documented as an absolute path in the schema, but `out` and every field inside `ops` items are bare — so the description must compensate, and it largely does by documenting each op's shape with concrete field examples such as path strings, prop identifiers, and factor scaling. Gaps remain: `deep` is never explained, the `dict_name` and `tint` ops have unclear target semantics, and it is not obvious which fields pair with which op.

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?

The description opens with a specific verb and resource: 'Edit a .ypt.xml (in place or to `out`)', then enumerates the exact op vocabulary the tool accepts. That is enough for an agent to know this is the mutation entry point for effect XML files, though it never explicitly contrasts itself with ptfx_merge or ptfx_install beyond a passing reference to ptfx_info.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives one genuinely useful routing rule — 'ptfx_info detail=true lists the prop names' — which tells the agent to discover valid prop identifiers before calling. However, it never says when to choose this over sibling operations like ptfx_merge, nor when to edit in place versus writing to `out`, so the when-to-use guidance is only partially implied.

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