Skip to main content
Glama

render_evidence_view

Read-only

Render an evidence view for a specified state and profile in Gantry's versioned robotics development data so agents can inspect supporting artifacts and changes.

Instructions

render evidence view

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": {
      "arguments": "<arguments>"
    },
    "name": "render_evidence_view"
  }
}

Input Schema

NameRequiredDescriptionDefault
argumentsYes
idempotency_keyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.4.0

TDQS

D1.8/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known, but the description adds nothing beyond that: it does not say whether rendering is deterministic, whether profile/state combinations can fail validation, or what the caller receives. With a zero-coverage description, the agent has only the annotations plus a redundant title.

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

Conciseness2/5

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

It is short only because it is under-specified rather than because it is efficient. The phrase is a lowercase echo of the name and earns no space of its own, offering no structure or front-loaded information.

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

Completeness1/5

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

This is a complex nested-schema tool with no output schema, and the description does not compensate at all: no explanation of what a rendered evidence view is, what the nested profile drives, or what resolves 'evidence view' relative to get_evidence_view and query_evidence.

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

Parameters1/5

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

Schema description coverage is 0% for a deeply nested payload whose core fields (view_id, state_id, profile with fields/basis/intent, idempotency_key) are entirely unexplained. The description supplies no meaning for any of them, and the ambiguity between 'render' and 'create a view' makes the profile requirement especially opaque.

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

Purpose2/5

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

"render evidence view" merely restates the tool name in lowercase; it names no verb nuance (does it render HTML, produce a snapshot, or evaluate a profile against a state?) and gives no signal distinguishing it from the sibling get_evidence_view.

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 when-to-use guidance, no prerequisite statement, and no reference to an alternative. The agent cannot tell from the description whether this should be called before or after get_evidence_view or state, or whether it is even required for a normal evidence workflow.

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