mallory-grapher

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.0.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.
Average 3.8/5 across 7 of 7 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 13 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

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.
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.
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.
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.
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.
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.
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![mallory-grapher MCP server](https://glama.ai/mcp/servers/johnhenry/mallory-grapher/badges/card.svg)](https://glama.ai/mcp/servers/johnhenry/mallory-grapher)

Score Badge

Copy to your README.md:

[![mallory-grapher MCP server](https://glama.ai/mcp/servers/johnhenry/mallory-grapher/badges/score.svg)](https://glama.ai/mcp/servers/johnhenry/mallory-grapher)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/mallory-grapher'

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