Skip to main content
Glama
Sign In
TraceDelta

TraceDelta

by swaroop2005
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

refresh_capsule

Re-query the backend to compute only the changes since the latest evidence capsule version and create a new delta update, avoiding redundant full reprints during incident investigations.

Instructions

Return only what CHANGED since the latest capsule version (a delta), not a reprint. Re-queries the backend for the minimum needed and creates a new version.

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

Input Schema

NameRequiredDescriptionDefault
focusNo
consumerNo
capsule_idNo
investigation_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.9/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full burden. It discloses that this re-queries the backend and creates a new version, which implies mutation (creating a version). However, it doesn't disclose side effects beyond versioning, whether re-querying has cost/latency implications, or how the delta is formatted. The 'creates a new version' hint partially compensates for missing annotations.

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 short (two sentences) and front-loads the key behavior (return only what changed). The instruction-like phrasing is efficient. It's concise without being under-specified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool that mutates state (creates a new version), has 4 undocumented parameters, and lacks an output schema, the description is underspecified. It doesn't explain what the delta format looks like, what triggers re-querying, or whether parameters are mutually required (e.g., capsule_id vs investigation_id). Compare_capsules sibling suggests comparison could be relevant, adding ambiguity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and all 4 parameters have empty defaults. The description adds no meaning to focus, consumer, capsule_id, or investigation_id. With 0% coverage, the description should help clarify which parameters matter for the delta behavior, but it says nothing about them.

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 states the tool returns a delta (only what changed since the latest version) and creates a new version by re-querying. This is a specific verb+resource (refresh capsule) with clear scope, though it doesn't explicitly distinguish from siblings like compare_capsules which could be confused for diff functionality.

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?

No guidance on when to use this tool vs. get_capsule or compare_capsules. The delta behavior is described but there's no statement of when a user would need a refresh versus retrieving or comparing. With siblings like compare_capsules and get_capsule, explicit usage boundaries would help significantly.

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