Skip to main content
Glama
shuiyuan-mcp-lite

shuiyuan-mcp-lite

by Cashrel894

list_user_posts

Read-only

Fetch recent topics and replies posted by a user, with offset/limit pagination and excerpt length limits.

Instructions

List recent topics/replies by a user; offset counts activities from 0.

max_chars limits each excerpt. A full page offers next_offset; the next page may be empty.

Input Schema

NameRequiredDescriptionDefault
limitNo
offsetNo
usernameYes
max_charsNo

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), and the description adds real behavioral detail beyond them: offset counts activities from 0, max_chars truncates excerpts, a full page returns next_offset, and the next page may legitimately be empty. Auth/rate-limit behavior is not covered, keeping it short of 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?

Three tight clauses, front-loaded with the core purpose before the pagination and truncation caveats. No wasted words, though the fragmentary phrasing is slightly terse.

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?

An output schema exists, so return values need not be described, and the mention of next_offset plus the possibility of an empty next page gives the pagination context an agent needs. The remaining gap is the undocumented limit/username semantics.

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 0%, so the description must carry parameter meaning. It explains offset (indexed from 0 over activities) and max_chars (per-excerpt character cap), but says nothing about how limit interacts with pagination or the username parameter, leaving two of four parameters undocumented.

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: 'List recent topics/replies by a user', which is a clear read operation on user-scoped content. It implicitly separates from siblings like read_post/read_topic (single-item reads) and search (query-driven), but never names an alternative explicitly.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: an agent can infer this is the tool for enumerating one user's activity, but there is no when-to-use vs search/get_user guidance and no prerequisites (e.g. whether the user must exist).

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