Nexus Catalyst

Create or update Linear records

integration_mutate

Destructive

Linear actions that CREATE OR MODIFY records: issues, projects, labels, comments, and the memory↔issue cross-reference rows. Every action here writes. Use integration_query for reads.

Actions: create_linear_project, save_linear_issue, create_linear_issue, create_linear_label, update_linear_label, create_linear_comment, auto_create_linear_issue, cross_reference_linear_memory, link_memory_to_linear_issue, update_ticket_from_memory.

Pass workspace to select the Linear workspace when more than one is connected.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`action`	Yes	The action to perform.

Output Schema

TableJSON Schema

Name	Required	Description
`data`	No	Per-action payload. Deliberately an open object: the action list is derived at runtime and each action has its own shape.
`error`	No	Present when the call did not succeed. An object carries `type` and `message` (and often a `timestamp`); Utils.formatError bodies set it to `true` with the reason in the top-level `message`.
`message`	No
`success`	No
`timestamp`	No	Unix epoch (milliseconds on most rows, seconds on legacy rows) or an ISO-8601 string.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 25, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "Envelope shared by every Linear action: `success`, a human-readable `message`, and `data` whose shape depends on the action (e.g. `{ issue }` for get_linear_issue, `{ issues, total }` for search_linear_issues, `{ disambiguation_required, available_workspaces }` when a workspace must be named).",
+  "properties": {
+    "data": {
+      "additionalProperties": true,
+      "description": "Per-action payload. Deliberately an open object: the action list is derived at runtime and each action has its own shape.",
+      "type": "object"
+    },
+    "error": {
+      "description": "Present when the call did not succeed. An object carries `type` and `message` (and often a `timestamp`); Utils.formatError bodies set it to `true` with the reason in the top-level `message`.",
+      "type": [
+        "object",
+        "boolean",
+        "string"
+      ]
+    },
+    "message": {
+      "type": "string"
+    },
+    "success": {
+      "type": "boolean"
+    },
+    "timestamp": {
+      "description": "Unix epoch (milliseconds on most rows, seconds on legacy rows) or an ISO-8601 string.",
+      "type": [
+        "number",
+        "string",
+        "null"
+      ]
+    }
+  },
+  "type": "object"
+}

First observedSep 16, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already establish readOnlyHint=false and destructiveHint=true; the description adds behavioral context by emphasizing that 'every action here writes' and by naming the affected record types, including the less obvious 'memory↔issue cross-reference rows.' It does not detail side effects like overwrites or reversibility, but with destructiveHint already present, the added context is sufficient.

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 front-loaded with the core semantic ('CREATE OR MODIFY'), then a compact list of actions, then the workspace note. No filler; every sentence carries information an agent needs.

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 action selection and workspace disambiguation, but it lacks per-action parameter guidance (e.g., required fields for create_linear_issue vs create_linear_label). Given the open-world schema and ten actions, an agent may know which action to call but not how to populate the remaining arguments; output schema may compensate, but the description itself has this gap.

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 only describes 'action' generically as 'The action to perform.' The description adds the full list of action names and, crucially, documents the workspace parameter that is not present in the schema (via additionalProperties). This goes beyond the schema's shallow coverage.

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?

Description states a specific verb-resource pair ('Linear actions that CREATE OR MODIFY records') and enumerates all included actions (issues, projects, labels, comments, cross-reference rows). It explicitly differentiates from sibling integration_query by saying 'Use integration_query for reads.'

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?

The description gives an explicit exclusion: 'Every action here writes. Use integration_query for reads.' This tells the agent when to use this tool vs the read sibling. It also provides a conditional usage instruction: 'Pass workspace to select the Linear workspace when more than one is connected.'

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

All Nexus Catalyst tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?