Skip to main content
Glama
Sign In
dzstudio-mcp

dzstudio-mcp

by siemendev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

read_scene

Read a dzStudio collaboration session's scene overview, including map, named groups, object counts, hidden/locked status, X/Z bounds, and loot settings before making changes.

Instructions

Overview of the project: map, groups with name, object count, hidden, locked and the X/Z bounds of their objects; loot on or off.

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

Input Schema

NameRequiredDescriptionDefault
sessionNoSession handle (s1, s2 …) or session id; default: the current session

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.3

TDQS

B3.2/5.0
Behavior3/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 does useful work by enumerating the returned fields (map, groups, bounds, loot), effectively substituting for a missing output schema. However, it never states that the call is read-only and side-effect free, nor anything about permissions or session state, which is a gap for a tool with zero annotation coverage.

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?

It is a single compact sentence with the key scope ('Overview of the project') front-loaded and the payload listed after the colon. The trailing 'loot on or off' is slightly tacked on, but nothing is redundant.

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?

For a no-argument, read-only overview tool with no output schema, the description supplies the most important missing piece: what the response contains. The remaining omission is a read-only/side-effect statement and any pointer to related tools, which is minor given the tool's simplicity.

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?

The single optional 'session' parameter is fully documented in the schema (100% coverage) including its default, and the description adds nothing about it. With one parameter and complete schema documentation, the baseline of 3 applies.

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?

The description enumerates exactly what the tool returns: the project map, groups with name/object count/hidden/locked flags, X/Z bounds, and loot state. That is a concrete verb-less but specific resource description, and an agent can tell it apart from query_objects or world_info by the overview-level content. It stops short of an explicit verb or a statement of what it does not cover.

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 when-to-use guidance, no prerequisite, and no mention of any sibling tool such as query_objects, world_info, or list_projects. The word 'Overview' weakly implies a summary call, but the agent must infer that on its own.

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

Deploy Server

Other Tools