Skip to main content
Glama
FutureEnterprises

@unihodl/mcp-server

by FutureEnterprises
OverviewSchemaRelated ServersScoreDiscussions
TypeScript
Remote

UNIHODL — Agent Handoff SDK & MCP Server

The handoff layer for the agentic web. Capture a human's working session — open tabs, scroll positions, video timestamps, and reasoning thread — and hand it to any AI agent as a signed, scoped, revocable Resume Token. Your agent picks up exactly where the human left off instead of starting cold.

This is the open-source SDK + MCP server + protocol spec. The browser extension, web app, and product live separately at unihodl.app.

# Zero-setup demo — no signup, sandbox key, real API:
npx -y @unihodl/mcp-server
#   env: UNIHODL_API_KEY=uh_test_sandbox_demo_key_v0
# then ask your agent:  resume ses_8f3aZ91b

What's here

Package

What it is

Install

@unihodl/mcp-server

MCP server — gives Claude Desktop, Cursor, Cline, etc. a resume tool

npx -y @unihodl/mcp-server

@unihodl/agent-sdk

TypeScript client — mint tokens, hydrate sessions

npm i @unihodl/agent-sdk

unihodl-agent

Python client

pip install unihodl-agent

RFC.md

The open Resume Token protocol spec

—

Related MCP server: Tabduct

Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "unihodl": {
      "command": "npx",
      "args": ["-y", "@unihodl/mcp-server"],
      "env": { "UNIHODL_API_KEY": "uh_test_sandbox_demo_key_v0" }
    }
  }
}

Restart Claude. The resume and list_sessions tools appear. Ask it to resume ses_8f3aZ91b and it receives the human's conclusions, open blockers, and intended next step — then continues the work.

Why it exists

Agent memory is well-funded, but it standardizes agent-generated memory. Nothing standardizes the human's live working context crossing into an agent — the 15 tabs, the half-formed decision, the thing you were about to do next. That handoff is the protocol. See RFC.md for the token design (EdDSA-signed, scope-filtered, TTL-capped, revocable, audited).

We're proposing Resume Tokens as an open standard — issues and PRs welcome. The goal is for every agent framework to accept a Resume Token, the way every framework now speaks MCP.

Get a live key

Free for 10,000 hydrations/month at unihodl.app/developers. Verify your key against the live API: https://www.unihodl.app/.well-known/jwks.json.

License

MIT — see LICENSE.

Available Tools

2 tools
list_sessionsA
Read-onlyIdempotent

List sessions in the workspace the configured API key can read, newest first, with cursor pagination. Read-only, no side effects. Returns {sessions: [{session_id, title, summary, captured_at, ai_tags}], next_cursor}. Pass any session_id to the resume tool for the full context; pass next_cursor back as cursor to fetch the next page (null means no more pages). Use this to discover what the human was working on when you do not already have a session_id — if you have one, call resume directly. Sandbox keys see the demo workspace. Errors: a malformed cursor or since value returns an error stating the expected format.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of sessions to return, between 1 and 50. Values outside the range are clamped rather than rejected.
cursorNoOpaque pagination cursor from a previous response's next_cursor. Omit to start from the newest session. Malformed cursors are rejected with an error.
sinceNoOnly return sessions captured at or after this ISO 8601 timestamp, e.g. '2026-06-01T00:00:00Z'.

Output Schema

ParametersJSON Schema
NameRequiredDescription
sessionsYesSessions, newest first.
next_cursorYesPass back as `cursor` to fetch the next page; null when there are no more pages.

TDQS

A4.9/5.0
Behavior5/5

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

The description adds significant behavioral context beyond annotations: read-only and no side effects are stated, pagination mechanics are detailed, return shape is given, error handling for malformed cursors or since values is explained, and sandbox key behavior is noted. Annotations already indicate read-only and idempotent, so this adds more value.

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

Conciseness5/5

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

The description is extremely concise, using three sentences to convey purpose, usage, return data, and errors. Every sentence adds value, and the most critical information (purpose and when to use) is front-loaded.

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

Completeness5/5

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

Given that annotations cover safety (read-only, idempotent) and the input schema is fully described, the description adds all necessary behavioral and usage context. Return type is described, error conditions are noted, and the relationship to sibling tool is clarified. The tool is fully 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 100%, with descriptions for limit, cursor, and since. The description adds value by explaining how to use the cursor (pass next_cursor back as 'cursor') and that since expects ISO 8601 format. This goes beyond the schema's basic descriptions.

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?

The description clearly states the tool lists sessions in the workspace, sorted newest first, with cursor pagination. It distinguishes itself from the sibling tool 'resume' by specifying that this tool is for discovering sessions when no session_id is known, while resume is for directly accessing a known session.

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?

Explicitly states when to use this tool (when you do not have a session_id) and when to use the alternative (resume if you have one). Also provides clear instructions on pagination: pass next_cursor back as 'cursor' and that null means no more pages.

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

resumeA
Read-onlyIdempotent

Fetch a UNIHODL session as Resume Context — the human's open tabs, scroll positions, video timestamps, AI-tagged decision thread, partial conclusions, and intended next step. Read-only and idempotent: it never modifies the session. Use it when you have a session_id (from list_sessions or the user) and need the human's working context before continuing their task; to discover sessions instead, use list_sessions. Returns a prompt-ready text block by default, or the raw Resume Context object with format 'json'. Errors: a malformed session_id is rejected before any network call; an unknown, expired, or revoked session returns an error message stating the reason.

ParametersJSON Schema
NameRequiredDescriptionDefault
session_idYesUNIHODL session id in the form ses_<alphanumeric>, e.g. 'ses_8f3aZ91b'. Obtain one from list_sessions or from the user. Ids that do not match the pattern are rejected without a network call.
formatNo'prompt-ready' (default): a structured natural-language block ready to inject directly into model context. 'json': the raw Resume Context object for programmatic use (schema: https://www.unihodl.app/sdk/spec).prompt-ready

TDQS

A4.8/5.0
Behavior5/5

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

The description adds behavioral context beyond annotations: 'Read-only and idempotent: it never modifies the session'. It also details error behavior (malformed id rejected before network call, unknown/expired/revoked session returns error message). This complements the annotations which already include readOnlyHint, destructiveHint, idempotentHint, and openWorldHint.

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

Conciseness5/5

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

The description is concise and well-structured. It starts with the core purpose, then details contents, behavioral properties, usage guidance, format options, and error handling. Every sentence adds necessary information without redundancy.

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

Completeness5/5

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

Given the tool's complexity (fetches multiple context items) and no output schema, the description provides a complete picture: what is returned (prompt-ready text or raw JSON object), error conditions, and integration with sibling tools. It covers all essential aspects for an AI agent to correctly invoke the tool.

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

Parameters5/5

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

With 100% schema description coverage, the description still adds value: it explains the session_id pattern and how to obtain one, and clarifies the 'format' parameter with use cases for 'prompt-ready' and 'json', including the default and a reference to the JSON schema. This goes beyond the schema descriptions.

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?

The description clearly states the tool's purpose: 'Fetch a UNIHODL session as Resume Context'. It specifies the content (open tabs, scroll positions, etc.) and distinguishes from sibling tool list_sessions by noting that this tool is for fetching context given a session_id, while list_sessions is for discovering sessions.

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?

The description explicitly states when to use the tool: 'Use it when you have a session_id... and need the human's working context before continuing their task'. It also directs to list_sessions for session discovery. While it doesn't explicitly state when not to use it, the context is clear.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.6/5.0
Disambiguation5/5

Each tool has a clear, distinct purpose: list_sessions discovers available sessions, while resume fetches details of a specific session. There is no overlap or ambiguity between them.

Naming Consistency4/5

Both tools follow a verb_noun pattern (list_sessions, resume), though 'resume' is a single verb without an explicit noun. The naming is mostly consistent and readable.

Tool Count3/5

With only 2 tools, the server is on the lower end of reasonable scope. It covers the basic read operations for sessions but feels minimal; additional tools like searching or filtering might be expected.

Completeness3/5

The server provides essential read functionality (listing and resuming sessions) but lacks any mutation operations or advanced filtering, leaving notable gaps for full session management.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/FutureEnterprises/unihodl'

If you have feedback or need assistance with the MCP directory API, please join our Discord server