Skip to main content
Glama
Sign In
Sess

Sess

by w1991e
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Finish the Sess interaction

sess_complete
DestructiveIdempotent

Close the waiting answer page after verifying the person's response to confirm the session is complete and stop new answers without deleting submitted data.

Instructions

Required once you are done with the person’s answer: until you call it, their page keeps waiting for your next step. It closes the page to new answers and does not delete what was given. Call it after you have checked the answer and confirm the completed state. If the outcome is unknown, repeat the identical call.

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": {
      "handle": "<handle>",
      "expected_revision": "<expected_revision>",
      "response_event_id": "<response_event_id>"
    },
    "name": "sess_complete"
  }
}

Input Schema

NameRequiredDescriptionDefault
handleYesOpaque handle from sess_request.
expected_revisionYes
response_event_idYesinteraction.response.eventId from the verified answer.

Output Schema

NameRequiredDescriptionDefault
interactionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.9/5.0
Behavior4/5

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

The destructiveHint=true annotation would otherwise make an agent fear data loss; the description usefully narrows this to 'closes the page to new answers and does not delete what was given.' It also discloses the blocking consequence (their page keeps waiting until you call it) and the safe-retry behavior, which adds operational meaning beyond idempotentHint. It does not cover what happens after closing or how a revision conflict surfaces.

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 mandatory nature is front-loaded in the first clause, and every sentence carries actionable content (urgency, non-deletion, verification, retry). The phrasing is slightly repetitive around closing the page, but nothing is padding.

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 mutating terminal tool with an output schema and full annotation coverage, the description supplies the urgency, the data-safety clarification, and the retry rule an agent needs. The remaining hole is the undocumented expected_revision semantics, which matters because the call fails without a valid value.

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 67%, with handle and response_event_id already documented in the schema, so the baseline is a 3. The description adds no parameter-level meaning at all, leaving expected_revision — an evident concurrency token — unexplained in both the schema and the description.

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 uses a specific verb+outcome framing: it closes the page to new answers and does not delete what was given, which lets an agent distinguish this terminal step from the request/response/ask siblings. It stops short of naming an explicit alternative or contrasting with a cancel/abandon path, so it is clear but not fully differentiated.

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

Usage Guidelines4/5

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

Timing is stated precisely ('Required once you are done with the person's answer' and 'Call it after you have checked the answer and confirm the completed state'), so the when-to-use condition is explicit. It also gives a recovery rule for unknown outcomes (repeat the identical call), though no sibling alternative is named for an abandoned or failed interaction.

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