Skip to main content
Glama

Get workspace graph

well_get_graph
Read-only

Draw the workspace's context graph — its companies, people, accounts, transactions and connectors, and the connections between them — as an interactive canvas the user can orbit, zoom and hover.

Use it when someone asks to see how their business data connects, wants a picture of the workspace, or asks what a company or person is linked to. Narrow the drawing with perspective ("contacts", "money", "accounting"), time_window, min_degree (thin a dense workspace to its hubs) and company_cap.

The card renders the graph itself. This tool's text result reports only the counts, so say what the shape shows rather than listing nodes. When at_company_cap is true the drawing holds as many companies as the cap allows and the workspace may hold more — say the view is capped rather than describing it as the whole graph.

This tool reads only — it changes nothing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
min_degreeNoDrop nodes with fewer than this many connections. Raise it to thin a dense workspace down to its hubs; 0 keeps every node.
company_capNoCap the number of company nodes drawn. Omit for the server's unbounded default.
perspectiveNoWhich slice of the graph to draw. "all" is everything; "contacts" is people and companies; "money" is transactions and accounts; "accounting" is the ledger side. Defaults to the server's own default when omitted.
time_windowNoHow far back to reach for the underlying records. Defaults to the server's own default when omitted.
workspace_idNoTarget workspace. Omit when the token authorizes one workspace. Required when it authorizes several: this read reports one workspace's own figures and will not choose which.
conversation_idNoThe conversation id returned by the previous Well result, in its meta under well/conversation_id, in its structuredContent, or in its JSON text block. Pass it back on every call in the same conversation, including a call a card makes, so the chosen workspace and the earlier answers still apply. It decides the conversation on its own: nothing the host states about the session replaces it. Omit it only on the first call of a conversation.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
errorNo
successYes
edge_countNoConnections between the shipped nodes.
node_countNoNodes the server actually shipped, after every filter.
company_capNoThe company cap the server applied, when one was.
failed_countNoOpen work that cannot progress on its own: stuck tasks and errored connectors.
at_company_capNoTrue when the drawing holds as many company nodes as the cap allowed, so the workspace may hold companies it does not show. It is not a count of what was left out — the projection carries no dropped-row signal.
own_company_idNoThe workspace's own company node, when one is resolved.
conversation_idNoThe conversation this result belongs to. Pass it back as the conversation_id argument on every later Well call in the same conversation.
processing_countNoOpen work that may still change the scene: queued or running tasks, plus connectors mid-sync.
resolved_workspaceNoThe workspace that answered, when the caller named none and the token authorizes several.
conversation_id_noteNoPresent only when the server opened a fresh lane, stating that no choice recorded earlier was read.
conversation_id_sourceNoWhere the conversation id came from: the host's own request meta, the caller's argument, or a fresh lane the server opened.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description doesn't need to repeat that. It adds valuable context: the tool is read-only (stated), the text result reports only counts (not node listings), and the at_company_cap behavior is disclosed. This goes beyond annotations to explain how to interpret results, which is critical for correct agent behavior.

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 well-structured: first sentence defines the tool's core purpose, followed by usage conditions, then guidance on interpreting results, and finally a clear read-only statement. It's front-loaded with the most important info and every sentence earns its place. No fluff or 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 has an output schema, the description doesn't need to detail return values. It covers the key aspects: what the tool does, when to use it, how to adjust output via parameters, how to interpret results (counts vs graph), and the at_company_cap edge case. The parameters are well-documented in the schema, and the description fills the behavioral gaps. For a visualization tool, this is complete.

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 coverage is 100%, so parameters are fully documented in the schema. The description adds context on how to use them (e.g., 'thin a dense workspace to its hubs' for min_degree, 'narrow the drawing' for perspective), but this is complementary rather than essential. For a tool with 6 well-described params, the baseline 3 is appropriate since the schema does the heavy lifting.

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 draws the workspace's context graph (companies, people, accounts, etc.) and visualizes connections. It distinguishes itself from siblings like well_get_entity or well_search_context by focusing on the graph visualization. The verb 'draw' and resource 'context graph' are specific and unambiguous.

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?

It explicitly states when to use: when someone asks to see how business data connects or wants a picture of the workspace. It also lists narrowing parameters (perspective, time_window, min_degree, company_cap) and provides behavioral guidance on what to say when at_company_cap is true. It implies when not to use (e.g., for specific entity details) by contrasting with the graph's scope.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources