sims4-tc-mcp

validate_and_build_ts4script

Validates Python 3.7 source code with an AST gatekeeper, then bundles the module into a .ts4script zip for Sims 4 script mods.

Instructions

Run the Python 3.7 AST gatekeeper then bundle a .ts4script zip.

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": {
      "source_dir": "<source_dir>",
      "output_path": "<output_path>"
    },
    "name": "validate_and_build_ts4script"
  }
}

Input Schema

Name	Required	Default
`strict`	No
`source_dir`	Yes
`module_name`	No	mod
`output_path`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 13, 2026

TDQS

C2.6/5.0

Behavior2/5

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

With no annotations, the description carries the full burden and leaves key traits unstated: whether the zip is still written when the AST gatekeeper rejects the source, whether the output path is overwritten, and what the failure mode looks like. It does at least disclose the ordered validate-then-bundle behavior, which is real information.

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?

One front-loaded sentence with no filler, and the ordering of the two phases is clear. That said, the brevity comes at the cost of needed detail rather than from trimming redundancy.

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

Completeness2/5

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

For a mutation tool that writes a file, has no annotations, no output schema, and four completely undocumented parameters, this definition is under-specified. An agent could not reliably set strict or module_name from this description alone.

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

Parameters1/5

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

Schema description coverage is 0% across four parameters, and the description provides no explanation of source_dir, output_path, module_name (default 'mod'), or strict. The strict flag is especially important because it presumably governs the gatekeeper's behavior, yet the description never connects it to validation.

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 two-step verb sequence (validate via Python 3.7 AST gatekeeper, then bundle a .ts4script zip) and names a concrete artifact format, which separates it from a generic packaging tool. It does not explicitly contrast itself with the sibling build_package, so it stops short of full differentiation.

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

Usage Guidelines2/5

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

There is no guidance on when to choose this over build_package, no preconditions for the validation step, and no statement of what to do when validation fails. The only implied usage is that the source must be Python 3.7 compatible.

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

Deploy Server