dzstudio-mcp

Overview Schema Source Related Servers Discussions Admin

session_events

Waits for and returns collaboration session events since the last result—joins, leaves, saves, discards, dropped steps, and lock changes—so agents can react to live session activity.

Instructions

What happened since the last result: joins, leaves, saves, discards, removal, own steps dropped, locks taken or released, connection. Waits up to wait_seconds (at most 30) for an event.

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

Input Schema

Name	Required	Description	Default
`session`	No	Session handle (s1, s2 …) or session id; default: the current session
`wait_seconds`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.3Nov 8, 2026

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description carries the full burden and does add useful behavior: it lists event categories and discloses that the call waits up to wait_seconds (max 30) for an event. However, it omits whether this is read-only, what happens on timeout, and how the 'last result' cursor is maintained.

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?

The description is a compact single sentence, front-loaded with the core semantics ('what happened since the last result') and followed by the relevant event list and wait constraint. The dense enumeration earns its place by telling the agent what kinds of events to expect.

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?

The tool is relatively simple with two optional parameters and no output schema, and the description covers event categories and wait behavior. It is still incomplete about the return shape, cursor semantics, and timeout behavior, which matter because there is no output schema to document the response.

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 50%: the session parameter is documented in the schema, and the description clarifies that wait_seconds controls how long the call waits for an event, with a maximum of 30. It does not explain edge cases such as wait_seconds=0 or what is returned when no event arrives within the wait.

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 clearly identifies the tool as returning session events since the last result and enumerates the event types covered. It is specific enough to distinguish from session_info, though it does not explicitly name an alternative or state the verb 'returns'.

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?

The phrase 'since the last result' and the wait behavior imply repeated polling for incremental events, but there is no explicit guidance on when to use this instead of session_info or other session tools. No exclusions or alternatives are provided.

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