Narrareach

Request a Substack code

start_substack_verification

Request verification for the selected Substack connection after its owner asks to continue. Returns an email or authenticator code prompt, or verified: true when Substack confirms without a code. Confirmation can resume previously approved articles waiting on this connection. Does not create a new schedule. Check existing article status before retrying. When a code is needed, ask in a normal chat message, end your turn, and wait for the user’s reply. If a code prompt closes without an answer, keep waiting in the conversation; do not request another code or retry publishing.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "connectionId": "<connectionId>"
    },
    "name": "start_substack_verification"
  }
}

Input Schema

Name	Required	Description	Default
`connectionId`	Yes	The exact Substack connection from the publishing response or get_user_profile.
`scheduledPostId`	No	The exact saved article job from the publishing response. Pass it to resume that same job after verification.

Output 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 changedNov 2, 2026
- addedOutput schema / properties / articleRecovery / properties / failed
```
Added value: +{
+  "type": "integer"
+}
```
- addedOutput schema / properties / articleRecovery / properties / followUp
```
Added value: +{
+  "const": "check_status",
+  "type": "string"
+}
```
- addedOutput schema / properties / articleRecovery / properties / succeeded
```
Added value: +{
+  "type": "integer"
+}
```

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 10, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations only give the generic profile (readOnly=false, openWorld=true, idempotent=false, destructive=false); the description adds genuinely non-derivable behavior: two possible return shapes (code prompt vs verified: true), the side effect of resuming previously approved articles waiting on the connection, and the waiting protocol when a prompt closes unanswered. That is exactly the context annotations cannot carry.

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 purpose and outcome, then the guardrails, which is the right order. Seven sentences is on the long side and the retry guidance is split across two locations ('Check existing article status before retrying' and 'do not request another code or retry publishing'), which could have been consolidated.

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?

With an output schema covering return values and annotations covering the safety profile, the description fills the remaining gaps: prerequisites, side effects on pending articles, and the multi-turn interaction protocol. Nothing an agent needs to invoke this correctly 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 coverage is 100% and both parameters already document that connectionId must be the exact connection and scheduledPostId resumes the same job. The description's phrase 'previously approved articles waiting on this connection' restates the resume semantics the schema already provides, adding no new syntax, format, or constraint.

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?

States a specific verb and resource ('Request verification for the selected Substack connection') and clarifies it is the initiation step, returning either a code prompt or verified: true. That implicitly separates it from complete_substack_verification and get_substack_verification_status, but those siblings are never named, so an agent must infer the boundary rather than read it.

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?

Explicit preconditions ('after its owner asks to continue'), explicit exclusions ('Does not create a new schedule', 'do not request another code or retry publishing'), and an explicit workflow for the code path ('ask in a normal chat message, end your turn, and wait for the user's reply'). The when-not cases are as specific as the when cases.

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?