Skip to main content
Glama

WindowsForum MCP Server

Get thread posts

get_thread_posts
Read-only

Read a page of visible posts in a WindowsForum thread, oldest first. Follow pagination.next_offset while pagination.has_more to read the full conversation, including later replies and accepted solutions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of posts to return (default: 50, maximum: 100)
offsetNoNumber of visible posts to skip (default: 0)
thread_idYesThe thread ID to get posts for

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • changedInput schema / properties / limit / description
      Previous value: -"Maximum number of posts to return (default: 50)"New value: +"Maximum number of posts to return (default: 50, maximum: 100)"
    • addedInput schema / properties / offset
      Added value: +{
      +  "default": 0,
      +  "description": "Number of visible posts to skip (default: 0)",
      +  "type": "integer"
      +}
    • addedOutput schema / additionalProperties
      Added value: +true
    • removedOutput schema / properties
      Removed value: -{
      -  "result": {
      -    "items": {
      -      "additionalProperties": true,
      -      "type": "object"
      -    },
      -    "type": "array"
      -  }
      -}
    • removedOutput schema / required
      Removed value: -[
      -  "result"
      -]
    • removedOutput schema / x-fastmcp-wrap-result
      Removed value: -true
  2. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already establish readOnlyHint/destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: results are restricted to 'visible' posts (implying hidden/deleted content is filtered), ordering is oldest-first, later replies and accepted solutions are included, and continuation depends on pagination.has_more.

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?

Two tight sentences, zero filler, with the scope/filtering constraint front-loaded and the pagination instruction following. Every clause carries information.

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-format explanation is unnecessary, and the annotations cover safety. The description suffices for correct invocation, though it leaves the meaning of 'visible' and the relationship to search_posts/render_thread unstated.

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 100% (limit, offset, thread_id all documented), so baseline is 3. The description adds nothing about parameter syntax or interaction (e.g., how offset relates to pagination.next_offset) beyond what the schema already states.

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?

Names a specific verb and resource ('Read a page of ... posts in a WindowsForum thread') plus scope ('oldest first'), which cleanly separates it from get_post (singular) and get_thread (metadata). It does not, however, name a sibling or state what it is not, so full sibling differentiation relies on inference.

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?

Gives operational guidance ('Follow pagination.next_offset while pagination.has_more to read the full conversation'), which is really how-to-paginate rather than when-to-use. There is no statement telling the agent to prefer search_posts or get_thread instead under any condition.

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