A
licenseA
qualityA
maintenanceHeadless WorkPaper MCP server for spreadsheet formulas, workbook edits, JSON persistence, and verified readback from TypeScript services.
7
35
MIT
mallory-grapher
by johnhenry
Run a headless, agent-drivable reactive compute-graph session server over MCP (stdio or HTTP) — no DOM/React — where agents can create sessions, set/get/list cells, and define computed cells.
session_open: start a
genericorgraph-theorysession; optionally seed initial input cell values.session_close / session_list: close sessions and list open sessions with kind, cell count, and creation time.
session_set_cell: set an input cell to any JSON value; setting a computed cell demotes it to input, and dependents recompute lazily.
session_get_cell: read a cell’s value, recomputing if stale; rich values project to typed JSON (e.g.,
{"$type":"graph", ...}).session_list_cells: show all cells with role (
freevscomputed) and the op defining computed cells.session_define: declare computed cells from a catalog, using literal args or
{"$cell":"name"}live references for reactive dependencies.Built-in ops:
math_eval(symbolic math),graph_parse_edge_list,graph_analyze,graph_bfs,graph_dfs, andgraph_dijkstra.Operational controls: sessions are in-memory, permissions can be granted per-session, and resource limits (sessions/cells/eval budget/payload) are configurable via environment variables.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@mallory-grapherstart a headless session and compute 5 * 7 = ?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
math-grapher
Full documentation: opensource.johnhenry.me/math/math-grapher
A headless, DOM-less session runtime for the @johnhenry/math family's reactive
compute graph (CellGraph), agent-drivable over MCP.
Why this exists
mallory's (the graphing-calculator app, formerly mallory-graph)
in-page WebMCP tools (useCellGraphTools:
${prefix}_list_cells/get_cell/set_cell) already let an agent drive a
live, reactive CellGraph — but only from inside a rendered browser tab.
The server-side MCP endpoint mallory ships today (@johnhenry/math-plus-mcp,
math-plus's packages/mcp) only covers stateless math tools
(Symbolic eval, guarded tensor/linalg) plus read-only, serialized
gallery access (gallery_list/gallery_get read NotebookState.blocks[]
JSON — no computed/derived-cell evaluation, no reactivity).
Real session parity — "an agent could run an entire modeling session headlessly" — means running the reactive compute graph itself server-side, with no DOM/React tree at all. That's a materially different, bigger project than either of the above, so it lives here instead of inside mallory.
Split out of mallory#163
after that issue's own audit trail: a feasibility spike
(cell-graph-headless-spike.test.ts) already confirmed CellGraph itself
has zero window/document references — set/define/get/
subscribe/subscribeAll are plain data-structure + closure code. What
doesn't exist yet is the actual session API around it.
Related MCP server: chuk-mcp-runtime
Relationship to mallory
Optional, not coupled. math-grapher does not depend on
mallory (the app), and mallory does not need to depend on
math-grapher to function. mallory may choose to mount a
math-grapher-backed MCP route the same way it mounts @johnhenry/math-plus-mcp
today (src/routes/api.mcp.ts) — a separate integration issue, not a
prerequisite for this repo to exist or ship v1.
Concretely, this repo owns:
The headless session runtime (open a session, drive its cells, read results) — no rendering, no React, no DOM.
An MCP tool surface over that runtime.
It deliberately does NOT own:
Canvas/WebGL rendering — session parity is about the same get/set/list contract WebMCP already gives an in-page agent, not pixels.
mallory's specific panel components, gallery storage, or UI.
What's known so far (carried over from #163's audit)
CellGraph's core (cell-graph.tsin mallory, ~500 lines) has no structural blocker to running headless — proven empirically, not just asserted.Most panels'
useXGraph()seed step readswindow.location.hash/getComputedStylefor URL-state hydration and theming. Both are already guarded withtypeof window !== "undefined"checks (existing SSR-safety code), so they degrade gracefully rather than crash — but a real agent-drivable session needs a way to seed state from something other than a browser's URL bar (an MCP tool argument, presumably).Write-path auth precedent: mallory's
gallery_savetool (#163 item 1, shipped) is gated OFF by default behind an explicit env var (MALLORY_GRAPH_ENABLE_MCP_WRITE=1), mirroringllmtm'sLLMTM_HUB_ENABLE_*convention. A session-runtime write surface should follow the same default-off, explicit-opt-in posture.
Status
v1 implemented. docs/design.md is the settled design; the session runtime, op catalog, MCP tool surface, and both transports are built and tested.
Usage
# stdio (the transport MCP hosts speak natively -- e.g. `claude mcp add`)
npx @johnhenry/math-grapher
# Streamable HTTP on http://localhost:3920/mcp (or a custom port)
npx @johnhenry/math-grapher --http
npx @johnhenry/math-grapher --http 8123Tools: session_open (kind generic or graph-theory), session_close,
session_list, session_set_cell, session_get_cell,
session_list_cells, session_explain_cell (a cell's own op/args/
immediate dependencies with their current values, one level -- issue #5),
session_snapshot/session_resume (serialize a session's free-cell
values + define-specs; reconstruct an equivalent session, possibly on a
different process -- issue #6), session_define. Computed cells are
declared as
JSON define-specs over a server-side op catalog (math_eval,
graph_parse_edge_list, graph_analyze, graph_bfs/dfs/dijkstra)
with {"$cell": "name"} live references — see
docs/design.md §5. An op MAY declare a
requiresCapability (issue #7); session_define rejects it unless
session_open/session_resume's own optional capabilities arg granted
it for that session (default none — matching the existing write-path
gating precedent below, just per-op instead of one global switch). No op
in the catalog above declares one yet.
Resource guards default modest and are overridable:
MATH_GRAPHER_MAX_SESSIONS (16), MATH_GRAPHER_MAX_CELLS (512),
MATH_GRAPHER_EVAL_BUDGET_MS (250), MATH_GRAPHER_MAX_PAYLOAD_BYTES
(262144).
Available Tools
7 toolssession_closeB
Close a session and free its cells.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes |
TDQS
B3.2/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does communicate a main effect—freeing cells—but it does not disclose whether the session must be active, whether this is destructive/reversible, or what happens to unsaved state.
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 entire description is one short, front-loaded sentence. It includes the core action and a meaningful side effect with no wasted words.
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?
This is a simple one-parameter, no-output-schema tool, so a brief description can be acceptable. However, the lack of annotations and lack of state/error/return context leave only a minimal viable level of completeness.
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?
The only parameter, sessionId, has no description coverage, and the description does not explain it or mention how the ID should be obtained. The parameter name is self-explanatory enough for basic inference, but the description adds no value beyond the schema.
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 uses a specific verb and object: 'Close a session', and adds meaningful scope with 'free its cells.' This clearly distinguishes it from siblings like session_open, session_list, and session_set_cell.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool, when not to use it, or what alternatives exist. It does not mention whether it should be used only after a session is no longer needed, nor does it reference sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
session_defineA
Define a computed cell from a catalog op. args values may be literal JSON or live cell references ({"$cell": "name"}) -- referenced cells become reactive dependencies, so the cell recomputes when they change. Available ops:
math_eval: Evaluate a mallory-math Symbolic expression string over named numeric variables. args: { expr: string, vars?: { name: number | {"$cell": ...} } }. value: number.
graph_parse_edge_list: Parse a
from to [weight]-per-line edge list into a graph value. args: { text: string, directed?: boolean (default true) }. value: graph (opaque; project with session_get_cell).graph_analyze: Structural analysis of a graph cell. args: { graph: graph }. value: { hasCycle, connectedComponents, stronglyConnectedComponents, topologicalOrder, adjacencyMatrix: { matrix, order } }.
graph_bfs: Breadth-first traversal order. args: { graph: graph, start: string }. value: string[].
graph_dfs: Depth-first traversal order. args: { graph: graph, start: string }. value: string[].
graph_dijkstra: Dijkstra shortest-path distances from a start vertex. args: { graph: graph, start: string }. value: [{ vertex, distance }].
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| op | Yes | ||
| args | Yes | ||
| cell | Yes | ||
| sessionId | Yes |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses reactive dependencies via live cell references, explains each op's output format, and notes that graphs are opaque and must be projected via session_get_cell. It lacks explicit mention of overwrite semantics or failure modes, but for a define operation it provides solid transparency.
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 long but well-structured as a bulleted list of ops, each with args and value. It avoids fluff, front-loads the core purpose, and every sentence adds information. The length is justified by the breadth of operations; nothing is redundant.
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?
Given the tool's complexity (multiple ops, nested args, no output schema), the description is remarkably complete: it specifies all ops, their parameters, return shapes, and the reactive behavior. It lacks error handling or edge-case notes, but for an operation that defines computed cells, it provides sufficient detail for correct invocation.
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 0%, so the description must compensate. It thoroughly explains 'op' and 'args' for each catalog operation, including argument structures and return types. However, 'sessionId' and 'cell' parameters are not explicitly described; sessionId is left to inferred context, and cell is only implicitly defined as the computed cell's name. Still, the heavy lifting for the most complex parameters is complete.
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 opens with a specific verb+resource: 'Define a computed cell from a catalog op.' It clearly distinguishes from siblings like session_set_cell (literal value) and session_get_cell (retrieve), and enumerates the exact operations available, leaving no ambiguity about what the tool does.
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 implies usage for computed cells and details each op's arguments and return values, effectively guiding selection among ops. It does not explicitly contrast with session_set_cell for static values or state when this tool should not be used, but the context is clear enough for an agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
session_get_cellB
Read a cell's current value (recomputing it if stale). Rich values project to typed JSON (a graph cell returns { "$type": "graph", vertices, edges, directed }).
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cell | Yes | ||
| sessionId | Yes |
TDQS
B3.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full transparency burden. It reveals a key behavioral trait—recomputing stale values—rather than presenting a plain read, and explains rich-value projection with a concrete graph example. It does omit error/edge behaviors, but the core side-effectful recomputation is explicitly disclosed.
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 a single, front-loaded sentence with a compact illustrative parenthetical. Every clause earns its place: the core read behavior, the stale recomputation side effect, and a concrete example of the rich JSON output. No filler or restatement of the name.
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 a two-parameter reader, it covers the critical behaviors (stale recompute and typed JSON projection). However, it doesn't explain the basic return format for non-rich cells, the session-open prerequisite, or failure behaviors. Since there is no output schema and no annotations, the description carries a heavier burden that it only partially satisfies.
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% and the description does not compensate: it never explains the semantics of sessionId or cell, how cells are referenced, or what format is expected. The parameter names are somewhat self-explanatory, but the description adds no operational meaning beyond the schema.
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 provides a concrete action and target: 'Read a cell's current value'. It is distinct from the sibling set_cell/write operations in effect, though it does not explicitly name alternatives. The additional detail about recomputing stale values further clarifies intended semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus siblings like session_set_cell or session_list_cells. It implies a read operation but does not state prerequisites, exclusions, or alternative conditions. This leaves the agent to infer usage purely from the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
session_listA
List open sessions with kind, cell count, and creation time.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It makes the read-only list behavior clear and discloses the returned attributes, but it does not mention ordering, pagination, or other behavioral details such as whether closed sessions are excluded.
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 a single, well-structured sentence that starts with the action and immediately delivers the key semantic information. Every word is meaningful, with no redundancy or boilerplate.
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?
As a straightforward zero-parameter list tool with no output schema, the description is largely complete: it identifies the resource and the returned fields. A brief note on ordering or cell-level access would improve completeness, but the current information is sufficient for basic selection.
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?
The tool has zero parameters, which matches the baseline of 4 for tools without parameters. The description needs to explain parameter-level semantics, and it does so implicitly by defining the scope of the returned list.
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 uses a specific verb ('List') plus a specific resource ('open sessions') and even names the returned fields: kind, cell count, and creation time. This clearly communicates what the tool does and distinguishes it from sibling tools like session_list_cells, which operate on cells rather than sessions.
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?
The description gives clear context for when to use this tool—when you need a list of open sessions and their basic metadata. However, it does not explicitly state when not to use it or point to alternatives like session_list_cells for cell-level information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
session_list_cellsA
List every cell in a session with its role ("free" input vs "computed") and, for computed cells, the op that defines it.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes |
TDQS
A3.6/5.0
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the output structure (role and op) but does not explicitly state that the operation is read-only, whether session must be open, or error behavior. The 'List' verb implies safety, but more could be added.
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 a single sentence that is front-loaded with the verb 'List' and immediately conveys the key details. No filler or redundancy.
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 a simple tool with one parameter and no output schema, the description covers the main function and return values, but lacks prerequisite context (e.g., session must be open) and parameter clarification. It's adequate but not fully complete.
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%, and the description does not explain the sessionId parameter. While the name is self-explanatory, the description fails to specify that it references an existing session or how to obtain it, leaving a gap.
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 every cell in a session, specifying the information returned (role and op for computed cells). This distinguishes it from siblings like session_get_cell (single cell) and session_list (sessions).
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?
The description implies usage for viewing all cells in a session, but it doesn't explicitly mention when to use this over alternatives like session_get_cell. Sibling names provide context, but no direct guidance or exclusion is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
session_openA
Open a reactive cell session. kind "generic" starts empty; "graph-theory" pre-wires an edge-list -> analysis -> BFS pipeline (input cells: edgeListText, directed, startVertex; computed cells: parsed, analysis, bfsOrder). Optional seed sets input cells in the same call (overriding preset defaults). Sessions are in-memory and die with the server.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| kind | Yes | ||
| seed | No |
TDQS
A4.3/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses key behavioral facts: sessions are reactive, in-memory, die with the server, and 'seed' overrides preset defaults. It omits the return/handle semantics, but the core side effects and lifecycle are clearly stated.
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?
Three dense sentences present the main action first, then conditional details, then lifecycle; no filler words. The graph-theory specifics are compressed into a parenthetical list without losing 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?
The description richly covers parameters and lifecycle, but because there is no output schema it should mention what session_open returns (e.g., a session handle/id) to support chaining with sibling session tools. That missing return-value contract keeps it from being fully complete.
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?
The schema provides only enum names and an open object with no descriptions (0% coverage), so the description compensates by explaining each kind's behavior and what seed does. It could specify seed's shape/keys more explicitly, but the stated semantics are actionable.
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 uses a specific verb ('Open') and resource ('reactive cell session'), and elaborates the two kinds ('generic' and 'graph-theory') with their exact cell setups. This clearly separates it from siblings like session_list_cells or session_close.
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?
It provides clear context for when to use the tool: starting a session, with explicit guidance on choosing 'generic' vs 'graph-theory' and how optional seed behaves. It does not spell out when-not-to-use or name alternatives, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
session_set_cellA
Set an input cell's value (any JSON). Setting a previously-computed cell demotes it to a plain input. Dependent computed cells recompute lazily on their next get.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cell | Yes | ||
| value | No | ||
| sessionId | Yes |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral transparency. It discloses two important side effects: demotion of computed cells to plain inputs and lazy recomputation of dependent cells. This is solid, though it omits potential edge cases like whether the session must be open.
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 two sentences, front-loaded with the main action and immediately followed by important behavioral details. Every sentence adds value with no filler or redundancy.
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?
The description covers the core action and key side effects, which is good for a simple setter. However, it omits sessionId semantics, the optional nature of value, and error/edge-case behavior, making it not fully complete for an unannotated tool without an output 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?
With 0% schema description coverage, the description must explain all parameters, but it does not mention sessionId at all. It also says 'Set an input cell's value,' implying value is required, while the schema marks value as optional, creating ambiguity about whether a value must be provided.
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 primary action: 'Set an input cell's value (any JSON).' It also distinguishes the tool from siblings like session_get_cell and session_define by explicitly mentioning the behavior for computed cells, making the scope and effect unambiguous.
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 gives useful usage context by explaining that setting a previously-computed cell demotes it to a plain input and that dependents recompute lazily. It implies when the tool is appropriate, though it does not explicitly name alternative tools or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
7 tool updates
v0.0.0- First observed
session_close - First observed
session_define - First observed
session_get_cell - First observed
session_list - First observed
session_list_cells - First observed
session_open - First observed
session_set_cell
TDQS
A4/5.0
Disambiguation5/5
Each session_ tool targets a distinct resource-action pair: listing sessions vs listing cells, setting vs getting cells, opening vs closing sessions. The overlapping terms 'session' and 'cell' are disambiguated by the noun and verb combination, leaving no ambiguity.
Naming Consistency5/5
All tools follow a strict 'session_' pattern with verb-noun structure (open, close, list, set_cell, get_cell, define, list_cells). The convention is uniform and predictable, making it easy to infer functionality from the name.
Tool Count5/5
With 7 tools, the set is well-scoped for the session-based reactive cell domain. Each tool serves a distinct purpose covering session management and cell operations without redundancy or bloat.
Completeness4/5
The tool surface covers the full session lifecycle (open, list, close) and cell operations (set, get, list cells, define). A minor gap is the absence of a direct 'delete cell' operation, but existing tools (set_cell demoting computed cells) mitigate this limitation, so agents can work around it.
Maintenance
ActivityMaintained
ResponsivenessResponsive
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
Hosted MCP memory and agent control plane for durable conversations, jobs, and operations.
Hosted runtime for persistent agent teams, durable workflows, memory, schedules, and goals.
Private-by-default, local-first memory/context/task orchestrator for MCP apps and agents.
Create, browse, remix, collaborate on, and run durable AI workflow nodes from MCP hosts.
Related MCP Servers
chuk-mcp-runtimeofficial
AlicenseNot gradedqualityBmaintenanceA robust runtime for the official Model Context Protocol (MCP) that adds proxying, session management, JWT auth, persistent user storage with scopes, and progress notifications.9Apache 2.0- AlicenseNot gradedqualityBmaintenanceExposes the Nodus orchestration runtime as MCP tools for memory management, goal/workflow execution, and sandboxed code execution.MIT
- FlicenseNot gradedqualityCmaintenanceA production-oriented MCP runtime providing orchestration tools for IDE and agent integrations, including task management, diagnostics, and token usage reporting.-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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/johnhenry/math-grapher'
If you have feedback or need assistance with the MCP directory API, please join our Discord server