Skip to main content
Glama
TheQtCompanyRnD

squish-mcp

Official

generate_page_objects_from_snapshot

Parses an XML object snapshot to generate Python page object code, automatically detecting output format based on existing patterns in the test suite.

Instructions

Generate page object references from an XML object snapshot file.

This tool:

  1. Calls parse_object_snapshot.py to filter XML elements and generate basic definitions

  2. Analyzes object reference patterns to understand existing style and locations

  3. Determines output format (simple dicts vs classes/functions) based on existing patterns

  4. Writes the generated Python code to a local temporary file and returns its path

Args: xml_file_path: Absolute path to the XML object snapshot file page_name: Name of the page/component these objects belong to test_suite_path: Path to a suite_* directory. output_directory: Existing directory where the temporary output file should be created

Note: To generate the XML snapshot file, a testcase script has to call saveObjectSnapshot(some_object, "snapshot_name.xml"), where some_object is the root object of the component to capture. In case of an empty testcase, a variation of the following can be used: import object all_top_level_objects = object.topLevelObjects() top_level_object = all_top_level_objects[0] # change to a suitable index in case of multi-window apps. saveObjectSnapshot(top_level_object, "snapshot_name.xml") The snapshot will be placed next to the test script that is being executed, so the xml_file_path should be constructed accordingly.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
page_nameYes
xml_file_pathYes
test_suite_pathYes
output_directoryYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
messageYesSummary of what was generated
summaryYesHuman-readable summary including format and temporary output path
xml_fileYesSource XML snapshot file path
page_nameYesName of the page/component these objects belong to
objects_foundYesNumber of object definitions generated
object_contextNoCurrent object reference context, if available
temp_file_pathYesAbsolute path to a local temporary file containing the generated object definitions
output_strategyYesStrategy used for output format and target location
pattern_analysisYesAnalysis of existing object reference patterns in the project
Behavior4/5

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

No annotations exist, so the description carries full burden. It discloses that the tool calls an external script, analyzes patterns, determines output format, writes to a temporary file, and returns its path. This is transparent for a code generation tool, though it does not mention potential side effects (e.g., file overwrite) beyond creating a temp file.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections (steps, args, note) but is somewhat lengthy due to a detailed note about generating the XML snapshot. The first sentence fronts the purpose, but the note could be condensed or referenced elsewhere.

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 the tool's complexity (4 required params, output schema present), the description covers purpose, input, processing, and output. It explains a key prerequisite (generating the XML snapshot). It does not explain return values beyond the file path, but an output schema exists. Missing usage guidance slightly reduces completeness.

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?

With 0% schema description coverage, the description compensates by explaining all four parameters in a structured 'Args' block. Each parameter gets a purpose and expected type (e.g., 'Absolute path to the XML object snapshot file'). This adds meaning beyond the bare JSON schema.

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?

The description clearly states the tool generates page object references from an XML snapshot file, with a specific verb ('Generate') and resource ('page object references'). The steps and argument list further clarify its function, distinguishing it from sibling tools like 'analyze_object_references' or 'extract_object_references' by focusing on code generation from a snapshot.

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?

While the description explains prerequisites (how to generate the XML snapshot), it provides no explicit guidance on when to use this tool versus alternatives. Sibling tools such as 'analyze_object_references' or 'extract_object_references' serve different purposes, but no comparison or selection criteria are given.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/TheQtCompanyRnD/squish-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server