Skip to main content
Glama
Sign In

Paxmod

by com.paxmod
OverviewDiscussionsAdmin

List flagged messages

list_flagged_messages
Read-only

Lists a project's most recent flagged messages, newest first, with the reason, confidence, player id, context id and any reviewer verdict (TP or FP). Filter by date, category or player. Up to 50 per call. Not available for organizations that keep player data in a separate region unless Paxmod has enabled it.

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": {
      "project_id": "<project_id>"
    },
    "name": "list_flagged_messages"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoHow many, 1 to 50. Default 20.
sinceNoOnly messages after this date or time (ISO 8601), for example 2026-11-01.
user_idNoOnly this player's messages (exact id).
categoryNoOnly this flag reason, for example Harassment.
project_idYesThe project's id, from list_projects.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior4/5

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

readOnlyHint already covers the safety profile, and the description still adds real value: sort order, the 50-per-call ceiling, and an availability restriction for organizations storing player data in a separate region unless Paxmod enables it. The only gap is the absence of pagination or continuation behavior when more than 50 flags exist.

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 tightly packed sentences, front-loaded with what is returned and ordered before the filters and the caveat. Minor redundancy in 'Up to 50 per call' against the limit field's '1 to 50' description, but it is short enough not to hurt.

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 no output schema, listing the returned fields (reason, confidence, player id, context id, reviewer verdict) is exactly the right compensation, and the availability caveat prevents a confusing empty result. Only pagination behavior beyond the 50-item cap is left unaddressed.

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%, so every parameter is already documented, and the description largely restates the same filter dimensions (date, category, player) without adding format or edge-case detail. Baseline 3 is appropriate when the schema carries the parameter burden.

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 a specific verb and resource ('Lists a project's most recent flagged messages'), then adds scope (per-project), ordering (newest first), and the fields returned. This clearly separates it from siblings like get_player_history or moderate_text, which neither list flags nor return reviewer verdicts.

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?

It gives clear usage context: filter by date, category, or player, and a hard cap of 50 per call. What it lacks is explicit routing — it never says to prefer get_player_history for a single player's full history or moderate_text to act on a flag — so an agent must infer the alternative from sibling names.

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

All Paxmod toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources