Player ban records from 560+ game community ban lists, with Steam's own bans. Reads need no key.
Scored across 5 tools
check_players and lookup_player overlap in ban/VAC lookup, but the batch-vs-single and Steam-only-vs-multi-identifier distinction is clear enough. list_sources and registry_stats also differ by per-list detail versus aggregate counts. The remaining tool is clearly distinct.
Most names follow a verb_noun pattern: check_players, list_my_communities, list_sources, lookup_player. registry_stats is the sole noun-phrase outlier, which is a minor inconsistency.
Five tools is well-scoped for a ban-registry service: batch checking, individual lookup, source listing, aggregate stats, and personal communities. No tool appears redundant or out of place.
The read-only surface covers core workflows: checking players, inspecting lists, aggregate stats, and user community context. Minor gaps remain, such as deeper per-community or per-list detail beyond what listing provides, but agents can work around them.
Check up to 100 Steam accounts in one call, such as everyone on a game server: each account's bans across every list Mizan reads, whether a list banned it for cheating, and Steam's own VAC and game bans. Pass SteamIDs in any form or steamcommunity.com profile links; lines of a server's status output work too.
| Name | Required | Description | Default |
|---|---|---|---|
| players | Yes | SteamIDs in any form (SteamID64, STEAM_0:0:11101, [U:1:22202]), steamcommunity.com profile links, or lines of `status` output. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| counts | Yes | |
| checked | Yes | |
| leftOut | Yes | Accounts past the first 100, not checked. |
| players | Yes | |
| unresolved | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the remaining burden is light. The description still adds real value by disclosing the scope of the check — every list Mizan reads plus Steam's own VAC and game bans — which tells the agent what evidence comes back. It omits rate limits or cost of a 100-account call, a minor gap given the output schema covers results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the batch capability before the detail. The second sentence is long and its final clause ('lines of a server's `status` output work too') largely repeats the schema, but the density is justified by the enumeration of ban sources.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description need not explain return values, and the single input is fully specified. What an agent needs to call it correctly is present; only sibling disambiguation and any scale/cost caveats for 100-account batches are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the single parameter already documents SteamID64, STEAM_0:0:11101, [U:1:22202], profile links, and `status` lines. The description restates those accepted formats rather than adding new semantics, so the schema does the heavy lifting and baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a concrete verb and resource ('Check up to 100 Steam accounts in one call') and explains exactly what is retrieved: bans across every list Mizan reads, cheating flags, and Steam's VAC/game bans. The batch framing ('up to 100 ... in one call') implicitly distinguishes it from the single-account lookup_player sibling, but no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Offers a use case ('such as everyone on a game server') that implies when to reach for batch checking rather than a single lookup. However, it never states when NOT to use it and never names lookup_player as the alternative for one-off checks, so the routing decision is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the communities you belong to on Mizan, your role in each, their registry status and their game servers. Needs you to sign in to Mizan.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| communities | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds a genuinely useful behavioural fact not in the annotations: it requires an authenticated Mizan session. It also hints at the shape of the result (per-community role, registry status, game servers), which the output schema presumably formalises.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, front-loaded with the action and scope, followed by the authentication precondition. Every clause carries information and nothing is repeated from the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, an output schema present and annotations covering the safety profile, the description supplies exactly the missing pieces: the authentication requirement and a summary of what is returned. Nothing needed to invoke the tool correctly is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies; the description correctly avoids inventing filtering options that do not exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('List') and scoped resource ('the communities you belong to on Mizan'), and further specifies what the response contains (role, registry status, game servers). This clearly distinguishes it from siblings: registry_stats reports aggregates, list_sources and lookup_player are unrelated, and check_players targets players rather than the caller's memberships.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'you belong to' and the sign-in requirement make the context of use clear: this is the caller's own membership view, available only when authenticated. There are no explicit when-not conditions or named alternatives, but no sibling overlaps enough to need one.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the ban lists Mizan reads, largest first: each list's name, who issues its bans, the games it covers, its bans and how many are in force, and whether Mizan is still reading it. Filter by game key or by part of the name.
| Name | Required | Description | Default |
|---|---|---|---|
| game | No | A game key, such as rust, garrysmod, cs2, csgo, tf2 or squad; registry_stats lists every one. | |
| name | No | Part of a list's name, such as "sourcebans". | |
| limit | No | Lists to return, largest first. Defaults to 25. |
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| lists | Yes | Every list Mizan reads. |
| readAt | Yes | ISO 8601 time |
| matched | Yes | Lists matching the filters, before the limit. |
| sources | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this a safe, idempotent read, so the bar is lower; the description still adds real behavior: results are ordered largest-first, each row reports whether Mizan is still reading the list, and filtering is optional. It does not state pagination behavior beyond the schema's limit default, which keeps it off 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler: the purpose and ordering lead, and the optional filters close. The field enumeration on the return side is mildly redundant given an output schema exists, but it is compact and reads naturally as part of the opening claim.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity, zero-required-parameter list tool with annotations and an output schema, this covers what an agent needs: what it returns, ordering, and filter options. The only missing piece is how this relates to registry_stats when the caller does not know a game key.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter already carries its own description, including the game-key pattern and the "part of a name" example. The description only restates that both filters exist without adding format, matching rules, or interaction between them, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
"List the ban lists Mizan reads, largest first" pairs a specific verb with a specific resource and adds ordering, then enumerates the fields each entry carries (issuer, games, ban counts, tracking status). No sibling tool (check_players, lookup_player, list_my_communities, registry_stats) touches ban lists, so the resource alone distinguishes it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The final clause states the two available narrowing options, which implies how to use the tool, but gives no when-to-use vs when-not guidance and never points at registry_stats for enumerating game keys (that pointer lives only in the schema). Adequate, not instructive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up a player's Mizan record: their bans across every list Mizan reads, whether any list banned them for cheating, and Steam's own VAC and game bans for a Steam account. Pass a SteamID in any form, a Steam profile link, a Discord id or a Minecraft name.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | A player id, profile link or name, as typed into mizan.ac/lookup. |
| Name | Required | Description |
|---|---|---|
| bans | Yes | At most 200 bans, newest first; verdict.bans counts every one. |
| found | Yes | |
| links | Yes | |
| steam | Yes | Steam's own VAC and game bans; null for another platform or when Steam did not answer. |
| player | Yes | |
| schema | Yes | The record format's version; it changes only when a field changes meaning or goes away. |
| profile | Yes | |
| verdict | Yes | |
| checkedAt | Yes | ISO 8601 time |
| steamState | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds a sense of what the record aggregates (multiple ban lists plus Steam VAC data), but since an output schema exists, most of that return detail is redundant; it says nothing about rate limits, lookup failures, or behavior for unknown players.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the outcome rather than the mechanics, with zero filler. The second sentence partially overlaps the `query` schema description, which is the only minor redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only lookup with a full output schema, the description covers purpose, input forms and record contents adequately. The only real gap is absence of routing guidance relative to the sibling lookup/list tools, which matters given check_players sits next to it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline would be 3, but the description meaningfully expands the accepted input space beyond the schema's generic "player id, profile link or name": SteamID in any form, Steam profile link, Discord id, or Minecraft name. That is genuine semantic value an agent would not infer from the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ("Look up a player's Mizan record") and enumerates what the record contains: bans across every list, cheating flags, and Steam VAC/game bans. This is far more specific than the title alone, though it never names the sibling check_players or explains how single-player lookup differs from it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence gives strong guidance on what inputs are accepted, but there is no explicit when-to-use / when-not-to-use framing and no mention of when to prefer check_players or list_sources instead. Usage is implied by the scope of what is returned rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The size of Mizan's registry: how many ban lists it reads, the bans on them, how many are in force, and the same counts for each game.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| ok | Yes | |
| bans | Yes | |
| games | Yes | |
| lists | Yes | |
| byGame | Yes | |
| readAt | Yes | ISO 8601 time |
| inForce | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered. The description adds the substantive behavior that results are broken down per game, which is beyond the annotations, but says nothing about whether counts are live, cached, or time-scoped — relevant for a stats endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence, front-loaded with the resource name and then the metrics in a natural reading order. No filler, no restatement of the tool name beyond what is needed to anchor the subject.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, an output schema present, and annotations covering the safety profile, the description only needs to say what is counted — and it does. The remaining gap is scope/timeliness of the counts (live vs. cached, overall vs. per-community), which an agent might want before relying on the numbers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is no parameter semantics to clarify and the description cannot add or omit anything here. Baseline of 4 applies for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource ("Mizan's registry") and enumerates exactly what is measured: number of ban lists read, bans on them, how many are in force, plus per-game breakdowns. This clearly separates it from the sibling tools (list_sources, lookup_player, check_players), which all operate on individual entities, though no sibling is named explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the counts framing signals 'use this for aggregate figures rather than listing or looking up entries.' There is no explicit when-to-use statement, no exclusion of alternatives, and no mention of whether it should be called before or after list_sources to gauge scope.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_playerslist_my_communitieslist_sourceslookup_playerregistry_statsSteam profiles, SteamID conversion, bans, FACEIT stats, friends and comparisons. Free, no API key.
Sanctions, PEP, watchlist, recall, business, and contract screening. Free tier, no auth required.
Breach intelligence API: email search, domain monitoring, passwords and stealer logs.
Free no-key IP intelligence: geolocation, VPN detection, DNS, WHOIS, blacklists, breach checks
Add one secure layer between your agents and this server.
