Skip to main content
Glama
Sign In

Vitalli

by app.vitalli.mcp
OverviewDiscussionsAdmin

vora_delete_biomarker

DestructiveIdempotent

Delete one biomarker observation from the signed-in user's Vora record (by id). Values that came from a document extraction or a CSV import are protected and return an error unless force=true; the regular way to remove those is deleting the document or rolling back the import in Vora.

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": {
      "observationId": "<observationId>"
    },
    "name": "vora_delete_biomarker"
  }
}

Input Schema

NameRequiredDescriptionDefault
forceNoAlso delete values that came from a document extraction or CSV import
observationIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already cover destructiveness, idempotency and scope, but the description adds non-obvious behavior the annotations cannot express: protected provenance classes and the error returned when force is omitted. It stops short of stating what happens on an unknown id or what the response looks like, but the mutation-specific risk is well disclosed.

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?

One sentence leads with the action and target, then adds the protection caveat and the sanctioned alternative. The parenthetical placement of 'by id' and the force clause are tight; no sentence is filler.

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 two-parameter destructive tool with rich annotations and no output schema, the description covers purpose, the main failure mode, and the override. The only gaps are behavior on a nonexistent id and whether the deletion is recoverable, which are minor given the annotation set.

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 coverage is only 50% and observationId is undocumented in the schema, but the description compensates by stating it is the id of the single observation being deleted. For 'force', the description restates the schema meaning and ties it to the concrete error it bypasses, adding real semantics rather than echoing the property text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Delete one biomarker observation'), names the owning collection ('signed-in user's Vora record') and the addressing key ('by id'). This distinguishes it from sibling vora_delete_observation and from add/list biomarker tools without needing the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly carves out the case where deletion is disallowed (values from document extraction or CSV import) and names the preferred alternative ('deleting the document or rolling back the import'). It also tells the agent the exact escape hatch (force=true), so the when-to-use and when-not-to-use conditions are both spelled out.

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

All Vitalli toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources