Skip to main content
Glama
Sign In
wtf-wave

wtf-wave

by xtrollyj00
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

user_view

DestructiveIdempotent

Captures the user's current waveform view so you can start from what they see; optionally adopts their rows, cursors, and range, reversible with undo.

Instructions

What the user is looking at in their wtf window on this trace, worded as view words the workspace, to start from what they see. Changes nothing unless adopt: that replaces the workspace's rows, cursors and range with the user's, dropping yours; command undo brings them back.

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

Input Schema

NameRequiredDescriptionDefault
adoptNoAlso copy the user's rows, cursors and visible range into the workspace, to build on them; they replace the workspace's (one `undo` step).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.4.0
    • changedInput schema / properties / adopt / description
      Previous value: -"Also copy the user's rows, cursors and visible range into the workspace, to build on them."New value: +"Also copy the user's rows, cursors and visible range into the workspace, to build on them;\nthey replace the workspace's (one `undo` step)."
  2. First observedv0.3.0

TDQS

B3.2/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false; the description earns credit by specifying exactly what `adopt` destroys ('replaces the workspace's rows, cursors and range with the user's, dropping yours') and the recovery path ('`command` `undo` brings them back'). That is concrete consequence and rollback information beyond the hint flags.

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?

One dense sentence carries all the information; it is economical but front-loading is weak and the phrasing ('worded as `view` words the workspace') plus the 'wtf window' term add decoding cost rather than clarity.

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?

With one optional parameter, rich annotations, and no output schema, the definition covers the destructive path and its undo, which is the main risk an agent faces. It is less complete on what is actually returned beyond a vague pointer to `view`'s output format.

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 the single `adopt` boolean is fully documented in-schema, so the baseline is 3. The description reinforces the overwrite/undo semantics but adds little that the schema description does not already say.

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 core idea (retrieve what the user is currently looking at) is recoverable, and 'worded as `view` words the workspace' points at a sibling's output shape. But 'wtf window' is unexplained jargon and the sentence structure obscures the verb/resource, so an agent must work to parse the purpose.

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?

It implies usage ('to start from what they see') and states the key conditional: nothing changes unless `adopt` is set. There is no explicit when-not or comparison against alternatives such as `view` or `workspace`, so guidance is implied rather than spelled out.

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