sims4-tc-mcp

analyze_last_exception

Parses the newest lastException, lastUIException, or lastCrash file and cross-references it with The Sims 4 Python and tuning indexes to diagnose script mod errors.

Instructions

Parse the newest lastException/lastUIException/lastCrash file and cross-reference it with the game Python and tuning indexes.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "analyze_last_exception"
  }
}

Input Schema

Name	Required	Description	Default
`sims4_docs_dir`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 13, 2026

TDQS

B3/5.0

Behavior2/5

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

No annotations are supplied, so the description carries the full disclosure burden. It reveals the two-step behavior (parse newest exception file, then cross-reference indexes) but says nothing about whether the tool only reads, what it returns, what happens when no exception file exists, or whether missing indexes cause failure.

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 short sentences, front-loaded with the action and resource, with no filler. The only weakness is that the second clause is compressed enough to be slightly ambiguous about what the cross-reference produces.

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?

No output schema and no annotations mean the description must explain results and prerequisites, which it largely does not. It conveys the core pipeline but leaves an agent guessing about the return format, failure modes, and the role of sims4_docs_dir.

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

Parameters2/5

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

There is one parameter, sims4_docs_dir, with 0% schema description coverage beyond a title and null default. The description never mentions this parameter, so an agent gets no help on what directory it should point to or how the default is resolved.

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 ("Parse") and specific resources (the newest lastException/lastUIException/lastCrash file) plus a second action (cross-reference with game Python and tuning indexes). This is clearly distinguishable from siblings like rebuild_indexes or inspect_package, though it never names an alternative.

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?

Implicit usage only: an agent can infer this is for diagnosing a Sims 4 exception after a crash or UI error. There is no explicit when-to-use, when-not-to-use, or prerequisite statement (e.g., that indexes must exist), and no named alternative diagnostic tool.

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

Deploy Server