Skip to main content
Glama
Sign In
Glitchrupt MCP Server

Glitchrupt MCP Server

by elbee19
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

glitchrupt_signal

Trigger a brief visual glitch effect with optional sound to signal attention. Supports preview mode, duration and volume control, and reports whether playback completed or timed out.

Instructions

Request one brief visual glitch with optional sound. preview=true uses a test window. Duration is 300–1000 ms, volume 0–0.5. Native pause, reduced-motion and cooldown safeguards apply. completed means playback finished; timeout means outcome unknown.

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

Input Schema

NameRequiredDescriptionDefault
soundNo
volumeNo
previewNo
variantNoclassic
duration_msNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations only declare readOnlyHint=false, destructiveHint=false and openWorldHint=false. The description goes meaningfully beyond them by disclosing safeguards (native pause, reduced-motion, cooldown) and result semantics ('completed means playback finished; timeout means outcome unknown'), which an agent could not derive from structured fields. It stops short of explaining what cooldown entails or what a failed/paused outcome looks like.

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

Conciseness5/5

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

Four short sentences, front-loaded with what the tool does, then the preview switch, then hard limits, then safeguards and outcome semantics. Nothing is redundant and no sentence is filler despite the telegraphic style.

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?

An output schema exists, so return values need not be spelled out, yet the description usefully clarifies the completed/timeout distinction. What is missing is variant semantics (five distinct glitch types) and any indication of what the preview test window does differently, which matters for a 5-parameter tool.

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?

Schema description coverage is 0%, so the description must compensate, and it does for the high-risk parameters: preview behavior, duration bounds (300–1000 ms) and volume bounds (0–0.5) are all restated with intent. It is silent on the variant enum beyond the schema's list, leaving one of five parameters without added meaning.

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?

States a specific verb and resource — 'Request one brief visual glitch with optional sound' — plus the scope ('one brief'). It does not name or distinguish itself from siblings such as glitchrupt_variants or glitchrupt_status, so an agent must infer the boundary, but the core action is unambiguous.

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 'preview=true uses a test window' clause gives a meaningful usage hint for testing versus live playback. However there is no explicit when-to-use/when-not guidance and no routing to glitchrupt_variants or glitchrupt_status, so usage is implied rather than stated.

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