Skip to main content
Glama

vora_delete_traffic_light

DestructiveIdempotent

Removes the signed-in user's traffic-light levels for one biomarker. The levels are gone afterwards.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "slug": "<slug>"
    },
    "name": "vora_delete_traffic_light"
  }
}

Input Schema

NameRequiredDescriptionDefault
slugYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the destruction profile is known before reading the description. The description adds the useful scoping fact that only the signed-in user's levels are affected, but "The levels are gone afterwards" largely restates destructiveHint, and nothing is said about what happens when no levels exist or how errors surface.

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?

Two short sentences, front-loaded with the operation and its scope. The second sentence ("The levels are gone afterwards") is nearly redundant with the destructive annotation and could be dropped, but total length is minimal.

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?

For a one-parameter destructive delete with rich annotations, the definition covers what is removed and whose data it is. It falls short on the one thing the schema does not supply: how to obtain a valid biomarker slug and what happens on unknown or missing levels.

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 0% for the single required parameter, so the description must carry the meaning of "slug." It tells the agent the parameter identifies "one biomarker," which is genuinely useful, but it does not say where the slug comes from (e.g., vora_list_biomarkers) or what format it takes, leaving a real gap.

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 states a specific verb ("Removes") and resource ("traffic-light levels") scoped to "one biomarker" and "the signed-in user's," which distinguishes it from vora_set_traffic_light and vora_get_traffic_lights by implication. It never names those siblings explicitly, so differentiation is inferred rather than stated.

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 explicit when-to-use or when-not-to-use guidance, and no mention of the natural alternatives (vora_set_traffic_light to create levels, vora_get_traffic_lights to read them). The agent must infer the scenario purely from the verb and resource.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources