Skip to main content
Glama

List reader activities

list_reader_activities
Read-onlyIdempotent

Read stored Substack likes, comments, restacks, and other notifications for the authenticated Narrareach account. This tool does not fetch new activity from Substack. Each item has type (LIKE, COMMENT, RESTACK, or OTHER), kind (the Substack notification type), and label (a short description). OTHER covers notifications that are not note likes, note replies, or restacks: follows, free and paid subscriptions, likes and replies on posts and comments, mentions, chat activity, live streams, and system notices such as a scheduled note being sent. Many OTHER items have no content; read kind and label to see what they are. Only COMMENT items with canReply true can be replied to. The inbox contains new activity; history contains the initial import and items already handled or replied to. Either can contain recent activity. sort=time returns newest first. range.page and range.all show the date ranges for the returned page and the requested state. Check sync.lastSyncedAt and sync.refreshRecommended for freshness; results may not include the latest activity.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNotime
typeNoall
limitNo
stateNoinbox
cursorNo
intentNo
substackConnectionIdNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageYes
syncYes
rangeYes
summaryYes
activitiesYes
connectedAccountNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedOutput schema / properties / activities / items / properties / kind
      Added value: +{
      +  "type": "string"
      +}
    • addedOutput schema / properties / activities / items / properties / label
      Added value: +{
      +  "type": "string"
      +}
    • changedOutput schema / properties / activities / items / required
      Previous value: -[
      -  "intent",
      -  "intentConfidence",
      -  "id",
      -  "type",
      -  "triageState",
      -  "senderCount",
      -  "occurredAt",
      -  "content",
      -  "targetContent",
      -  "canReply",
      -  "actors"
      -]New value: +[
      +  "intent",
      +  "intentConfidence",
      +  "id",
      +  "type",
      +  "kind",
      +  "label",
      +  "triageState",
      +  "senderCount",
      +  "occurredAt",
      +  "content",
      +  "targetContent",
      +  "canReply",
      +  "actors"
      +]
  2. Changed2 schema fields changed
    • addedOutput schema / properties / range
      Added value: +{
      +  "additionalProperties": false,
      +  "properties": {
      +    "all": {
      +      "additionalProperties": false,
      +      "properties": {
      +        "newestOccurredAt": {
      +          "anyOf": [
      +            {
      +              "format": "date-time",
      +              "type": "string"
      +            },
      +            {
      +              "type": "null"
      +            }
      +          ]
      +        },
      +        "oldestOccurredAt": {
      +          "anyOf": [
      +            {
      +              "format": "date-time",
      +              "type": "string"
      +            },
      +            {
      +              "type": "null"
      +            }
      +          ]
      +        }
      +      },
      +      "required": [
      +        "newestOccurredAt",
      +        "oldestOccurredAt"
      +      ],
      +      "type": "object"
      +    },
      +    "page": {
      +      "additionalProperties": false,
      +      "properties": {
      +        "newestOccurredAt": {
      +          "anyOf": [
      +            {
      +              "format": "date-time",
      +              "type": "string"
      +            },
      +            {
      +              "type": "null"
      +            }
      +          ]
      +        },
      +        "oldestOccurredAt": {
      +          "anyOf": [
      +            {
      +              "format": "date-time",
      +              "type": "string"
      +            },
      +            {
      +              "type": "null"
      +            }
      +          ]
      +        }
      +      },
      +      "required": [
      +        "newestOccurredAt",
      +        "oldestOccurredAt"
      +      ],
      +      "type": "object"
      +    },
      +    "state": {
      +      "enum": [
      +        "inbox",
      +        "history"
      +      ],
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "state",
      +    "page",
      +    "all"
      +  ],
      +  "type": "object"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "activities",
      -  "page",
      -  "summary",
      -  "sync"
      -]New value: +[
      +  "activities",
      +  "page",
      +  "summary",
      +  "range",
      +  "sync"
      +]
  3. Changed2 schema fields changed
    • addedOutput schema / properties / sync
      Added value: +{
      +  "additionalProperties": false,
      +  "properties": {
      +    "historyAvailableFrom": {
      +      "anyOf": [
      +        {
      +          "format": "date-time",
      +          "type": "string"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ]
      +    },
      +    "lastSyncedAt": {
      +      "anyOf": [
      +        {
      +          "format": "date-time",
      +          "type": "string"
      +        },
      +        {
      +          "type": "null"
      +        }
      +      ]
      +    },
      +    "refreshRecommended": {
      +      "type": "boolean"
      +    },
      +    "status": {
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "status",
      +    "lastSyncedAt",
      +    "historyAvailableFrom",
      +    "refreshRecommended"
      +  ],
      +  "type": "object"
      +}
    • changedOutput schema / required
      Previous value: -[
      -  "activities",
      -  "page",
      -  "summary"
      -]New value: +[
      +  "activities",
      +  "page",
      +  "summary",
      +  "sync"
      +]
  4. Changed4 schema fields changed
    • addedInput schema / properties / intent
      Added value: +{
      +  "enum": [
      +    "QUESTION",
      +    "OBJECTION",
      +    "AGREEMENT",
      +    "CORRECTION",
      +    "EXPERIENCE",
      +    "COLLABORATION",
      +    "LEAD",
      +    "SPAM"
      +  ],
      +  "type": "string"
      +}
    • addedOutput schema / properties / activities / items / properties / intent
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "string"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ]
      +}
    • addedOutput schema / properties / activities / items / properties / intentConfidence
      Added value: +{
      +  "anyOf": [
      +    {
      +      "type": "number"
      +    },
      +    {
      +      "type": "null"
      +    }
      +  ]
      +}
    • changedOutput schema / properties / activities / items / required
      Previous value: -[
      -  "id",
      -  "type",
      -  "triageState",
      -  "senderCount",
      -  "occurredAt",
      -  "content",
      -  "targetContent",
      -  "canReply",
      -  "actors"
      -]New value: +[
      +  "intent",
      +  "intentConfidence",
      +  "id",
      +  "type",
      +  "triageState",
      +  "senderCount",
      +  "occurredAt",
      +  "content",
      +  "targetContent",
      +  "canReply",
      +  "actors"
      +]
  5. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, and the description adds rich behavior beyond them: the meaning of OTHER, that many OTHER items carry no content, the canReply gate for COMMENT, inbox vs history contents, sort semantics, and sync.lastSyncedAt/refreshRecommended freshness caveats.

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?

Well front-loaded: purpose and the fetch caveat come first, then type/kind/label semantics, then state and sort behavior. Dense but nearly every sentence delivers usable information; the OTHER enumeration runs slightly long but is justified by the schema gap.

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?

With an output schema present, return values need no explanation, and annotations cover the safety profile, so the remaining burden is behavioral and param-level. The description handles behavior, state, and freshness well but leaves several filter params unexplained, so it is not fully complete for a 7-param tool.

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 0% across 7 params, so the description carries the full burden, yet it only meaningfully explains type, sort=time, and state. limit, cursor, intent (an 8-value enum), and substackConnectionId are left entirely undocumented, so compensation is only partial.

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 ('Read stored Substack likes, comments, restacks, and other notifications') and immediately draws a scope boundary ('does not fetch new activity from Substack'), separating it from refresh/fetch-flavored siblings. An agent can distinguish it from reply_to_reader_activity and update_reader_activity without opening a 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?

Gives strong conditional context: inbox vs history semantics, 'Either can contain recent activity', and 'Only COMMENT items with canReply true can be replied to' (implying the reply tool). It stops short of naming the alternative tools (reply_to_reader_activity, update_reader_activity) or stating exclusions explicitly, so it lands just below the top bar.

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