Skip to main content
Glama
Hardik-Singh

Invariance MCP

Official
by Hardik-Singh
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

invariance_session_create

Start a new agent session to contain a bounded chunk of work, such as a Claude Code task, meeting, recording, or note, so events and tool calls can be appended and linked to a run.

Instructions

Open a new agent-session — the canonical container for an operator's bounded chunk of work in the company brain. CALL THIS at the START of: a new Claude Code task (source='api'), a screen recording for a teammate (source='screen_recording'), a mic capture session (source='microphone'), a meeting (source='meeting'), ingestion of a Granola note (source='granola_note'), or a manual note-taking session (source='manual_note'). Events (transcript chunks, tool calls, screenshots, notes) are appended to this session via invariance_session_append_note or the events sub-route. Link a session to a run via agent_id+run_id (or call invariance_session_attach_run later).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleNoHuman-readable title for the session.
run_idNoOptional run ID to attach at creation time.
sourceYesWhat kind of activity stream this session represents. Use: - "api" for autonomous agent work, including a single Claude Code task / sub-agent invocation (one Claude Code session = one agent-session with source="api"). - "screen_recording" when capturing a human teammate's screen for the company brain. - "microphone" when capturing raw mic audio (e.g. a teammate thinking out loud at their desk). - "meeting" for a Zoom/Meet/in-person meeting with multiple participants. - "granola_note" when ingesting a Granola meeting note. - "manual_note" when a human or agent is jotting freeform notes into the brain.
agent_idNoOptional agent ID to associate with the session (for source="api" Claude Code work, this is the agent running the task).
metadataNoOptional metadata as a JSON object string. Example: {"participants":["alice@x.com"],"app":"granola"}
session_typeNoOptional finer-grained label, e.g. "claude_code", "standup", "1on1", "design_review".
external_session_idYesStable client-supplied ID for dedup (e.g. the Claude Code conversation ID, the meeting calendar event ID, the Granola note ID, the screen-recording file UUID). Reusing the same external_session_id for the same source returns the existing session.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A4.1/5.0
Behavior4/5

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

Beyond annotations, the description discloses dedup/upsert behavior with external_session_id + same source returns existing session, and explains that events/transcripts are appended through other routes. It also communicates the write semantics consistent with readOnlyHint=false without contradicting the annotations.

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 description is substantive but each sentence moves the agent forward: purpose, when to call, how it relates to event append, and linking options. It's longer than minimal, but it's accountable for 7 parameters and multiple sibling alternatives, so the length is justified.

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?

Despite no output schema, the description provides enough usage context: how to create, when to create, the dedup contract, and how to tie into runs. The main omission is an explicit description of the return value, but the purpose and parameters are largely covered.

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 description coverage is 100%, so the baseline is 3. The description adds some context around source semantics and explains linking via agent_id+run_id or attach_run later, but most param semantics are already fully documented in the schema, so the additional value is modest.

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 opening sentence states 'Open a new agent-session', giving a specific verb and resource, and immediately frames it as 'the canonical container' for a bounded work chunk. It further distinguishes the tool from its siblings by enumerating the six source contexts and contrasts it with append and attach operations.

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 says 'CALL THIS at the START of' and lists six concrete use cases (api, screen recording, mic capture, meeting, granola note, manual note), giving clear contextual guidance. It also names alternatives like invariance_session_append_note and invariance_session_attach_run, but it doesn't explicitly state when not to create a session, just implies it.

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