Skip to main content
Glama

get_note_thread

Read-only

Read a public Substack Note thread by comment ID to retrieve the Note, its ancestors, and available replies, with explicit truncation markers when limits apply.

Instructions

Anonymous public Note thread read, no credentials sent. Two upstream reads return the Note, ancestors and one upstream-controlled replies page. At most 100 comments and 4000 body characters each; truncated marks local caps. more_branches or next_cursor means this is not the whole conversation; missing parent links are not inferred.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cursorNo
comment_idYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
rootYes
branchesYes
ancestorsYes
truncatedYes
next_cursorYes
completenessYes
more_branchesYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.3.0

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the readOnlyHint annotation, it discloses concrete behavioral constraints: two upstream reads, an upstream-controlled replies page, 100-comment and 4000-character caps, truncation semantics, and the meaning of more_branches/next_cursor. It also warns that missing parent links are not inferred.

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?

Three dense sentences with no filler. The most important facts (anonymous, public, no credentials) are front-loaded, and each sentence adds distinct operational value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple read-only nature, annotations, and a present output schema, the description covers most of what an agent needs: scope, safety, limits, truncation, and incomplete-conversation signals. The only notable gap is input cursor usage, which is somewhat inferable from next_cursor.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for the undocumented comment_id and cursor parameters. It mentions next_cursor in the output context but never explains the input cursor parameter or how comment_id identifies the thread.

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 opens with 'Anonymous public Note thread read', a specific verb plus resource, and immediately clarifies that no credentials are sent. This distinguishes it from authenticated or post-comment tools without needing to open the schema.

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?

The description clearly signals when this tool applies: anonymous public Note threads with no credentials. It does not explicitly name sibling alternatives or state when not to use it, so it stops short of a 5.

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