Skip to main content
Glama
LCV-Ideas-Software

cross-review

by LCV-Ideas-Software
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Attach Session Evidence (Optional)

session_attach_evidence

Attach durable, out-of-band evidence to an existing cross-review session when material is not tied to a specific review round; only the session petitioner can call it.

Instructions

Attach one durable evidence artifact to an existing session, out of band from a review round, within the current configured aggregate evidence limit. Wait until any active round finishes; its admitted evidence corpus cannot be mutated concurrently. Only the session's own petitioner may call it, and the artifact carries the same caller_submitted_unverified provenance as material passed through the evidence field of a review starter — this tool promotes nothing. Prefer the evidence field for the routine path; this one exists for material that does not belong to a specific round. Requires the verified capability token of the persisted session petitioner; a peer cannot attach evidence to someone else's session.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
labelYes
callerYes
contentYes
extensionNotxt
session_idYes
content_typeNotext/plain
response_formatNojson

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv4.4.18
    • removedInput schema / properties / caller / default
      Removed value: -"operator"
    • changedInput schema / properties / caller / enum
      Previous value: -[
-  "codex",
-  "claude",
-  "gemini",
-  "deepseek",
-  "grok",
-  "perplexity",
-  "operator"
-]New value: +[
+  "codex",
+  "claude",
+  "gemini",
+  "deepseek",
+  "grok",
+  "perplexity"
+]
    • changedInput schema / required
      Previous value: -[
-  "session_id",
-  "label",
-  "content"
-]New value: +[
+  "session_id",
+  "label",
+  "content",
+  "caller"
+]
  2. First observedv4.4.8

TDQS

A4.4/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses the concurrency constraint (cannot mutate an admitted corpus during an active round), the authorization model (only the session's own petitioner, requires the verified capability token), the aggregate-limit scoping, and the provenance semantics (`caller_submitted_unverified`, 'promotes nothing'). These are material behavioral facts not derivable from readOnlyHint=false / destructiveHint=false.

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?

Front-loaded with the core action and reasonably dense, with each sentence adding a distinct constraint (concurrency, auth, provenance, routing). It is somewhat long and clause-heavy, but 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 non-idempotent mutation with no annotations on return values and no output schema, the description covers authorization, concurrency, scope, and provenance well. The main gap is parameter-level detail, which is missing from both description and schema.

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% across 7 parameters, so the description carries the burden — but it only loosely implies `caller` (petitioner) and `content` (artifact). It says nothing about `label`, `extension`, `content_type`, `response_format`, or the session_id format, leaving most parameters undocumented anywhere.

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 ('Attach one durable evidence artifact to an existing session') and immediately scopes it ('out of band from a review round'). It also names the sibling mechanism it is NOT (the `evidence` field of a review starter), so an agent can distinguish it from session_start_round without opening schemas.

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?

Explicit routing guidance: 'Prefer the `evidence` field for the routine path; this one exists for material that does not belong to a specific round.' It also gives a prerequisite/ordering rule ('Wait until any active round finishes'). When-to-use, when-not, and the alternative are all 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