Skip to main content
Glama
Sign In
social-watch-mcp

social-watch-mcp

by denis1stomin
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

replies

Read-only

Read comments, responses, and mentions with author, date, and link, filtered by platform and since timestamp.

Instructions

Replies, comments and mentions to read: text, author handle, date, link. since = ISO date or Unix seconds.

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": {
      "platform": "<platform>"
    },
    "name": "replies"
  }
}

Input Schema

NameRequiredDescriptionDefault
sinceNo
platformYesOne of: threads, itch, youtube, x

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.1/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context by listing returned fields (text, author handle, date, link) and the 'since' input format, but it does not explain ordering, pagination, or rate-limit behavior.

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 description is very short and front-loaded with the returned fields and the 'since' format. The opening fragment 'Replies, comments and mentions to read' is slightly awkward, but every sentence earns its place.

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?

For a simple read-only list tool with only two parameters and no output schema, the description covers the returned fields and the 'since' format. However, it omits ordering, default time range, and pagination behavior, which matters for a 'since'-filtered list tool.

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 only 50%, and the description compensates by clarifying that 'since' accepts an ISO date or Unix seconds, which the schema only types as a string. The 'platform' parameter is covered by its enum in the schema, so the description adds meaningful value where coverage is weakest.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies the resource as replies, comments, and mentions to read, but the phrasing 'to read' is vague about whether this lists or fetches them. It does not explicitly distinguish itself from siblings such as recent_posts or accounts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus the sibling tools, nor any stated prerequisites or exclusions. The agent must infer that this is for reading replies/comments/mentions rather than posts or accounts.

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

Deploy Server

Other Tools