Narrareach

Confirm your Substack connection

verify_substack

Destructive

Compatibility tool for existing connections. New clients can use get_substack_verification_status, start_substack_verification, complete_substack_verification, and cancel_substack_verification for individual operations. Confirm Substack without leaving this conversation or signing in again. Use the exact connectionId from the publishing response or get_user_profile. Check status first. When the user wants to continue, use start to request a code, then ask them for it here. If start returns verified: true, skip code entry. Ask in a normal chat message and wait for the user’s reply; if a prompt closes without an answer, keep waiting in chat without requesting another code. Use complete with the returned id and the code they provide. Never guess a code, repeat submissions automatically, or send the code to another tool. Only the connected account owner can confirm. After completion, poll the existing schedule if its ID is known. Otherwise promptly retry the same saved draft with the original settings; the scheduler checks for an existing matching schedule before creating one. Verification is not proof of scheduling or publishing.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	No	Code request id returned by start or status. Required for complete and cancel.
`code`	No	The six-digit code supplied by the user. Required only for complete. Never echo it back.
`action`	Yes
`connectionId`	Yes	The exact Substack connection to confirm.
`scheduledPostId`	No	The exact saved article job from the publishing response. Pass it to resume that same job after verification.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`id`	No
`method`	No
`message`	Yes
`required`	No
`verified`	No
`cancelled`	No
`challenge`	No
`expiresAt`	No
`connection`	No
`nextAction`	No
`instruction`	No
`publication`	Yes
`connectionId`	Yes
`articleRecovery`	No
`resumedArticles`	No
`scheduledPostId`	No
`connectedAccount`	No
`deliveryConfirmed`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 18, 2026

addedInput schema / properties / scheduledPostId

Added value: +{
+  "description": "The exact saved article job from the publishing response. Pass it to resume that same job after verification.",
+  "maxLength": 64,
+  "minLength": 1,
+  "type": "string"
+}

changedOutput schema / properties / challenge / anyOf

Previous value: -[
-  {
-    "additionalProperties": false,
-    "properties": {
-      "expiresAt": {
-        "format": "date-time",
-        "type": "string"
-      },
-      "id": {
-        "type": "string"
-      },
-      "method": {
-        "anyOf": [
-          {
-            "enum": [
-              "email",
-              "totp"
-            ],
-            "type": "string"
-          },
-          {
-            "type": "null"
-          }
-        ]
-      }
-    },
-    "required": [
-      "id",
-      "method",
-      "expiresAt"
-    ],
-    "type": "object"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "additionalProperties": false,
+    "properties": {
+      "expiresAt": {
+        "format": "date-time",
+        "type": "string"
+      },
+      "id": {
+        "type": "string"
+      },
+      "method": {
+        "anyOf": [
+          {
+            "enum": [
+              "email",
+              "totp"
+            ],
+            "type": "string"
+          },
+          {
+            "type": "null"
+          }
+        ]
+      },
+      "scheduledPostId": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "id",
+      "method",
+      "expiresAt"
+    ],
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

addedOutput schema / properties / scheduledPostId
```
Added value: +{
+  "type": "string"
+}
```

Changed2 schema fields changedOct 10, 2026
- addedOutput schema / properties / instruction
```
Added value: +{
+  "type": "string"
+}
```
- addedOutput schema / properties / nextAction
```
Added value: +{
+  "const": "wait_for_code",
+  "type": "string"
+}
```
AddedOct 9, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, non-idempotent, open-world. The description adds real behavioral context beyond them: the account-owner-only authorization requirement, the instruction not to auto-repeat submissions, the handling of closed prompts, and the caveat that 'Verification is not proof of scheduling or publishing.' It does not explain what the destructive flag actually destroys, which keeps it from a 5.

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 purpose and alternative tools are front-loaded before the workflow detail, and most sentences carry operational weight. It is a dense single paragraph, however, and the workflow/constraint sentences could be structured more scannably for a four-action tool.

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?

An output schema exists, so return values need no explanation. For a multi-action tool with 5 params, the description covers the full lifecycle (status, start, complete, cancel), the code-entry loop, failure handling, and post-completion scheduling behavior — everything an agent needs to invoke it correctly.

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 80%, so the baseline is 3. The description still adds value by telling the agent where connectionId comes from ('the publishing response or get_user_profile') and how scheduledPostId is used to 'resume that same job after verification' — sourcing and intent the schema does not state.

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 names a specific verb and resource ('Confirm Substack connection') and explicitly frames the tool as a compatibility wrapper for existing connections. It also names the four sibling tools (get/start/complete/cancel_substack_verification) that new clients should use for individual operations, so an agent can distinguish it from them without opening any schema.

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 gives explicit routing ('New clients can use ... for individual operations'), sequencing ('Check status first', 'use start to request a code'), and a clear step-by-step workflow through status/start/complete/cancel. It also states exclusions and anti-patterns ('Never guess a code, repeat submissions automatically, or send the code to another tool').

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

All Narrareach 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?