Liminal

handoff

Save or continue work across sessions. create: task, session_state, evidence, subject. resume: subject or handoff_id. list. More args: get_capabilities(tool=...).

Input Schema

TableJSON Schema

Name	Required	Description
`task`	No
`action`	Yes	create\|resume\|list
`context`	Yes	Describe the user's goal in one short sentence. Omit personal data and secrets.
`subject`	No	work name; resume by subject in one call
`evidence`	No
`llm_model`	Yes	The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
`handoff_id`	No
`session_state`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 20, 2026

addedInput schema / properties / llm_model

Added value: +{
+  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "action",
-  "context"
-]New value: +[
+  "action",
+  "context",
+  "llm_model"
+]

Changed24 schema fields changedOct 18, 2026

addedInput schema / properties / action / description
```
Added value: +"create|resume|list"
```
removedInput schema / properties / action / title
```
Removed value: -"Action"
```

removedInput schema / properties / checkpoint

Removed value: -{
-  "anyOf": [
-    {
-      "additionalProperties": true,
-      "type": "object"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "title": "Checkpoint"
-}

addedInput schema / properties / context

Added value: +{
+  "description": "Describe the user's goal in one short sentence. Omit personal data and secrets.",
+  "type": "string"
+}

removedInput schema / properties / current_artifact_hash

Removed value: -{
-  "default": "",
-  "title": "Current Artifact Hash",
-  "type": "string"
-}

removedInput schema / properties / detail

Removed value: -{
-  "default": "lean",
-  "title": "Detail",
-  "type": "string"
-}

removedInput schema / properties / evidence / default
```
Removed value: -""
```
removedInput schema / properties / evidence / title
```
Removed value: -"Evidence"
```
removedInput schema / properties / handoff_id / default
```
Removed value: -""
```
removedInput schema / properties / handoff_id / title
```
Removed value: -"Handoff Id"
```

removedInput schema / properties / parent_handoff_id

Removed value: -{
-  "default": "",
-  "title": "Parent Handoff Id",
-  "type": "string"
-}

removedInput schema / properties / refs

Removed value: -{
-  "anyOf": [
-    {
-      "additionalProperties": true,
-      "type": "object"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "title": "Refs"
-}

removedInput schema / properties / resources

Removed value: -{
-  "default": "",
-  "title": "Resources",
-  "type": "string"
-}

removedInput schema / properties / session_state / default
```
Removed value: -""
```
removedInput schema / properties / session_state / title
```
Removed value: -"Session State"
```

removedInput schema / properties / source_sessions

Removed value: -{
-  "anyOf": [
-    {
-      "items": {
-        "type": "string"
-      },
-      "type": "array"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "title": "Source Sessions"
-}

removedInput schema / properties / subject / default
```
Removed value: -""
```

addedInput schema / properties / subject / description

Added value: +"work name; resume by subject in one call"

removedInput schema / properties / subject / title
```
Removed value: -"Subject"
```
removedInput schema / properties / task / default
```
Removed value: -""
```
removedInput schema / properties / task / title
```
Removed value: -"Task"
```

removedInput schema / properties / tool_manifest

Removed value: -{
-  "anyOf": [
-    {
-      "items": {
-        "additionalProperties": true,
-        "type": "object"
-      },
-      "type": "array"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "title": "Tool Manifest"
-}

changedInput schema / required

Previous value: -[
-  "action"
-]New value: +[
+  "action",
+  "context"
+]

removedInput schema / title
```
Removed value: -"handoffArguments"
```

First observedOct 12, 2026

TDQS

B3.3/5.0

Behavior2/5

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

With no annotations, the description carries the full behavioral burden, yet it says nothing about persistence lifetime, auth requirements, rate limits, or what 'save' or 'resume' actually mutate or return. 'Save or continue work across sessions' hints at persistence but discloses no concrete behavioral traits.

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?

Very terse and front-loaded, with the core purpose first and action-arg groups following. The telegraphic style is efficient, though it borders on cryptic enough to occasionally cost clarity.

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

Completeness3/5

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

For an 8-param, multi-action tool with no annotations and no output schema, the description is thin, though it does route the agent to get_capabilities for additional arguments. It leaves return behavior, persistence semantics, and mode selection under-specified.

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 50%, and the description helpfully maps undocumented params to their action (create: task, session_state, evidence, subject; resume: subject or handoff_id), a relationship the flat schema does not convey. It does not add format or syntax detail, but it meaningfully compensates for the coverage gap.

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 states a specific purpose ('Save or continue work across sessions') and enumerates the three action modes (create/resume/list), which lets an agent distinguish them from siblings like focus or solve. It does not, however, differentiate itself relative to the sibling tools by name.

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

Usage Guidelines3/5

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

It implies when each action applies by mapping args to modes (create: ...; resume: subject or handoff_id; list), and points to get_capabilities for more args. But there is no explicit when-to-use/when-not guidance versus alternatives like focus, leaving selection largely to inference.

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

All Liminal tools Inspect

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.