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. When at_email_thread_cap is true the drawing shows each workspace's newest email threads only and older threads are left out.

This tool reads only — it changes nothing.

Input 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.
workspace_scopeNoRestrict this call to the family: the token's primary workspace plus the company workspaces under it that you are a member of. Unrelated authorized workspaces drop out of the read; row reads merge across the family, while a per-workspace figure still reports exactly one workspace.

Output 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.
newly_connectedNoTools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. The connected-line rule says when to tell an entry; when it does, one line per entry, in the person's language: "<name> is connected.". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later.
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.
at_email_thread_capNoTrue when older email threads were left out because a workspace held more than the per-workspace email thread cap. The drawing shows each workspace's newest threads only.
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. Changed4 schema fields changed
    • removedOutput schema / properties / own_company_id / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / own_company_id / type
      Added value: +[
      +  "string",
      +  "null"
      +]
    • removedOutput schema / properties / resolved_workspace / properties / name / anyOf
      Removed value: -[
      -  {
      -    "type": "string"
      -  },
      -  {
      -    "type": "null"
      -  }
      -]
    • addedOutput schema / properties / resolved_workspace / properties / name / type
      Added value: +[
      +  "string",
      +  "null"
      +]
  2. Changed1 schema field changed
    • changedOutput schema / properties / newly_connected / description
      Previous value: -"Tools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. Start the reply with one line per entry, in the person's language: \"<name> is connected.\". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later."New value: +"Tools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. The connected-line rule says when to tell an entry; when it does, one line per entry, in the person's language: \"<name> is connected.\". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later."
  3. Changed1 schema field changed
    • addedInput schema / properties / workspace_scope
      Added value: +{
      +  "description": "Restrict this call to the family: the token's primary workspace plus the company workspaces under it that you are a member of. Unrelated authorized workspaces drop out of the read; row reads merge across the family, while a per-workspace figure still reports exactly one workspace.",
      +  "enum": [
      +    "family"
      +  ],
      +  "type": "string"
      +}
  4. Changed2 schema fields changed
    • addedOutput schema / properties / at_email_thread_cap
      Added value: +{
      +  "description": "True when older email threads were left out because a workspace held more than the per-workspace email thread cap. The drawing shows each workspace's newest threads only.",
      +  "type": "boolean"
      +}
    • addedOutput schema / properties / newly_connected
      Added value: +{
      +  "description": "Tools that connected to this workspace since the last result and that no session was told about yet, oldest first. Present only when at least one tool is new. Start the reply with one line per entry, in the person's language: \"<name> is connected.\". Never fold several entries into one sentence. Each entry comes back once, on one result only: never repeat its line later.",
      +  "items": {
      +    "additionalProperties": false,
      +    "properties": {
      +      "name": {
      +        "type": "string"
      +      },
      +      "service_id": {
      +        "type": "string"
      +      }
      +    },
      +    "required": [
      +      "name",
      +      "service_id"
      +    ],
      +    "type": "object"
      +  },
      +  "type": "array"
      +}
  5. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly, non-destructive, closed-world), and the description adds substantial behavior beyond that: the graph renders in a card while the text result carries only counts, and it explains the at_company_cap and at_email_thread_cap truncation states and how to phrase them honestly. That is exactly the kind of output/limits disclosure an agent needs to avoid misdescribing the view.

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?

Front-loaded with the action and its visual form, then usage triggers, then caveats about caps. Slight waste in 'This tool reads only — it changes nothing,' which duplicates readOnlyHint, but the rest of the text is dense and purposeful.

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?

For a 7-parameter rendering tool with an output schema, the description covers what it draws, when to call it, how to narrow it, what the text result contains, and the two truncation caveats. Nothing an agent needs in order to call it and narrate the result is missing.

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% and every parameter is already documented with enums, so the schema carries the semantic load. The description restates the narrowing role of perspective, time_window, min_degree and company_cap but adds no new syntax or defaults, and says nothing about workspace_id, workspace_scope or conversation_id. Baseline 3 applies.

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?

States a specific verb and resource: draws the workspace's context graph (companies, people, accounts, transactions, connectors) as an interactive canvas. The enumeration of node types plus the rendering medium makes it clearly distinct from data-returning siblings such as well_get_computed_figures or well_search_context.

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?

Gives concrete triggers: '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.' It also explains how to narrow the drawing via perspective, time_window, min_degree and company_cap. It does not explicitly name a sibling to use instead (e.g. well_show_record_graph_summary), so it stops short of full routing guidance.

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