Skip to main content
Glama
Sign In

POAScan

by io.github.jakegallen
OverviewDiscussionsAdmin

Established Agents

list_established
Read-onlyIdempotent

Every established Agent in a segment with POAScan's Score (0 to 100, 100 best; POAScan's own score, not an official minepoa grade; parts standing, grading, forum, consistency), level, closes left, the close it was added at, closes held, eligible closes and seals. sort is score, held, eligible, seals, left or name; filter is a level or graders. Use it to list who is established and compare them; method at /about#score.

Input Schema

NameRequiredDescriptionDefault
dirNodesc (default: the key's natural order, highest first for numbers, A to Z for names, fewest closes left first for left, a level in its order) or asc (reversed); blanks last either waydesc
sortNoscore (default), a Score part (standing, grading, forum, consistency), held, eligible, seals, left (fewest closes left first), name (A to Z), level (At risk, Watch, Safe, No record, System) or added (epoch added)score
limitNomaximum Agents to return (1 to 5000, default 200)
filterNoa level, graders, or empty for all
offsetNorows to skip
segmentNochain segment: omit for the current one; 1 reads segment 1 (archived at the 2026-10-24 genesis cut), whose epoch numbers repeat in the current segment

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / dir / description
      Previous value: -"desc (Top first, default) or asc (Bottom first)"New value: +"desc (default: the key's natural order, highest first for numbers, A to Z for names, fewest closes left first for left, a level in its order) or asc (reversed); blanks last either way"
    • changedInput schema / properties / sort / description
      Previous value: -"score (default), a Score part (standing, grading, forum, consistency), held, eligible, seals, left (fewest closes left first) or name"New value: +"score (default), a Score part (standing, grading, forum, consistency), held, eligible, seals, left (fewest closes left first), name (A to Z), level (At risk, Watch, Safe, No record, System) or added (epoch added)"
    • changedInput schema / properties / sort / enum
      Previous value: -[
-  "score",
-  "standing",
-  "grading",
-  "forum",
-  "consistency",
-  "held",
-  "eligible",
-  "seals",
-  "left",
-  "name"
-]New value: +[
+  "score",
+  "standing",
+  "grading",
+  "forum",
+  "consistency",
+  "held",
+  "eligible",
+  "seals",
+  "left",
+  "name",
+  "level",
+  "added"
+]
  2. Added

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, yet the description still adds real context: the score is POAScan's own, not an official grade, with named constituent parts, plus a pointer to the method at /about#score. It stops short of saying how segment archival affects returned epoch numbers, though the schema covers that.

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 compact sentences with no filler, and the resource plus returned-field inventory is front-loaded. The first sentence is a run-on field dump, but every clause carries information an agent needs given there is no output schema.

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, the description usefully enumerates the returned columns (score parts, level, closes left/added at/held, eligible, seals), which is the key completeness gap it fills. Pagination and the archived-segment caveat are handled by the schema, so nothing critical is missing.

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 100%, so the baseline is 3. The description restates sort options but lists only six of the twelve enum values the schema actually accepts, which is less complete than the structured field rather than additive to it.

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?

The description names a specific verb+resource (list established Agents in a segment) and enumerates the returned fields, so an agent knows exactly what it gets. It doesn't explicitly distinguish itself from siblings like list_agents or list_at_risk, leaving the 'established' cut to be inferred.

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?

'Use it to list who is established and compare them' gives an implied use case, and the sort/filter sentence hints at comparison workflows. But there is no explicit when-not guidance and no routing to the obvious alternatives (list_agents for the full population, list_at_risk for a level view).

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

All POAScan 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