Skip to main content
Glama

playcal_query

Filter large JSON results or Unity Editor command output by conditions, then return only matching items, selected fields, and a limited count to reduce noise for coding agents.

Instructions

pick a list, filter it and keep only the fields you need from a big JSON result

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": "playcal_query"
  }
}

Input Schema

NameRequiredDescriptionDefault
frmNothe list to read, e.g. data.objects; ** walks nested children at any depth
limitNomost items to return (default 50)
unityNoread from a Unity Editor command instead, e.g. "get_hierarchy --depth 3"
whereNokeep items where EXPR holds: name~Enemy, active=true, tag!=Untagged. Repeatable
selectNofield to keep per item. Repeatable
sourceNoJSON file, or - for stdin (default). Ignored with --unity-
project_pathNoUnity project folder, with --unity

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.1

TDQS

C2.6/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 and it discloses very little. It implies read-only behavior through the word 'query' but never states it, and says nothing about how large results are handled, stdin/file sourcing, whether a Unity connection is required, or what happens on a failed filter expression.

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?

A single front-loaded sentence with no filler or repetition. Its compactness is achieved at the cost of precision, but there is no bloat to trim.

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?

This is a seven-parameter tool with two distinct execution modes (JSON file/stdin and Unity Editor command), a filter mini-language, and no output schema or annotations. A one-line informal sentence leaves far too much unspecified for correct invocation, particularly around how 'frm', 'source', 'unity', and 'project_path' interact.

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 description coverage is 100%, so the schema already documents all seven parameters including the 'where' expression examples and the 'frm' wildcard semantics. The description only echoes the concepts (list, filter, fields) without adding any syntax, precedence, or default behavior beyond what the properties already say, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The verb sequence (pick / filter / keep fields) does convey a query-and-project operation, and 'from a big JSON result' hints at the data domain. But the description never names the resource or system (Unity editor data, playcal source files) and offers nothing to distinguish it from siblings like playcal_observe or playcal_logs, so an agent cannot confidently route to it.

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 use this tool versus the ~19 sibling tools, and no mention of the two mutually exclusive modes (reading a list via 'frm'/'source' vs. invoking an Editor command via 'unity'). The alternative paths are only discoverable by reading the schema.

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