ppsspp-dfx

Overview Schema Source Related Servers Discussions Admin

ppsspp_analyze_log

Read-onlyIdempotent

Filter PPSSPP log files for ERROR, WARNING, or CRASH lines to isolate emulator issues. Supports keyword and severity matching for targeted debugging.

Instructions

PURPOSE: Filter a PPSSPP log file for ERROR / WARNING / CRASH lines.

USAGE: log_path optional (defaults to the server-mirrored PPSSPP broadcast log at .ppsspp-dfx/output/ppsspp.log, written while a session runs); filter optional (keyword); session_id optional.

BEHAVIOR: READ-ONLY. Reads and filters a log file. Does not contact PPSSPP.

RETURNS: {log_path, matches: [{line_no, text}...], count, filter, filter_mode, total_matches, truncated}. truncated=true covers both an explicit limit cut and the internal 500-match cap; total_matches is a lower bound (>= the value) whenever truncated=true.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No	Cap the returned match list (0 = no cap beyond the hard internal cap of 500). When truncation happens the response carries total_matches and truncated=true; total_matches is a LOWER BOUND whenever truncated=true (the scan stops at 500 matches, so the real count can be higher). Use this on long logs instead of receiving 200KB+ of matches.
`filter`	No	Additional keyword to filter for. Case-sensitive substring match; combined with the severity keywords per filter_mode.
`log_path`	No	Path to the log file to analyze. Whitelist: must be a file anywhere inside the server-managed .ppsspp-dfx tree (the whole tree is allowed, wider than output/ or config/ — verified against the runtime whitelist); arbitrary filesystem paths are rejected. If None, reads the server-mirrored PPSSPP broadcast log (.ppsspp-dfx/output/ppsspp.log — the running game's own ERROR/WARNING lines, captured while a session runs).
`session_id`	No	Optional session ID (reserved for future use; ignored).
`filter_mode`	No	'any' (default, legacy): a line matches if it contains a severity keyword OR the filter. 'all': a line must contain a severity keyword AND the filter — use this to narrow (e.g. filter='GPU', filter_mode='all' → only GPU-related ERROR/WARNING/CRASH lines).	any

Output Schema

TableJSON Schema

Name	Required	Description
`count`	Yes	Number of matches (after limit truncation).
`filter`	Yes	User-supplied keyword filter.
`matches`	Yes	Matching log lines.
`log_path`	Yes	Path to the log file (or '(default)' if from launcher).
`truncated`	Yes	True when limit truncated the match list.
`filter_mode`	Yes	Filter combination mode: 'any' (legacy OR) or 'all' (severity AND filter).
`total_matches`	Yes	Match count before limit truncation.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.1.7Oct 7, 2026

changedInput schema / properties / log_path / description

Previous value: -"Path to the log file to analyze. S3 whitelist: must be a file anywhere inside the server-managed .ppsspp-dfx tree (the whole tree is allowed, wider than output/ or config/ — verified against the runtime whitelist); arbitrary filesystem paths are rejected. If None, reads the server-mirrored PPSSPP broadcast log (.ppsspp-dfx/output/ppsspp.log — the running game's own ERROR/WARNING lines, captured while a session runs)."New value: +"Path to the log file to analyze. Whitelist: must be a file anywhere inside the server-managed .ppsspp-dfx tree (the whole tree is allowed, wider than output/ or config/ — verified against the runtime whitelist); arbitrary filesystem paths are rejected. If None, reads the server-mirrored PPSSPP broadcast log (.ppsspp-dfx/output/ppsspp.log — the running game's own ERROR/WARNING lines, captured while a session runs)."

Changed9 schema fields changedv0.1.6Oct 4, 2026

changedInput schema / properties / filter / description

Previous value: -"Additional keyword to filter for (in addition to ERROR/WARNING/CRASH). Case-sensitive substring match."New value: +"Additional keyword to filter for. Case-sensitive substring match; combined with the severity keywords per filter_mode."

addedInput schema / properties / filter_mode

Added value: +{
+  "default": "any",
+  "description": "'any' (default, legacy): a line matches if it contains a severity keyword OR the filter. 'all': a line must contain a severity keyword AND the filter — use this to narrow (e.g. filter='GPU', filter_mode='all' → only GPU-related ERROR/WARNING/CRASH lines).",
+  "enum": [
+    "any",
+    "all"
+  ],
+  "title": "Filter Mode",
+  "type": "string"
+}

addedInput schema / properties / limit

Added value: +{
+  "default": 0,
+  "description": "Cap the returned match list (0 = no cap beyond the hard internal cap of 500). When truncation happens the response carries total_matches and truncated=true; total_matches is a LOWER BOUND whenever truncated=true (the scan stops at 500 matches, so the real count can be higher). Use this on long logs instead of receiving 200KB+ of matches.",
+  "title": "Limit",
+  "type": "integer"
+}

changedInput schema / properties / log_path / description

Previous value: -"Path to the log file to analyze. S3 whitelist: must be a file under the server-managed .ppsspp-dfx tree (.ppsspp-dfx/output/ or .ppsspp-dfx/config/); arbitrary filesystem paths are rejected. If None, reads the server-mirrored PPSSPP broadcast log (.ppsspp-dfx/output/ppsspp.log — the running game's own ERROR/WARNING lines, captured while a session runs)."New value: +"Path to the log file to analyze. S3 whitelist: must be a file anywhere inside the server-managed .ppsspp-dfx tree (the whole tree is allowed, wider than output/ or config/ — verified against the runtime whitelist); arbitrary filesystem paths are rejected. If None, reads the server-mirrored PPSSPP broadcast log (.ppsspp-dfx/output/ppsspp.log — the running game's own ERROR/WARNING lines, captured while a session runs)."

changedOutput schema / properties / count / description

Previous value: -"Number of matches."New value: +"Number of matches (after limit truncation)."

addedOutput schema / properties / filter_mode

Added value: +{
+  "description": "Filter combination mode: 'any' (legacy OR) or 'all' (severity AND filter).",
+  "title": "Filter Mode",
+  "type": "string"
+}

addedOutput schema / properties / total_matches

Added value: +{
+  "description": "Match count before limit truncation.",
+  "title": "Total Matches",
+  "type": "integer"
+}

addedOutput schema / properties / truncated

Added value: +{
+  "description": "True when limit truncated the match list.",
+  "title": "Truncated",
+  "type": "boolean"
+}

changedOutput schema / required

Previous value: -[
-  "log_path",
-  "matches",
-  "count",
-  "filter"
-]New value: +[
+  "log_path",
+  "matches",
+  "count",
+  "filter",
+  "filter_mode",
+  "total_matches",
+  "truncated"
+]

First observedv0.1.0Sep 16, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context: it does not contact PPSSPP, the default source is the server-mirrored broadcast log, and it explains that the 500-match internal cap makes total_matches a lower bound — behavioral detail absent from annotations.

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?

Front-loaded PURPOSE/USAGE/BEHAVIOR/RETURNS structure with no filler; every sentence carries load-bearing information and the most decision-relevant facts come first.

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?

With annotations covering safety, an output schema present, and 100% schema description coverage, the description supplies the remaining gaps (default source, truncation lower-bound semantics) and omits return-value detail that the output schema already owns.

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?

Schema coverage is 100% and each parameter already carries a detailed description, so the baseline is 3. The USAGE line restates optional/default status but adds no syntax or format detail beyond what the schema provides.

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?

States a precise verb+resource+scope: filter a PPSSPP log file for ERROR/WARNING/CRASH lines. No sibling tool covers this surface, and the purpose is unambiguous without opening the schema.

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?

Explicitly documents that log_path, filter, and session_id are optional and what the defaults resolve to, and the schema's filter_mode documents the 'all' vs 'any' narrowing with a concrete example. It stops short of naming when a sibling tool would be preferable, but no obvious alternative exists.

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