Steam profiles, SteamID conversion, bans, FACEIT stats, friends and comparisons. Free, no API key.
Scored across 9 tools
Each tool has a clearly stated role, and descriptions explicitly route away from neighbors (e.g. steam_convert vs steam_identity, steam_summary vs narrow tools). The main overlap is steam_summary aggregating what steam_profile, steam_bans, steam_faceit and steam_friends return individually, but the guidance on when to use the cheap narrow tool vs the aggregate is explicit enough that misselection is unlikely.
All names share a predictable steam_ prefix with snake_case resource/action suffixes, which makes the set easy to scan. There is a minor inconsistency between noun-style names (steam_profile, steam_friends, steam_bans) and verb-style names (steam_compare, steam_convert), but the convention is still readable and coherent.
Nine tools is well-scoped for a Steam player-intelligence server. Each tool covers a distinct operation (identity resolution, conversion, profile, bans, friends, FACEIT, comparison, batch, aggregate summary) and none feels redundant or gratuitous.
The surface covers the core player-intelligence lifecycle: identity resolution, format conversion, profile, bans, friends, FACEIT, batch lookups, comparisons, and an aggregate summary. Minor gaps remain around game libraries, achievements, playtime, and recent match data (the latter explicitly out of scope), but the stated workflows have no dead ends.
Use when the user asks whether a Steam account has a VAC, game, community or trade (economy) ban - the first check for a cheating report or before trusting a player. Returns VACBanned, NumberOfVACBans, NumberOfGameBans, DaysSinceLastBan, CommunityBanned and EconomyBan exactly as Steam reports them; DaysSinceLastBan is 0 both for banned today and never banned. Unresolvable ids or an unavailable upstream return an error result, never guessed data. Do not use for FACEIT bans (steam_faceit).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | any SteamID format: steamid64 (17 digits), STEAM_1:0:x, STEAM_0:0:x, [U:1:x], hex, steam:hex, a 32-bit account id, a steamcommunity.com link or a vanity name |
| Name | Required | Description |
|---|---|---|
| bans | No | Steam ban object: VACBanned, NumberOfVACBans, NumberOfGameBans, DaysSinceLastBan, CommunityBanned, EconomyBan |
| steamid64 | No | |
| provenance | No | freshness of the ban snapshot: retrieved_at, age_seconds, fresh, cache_ttl |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent and open-world traits, but the description adds genuinely non-obvious semantics: the DaysSinceLastBan=0 ambiguity (banned today vs. never banned) and the failure contract that unresolvable ids or an unavailable upstream return an error rather than guessed data. It does not mention rate limits or any auth/key prerequisites for the upstream Steam API.
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?
Three sentences, front-loaded with the trigger and scope, followed by return/caveat detail and then the exclusion. Each clause carries information an agent would otherwise have to guess; nothing is filler.
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 tool with an output schema and full annotations, the description covers trigger, scope, exclusion, failure behavior and the one ambiguous return field. An agent has everything needed to call it correctly and interpret the result.
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 the id property description already enumerates every accepted SteamID format, so the schema carries the full burden. The description adds nothing about the id parameter itself, 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?
States a specific verb and resource ('checks whether a Steam account has a VAC, game, community or trade ban') and enumerates the ban categories it covers. It explicitly names the sibling it is not for (steam_faceit), so an agent can distinguish it from neighbors without opening any schema.
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?
Gives an explicit trigger ('use when the user asks whether...'), two concrete scenario contexts ('first check for a cheating report or before trusting a player'), and an explicit exclusion with the alternative tool named. Nothing about when to select this vs. siblings 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.
Use when the user gives several Steam ids - a match roster, a team, a list of suspects - and wants profiles, FACEIT or ban status for all of them: up to 100 in ONE call, always instead of per-player calls. ids are STRINGS in any computable SteamID format (steamid64, STEAM_1:0:x, STEAM_0:0:x, [U:1:x], hex, steam:hex, a 32-bit account id, a /profiles/ link); never JSON numbers (a 17-digit number loses precision and points at another account); vanity names are not accepted - resolve them with steam_identity first. Players unknown to the platform come back in not_found - fetch those with steam_profile. include adds FACEIT (one query for the batch) and Steam bans (one upstream call) - the cheapest way to review a full roster. Do not use for one player (steam_summary).
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | steamid64 list, max 100 - prefer one batch over per-player calls | |
| include | No | extra blocks per player: faceit level/ELO, Steam ban status |
| Name | Required | Description |
|---|---|---|
| count | No | players returned |
| invalid | No | inputs that are not a computable SteamID |
| players | No | per player: steamid64, ids, steam and the include blocks |
| not_found | No | valid ids unknown to the platform - fetch them with steam_profile |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnlyHint, idempotentHint, no destruction), yet the description still adds behavior the agent could not infer: unknown players surface in not_found rather than erroring, and include fans out into one batched FACEIT query plus one upstream bans call, which is framed as the cheapest way to review a roster. That partial-result and cost disclosure goes well beyond the structured fields.
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?
Front-loaded with the usage trigger and preference rule, and every sentence carries load (format list, numeric-precision warning, vanity redirect, not_found handling, include cost, exclusion). It is dense to the point of being one long block with heavy parentheticals, which costs it a point on readability.
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 two-parameter batch tool with an output schema, the description covers everything an agent needs: input formats, the 100-item ceiling, what extra blocks include returns, how misses are reported, and where to go next. Return-value details are rightly left to the output schema.
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%, but the description still adds essential meaning: ids must be strings in any computable SteamID format (with the accepted variants enumerated), must never be JSON numbers because a 17-digit number loses precision, and vanity names are rejected. That risks-and-formats guidance materially exceeds the schema's narrower 'steamid64 list' wording and prevents the most likely caller error.
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?
Opens with a specific verb and resource ('gives several Steam ids ... and wants profiles, FACEIT or ban status for all of them') and scopes the batch to up to 100 ids in a single call. It explicitly distinguishes itself from siblings by naming steam_summary, steam_profile, and steam_identity as the right tools in the cases this one does not cover.
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?
Provides an explicit when-to-use trigger ('several Steam ids - a match roster, a team, a list of suspects'), a strong preference rule ('always instead of per-player calls'), and a when-not ('Do not use for one player (steam_summary)'). It also routes follow-up cases to alternatives: vanity names to steam_identity and not_found results to steam_profile.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user asks to compare two Steam players, whether two accounts are related or share friends, or for smurf and alt-account hints: identity, account age, visibility, Steam bans, FACEIT and shared friends compared over the full friend lists. HEAVIEST tool - it builds two summaries plus both friend graphs. Do not use for a single player (steam_summary) or for more than two players (steam_batch).
| Name | Required | Description | Default |
|---|---|---|---|
| id1 | Yes | any SteamID format: steamid64 (17 digits), STEAM_1:0:x, STEAM_0:0:x, [U:1:x], hex, steam:hex, a 32-bit account id, a steamcommunity.com link or a vanity name | |
| id2 | Yes | any SteamID format: steamid64 (17 digits), STEAM_1:0:x, STEAM_0:0:x, [U:1:x], hex, steam:hex, a 32-bit account id, a steamcommunity.com link or a vanity name |
| Name | Required | Description |
|---|---|---|
| a | No | summary of the first player: identity, account, Steam bans, FACEIT |
| b | No | summary of the second player |
| shared_friends | No | friends present in both snapshots; an empty list is not proof the players are unrelated |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond them: it warns this is the HEAVIEST tool because it builds two summaries plus both friend graphs, which tells the agent about cost/latency and why to avoid calling it casually. No auth or rate-limit detail, and the friend-graph scan over 'full friend lists' could hint at scale limits, but the cost disclosure is the key one.
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 'Use when' trigger, then the cost warning, then the negative routing. Every clause earns its place and no format details are duplicated from the schema.
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?
An output schema exists, so return structure needn't be explained. Given the tool's cost and complexity, the description covers triggers, exclusions, alternatives and the expensive side effects (two summaries plus both friend graphs) — everything an agent needs to decide and invoke correctly.
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 both id1/id2 document every accepted SteamID format in detail, so the description does not need to repeat it. The description adds no parameter-level meaning beyond what the schema states; baseline 3 applies since the schema carries the load.
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?
Specific verb ('compare') plus resource ('two Steam players') plus an enumeration of what is compared: identity, account age, visibility, bans, FACEIT, shared friends. It explicitly distinguishes itself from steam_summary (one player) and steam_batch (more than two), so an agent can route without opening any schema.
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 first sentence gives concrete trigger scenarios (compare two players, are accounts related, share friends, smurf/alt hints) and the last sentence names both exclusions and the sibling to use instead. Nothing 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.
Use when the user wants a SteamID converted between formats - steamid64 (dec and hex), STEAM_1:0:x, legacy STEAM_0, [U:1:x], 32-bit account id, steam:hex (FiveM) or the profile URL - starting from any one of them, instantly and offline. CHEAPEST TOOL: prefer it over steam_identity whenever only format conversion is needed. Do not use for vanity names (steamcommunity.com/id/name is not a computable format - use steam_identity) or for profile data (steam_profile).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | steamid64 (17 digits), STEAM_1:0:x, STEAM_0:0:x, [U:1:x], hex, steam:hex, a 32-bit account id or a /profiles/ link. NOT a vanity name |
| Name | Required | Description |
|---|---|---|
| steamid | No | STEAM_1:y:z |
| steamid3 | No | [U:1:x] |
| accountid | No | 32-bit account id |
| steam_hex | No | steam:hex form used by FiveM |
| steamid64 | No | |
| profile_url | No | steamcommunity.com/profiles/ link |
| input_format | No | which format the input was recognized as |
| steamid64_hex | No | steamid64 in hexadecimal |
| steamid_legacy | No | STEAM_0:y:z |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations declare openWorldHint=true, implying interaction with an open world of external entities, while the description says the conversion is 'instantly and offline.' That is a direct contradiction. Although the description otherwise adds useful context about cheapness and format handling, the rule requires score 1 when the description contradicts annotations.
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?
The description is front-loaded with the core action, then immediately routes the agent via cheapness and exclusions. Every clause earns its place, with no filler.
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?
Given a single required input and an output schema, the description need not explain return values. It covers the accepted formats, usage preference, exclusions, and offline/instant behavior, so an agent has enough to call it correctly apart from the annotation contradiction.
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 the schema already documents the single id parameter with examples and the vanity-name exclusion. The description reinforces that any supported format is accepted but does not add syntax or format details beyond the schema.
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: converting SteamIDs between named formats, and explicitly says it works from any one of them. It distinguishes the tool from siblings like steam_identity and steam_profile.
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?
It gives explicit when-to-use guidance ('prefer it over steam_identity whenever only format conversion is needed') and when-not-to-use guidance ('Do not use for vanity names... or for profile data'). The alternatives are named directly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user asks how good a CS2 player is on FACEIT - level, ELO, country, nickname - or whether a FACEIT account is banned. Returns the FACEIT player object plus known FACEIT bans; players without a FACEIT account return a result saying so - absence is reported explicitly, never silently. Do not use for Steam (VAC/game) bans (steam_bans) or for match history and per-match stats, which SteamGPT does not have.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | any SteamID format: steamid64 (17 digits), STEAM_1:0:x, STEAM_0:0:x, [U:1:x], hex, steam:hex, a 32-bit account id, a steamcommunity.com link or a vanity name |
| Name | Required | Description |
|---|---|---|
| bans | No | known FACEIT bans |
| note | No | present only when no FACEIT profile is known |
| faceit | No | FACEIT player object (nickname, country, games.cs2.skill_level, games.cs2.faceit_elo) or null when no FACEIT profile is known |
| steamid64 | No | |
| provenance | No | freshness of the FACEIT snapshot |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, non-destructive, so the safety profile needs no repeating. The description adds genuinely useful behavior beyond that: it returns the player object plus known FACEIT bans, and explicitly reports absence rather than returning empty. However, with an output schema present, the return-shape detail is modest incremental value, placing it just above baseline.
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?
Front-loaded with the trigger condition, then return behavior, then exclusions — a natural decision order. Roughly three sentences, every one carrying routing or behavioral weight, with no restated title or filler.
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 tool with full annotations and an output schema, this covers everything an agent needs: the trigger, the returned data, the no-account edge case, and the sibling it should not be confused with. Nothing material is 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 coverage is 100% and the single `id` property already enumerates every accepted SteamID format, so the description adds no parameter meaning. Baseline 3 applies when the schema carries the full load.
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 (FACEIT CS2 profile) and the exact data returned: level, ELO, country, nickname, plus ban status. It also contrasts itself with the sibling steam_bans, so an agent can distinguish it from VAC/game-ban lookups without opening a schema.
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?
Opens with an explicit trigger ('Use when the user asks how good a CS2 player is on FACEIT...') and then states exclusions: not for Steam bans (routing to steam_bans) and not for match history, which the server doesn't have. Both the when and the when-not are named, along with the alternative sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user asks who the friends of a Steam player are or needs the friend list for a graph check. Source: the platform snapshot of the public Steam friend graph (cache only, no live Steam call; it can be partial - absence of a friendship is not proof). detail picks token cost: short - steamid64 array, medium - steamid64 + personaname, full - raw Steam objects; use short unless names are needed. Do not use for shared friends of two players (steam_compare).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | any SteamID format: steamid64 (17 digits), STEAM_1:0:x, STEAM_0:0:x, [U:1:x], hex, steam:hex, a 32-bit account id, a steamcommunity.com link or a vanity name | |
| limit | No | max friends to return, default 100 | |
| detail | No | response detail level, default full |
| Name | Required | Description |
|---|---|---|
| count | No | friends returned |
| friends | No | entries shaped by detail: steamid64 strings, {steamid64, personaname} or {steamid64, steam} |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/idempotent annotations by disclosing that this is a cached snapshot with no live Steam call and that results can be partial ('absence of a friendship is not proof') – a crucial caveat an agent could not infer elsewhere. Minor tension: schema default for detail is 'full' while description advises 'use short unless names are needed', which could confuse an agent picking values.
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?
Front-loaded trigger clause, then source caveat, then detail guidance, then exclusion – every sentence carries distinct information with no filler despite the density.
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?
An output schema exists, so return values needn't be explained; the description still covers the source, staleness risk, and detail-level cost, which is everything an agent needs to call it correctly.
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 is 3, and the description adds real value by explaining what each detail level returns (short=steamid64 array, medium=+personaname, full=raw objects) and the cost tradeoff, which the schema's one-line 'response detail level' does not. The limit parameter is left unmentioned.
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+resource ('who the friends of a Steam player are' / friend list) and names the sibling it is not (steam_compare for shared friends). An agent can distinguish it from steam_compare and steam_profile without opening any schema.
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?
Explicit when-to-use ('user asks who the friends... or needs the friend list for a graph check') and when-not ('Do not use for shared friends of two players (steam_compare)'), plus guidance on picking detail level by token cost.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user gives a vanity name or a steamcommunity.com/id/ link and the steamid64 behind it is needed, or when a resolved identity is needed in every format without profile data: steamid64, SteamID (STEAM_1:0:x), SteamID3 ([U:1:x]), steam hex, vanity, profile URL. Resolution goes through Steam; unresolvable ids return an error result - never a partial guess. Do not use for pure format conversion of a known id (steam_convert is cheaper) or for profile data (steam_profile).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | any SteamID format: steamid64 (17 digits), STEAM_1:0:x, STEAM_0:0:x, [U:1:x], hex, steam:hex, a 32-bit account id, a steamcommunity.com link or a vanity name |
| Name | Required | Description |
|---|---|---|
| vanity | No | custom URL name when known, otherwise null |
| steamid | No | STEAM_1:y:z |
| resolved | No | |
| steamid3 | No | [U:1:x] |
| steam_hex | No | steamid64 in hexadecimal |
| steamid64 | No | |
| profile_url | No | steamcommunity.com/profiles/ link |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and openWorld, so the safety profile is covered. The description adds genuinely new behavior: resolution traverses Steam and unresolvable ids return an error rather than a partial guess. It does not discuss rate limits, throttling, or latency of the network lookup, which matters for an openWorld resolver.
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?
Front-loaded with the 'Use when' trigger, then capability, then exclusions. Dense and mostly waste-free, though the inline enumeration of every output format partially duplicates what the output schema already conveys.
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?
Output schema exists, so return values need no explanation; the description instead covers the failure mode (error on unresolvable ids, no guessing), the input trigger, and sibling routing. Nothing an agent needs to invoke it correctly is 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 coverage is 100% and the id parameter's schema text already enumerates accepted formats, so the description only re-summarizes the same list. Baseline 3 applies since the schema does the heavy lifting and the description adds no syntax or normalization rules beyond it.
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 action (resolve the steamid64 behind a vanity name or steamcommunity.com/id/ link) plus the secondary capability of returning an identity in every format. It explicitly distinguishes itself from steam_convert and steam_profile, so an agent can route without opening sibling schemas.
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?
Gives an explicit trigger (user supplies a vanity name or /id/ link and needs the steamid64), an explicit non-use case (pure format conversion of a known id) with a named cheaper alternative, and a second exclusion for profile data. When-to-use, when-not, and alternatives are all present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user asks about one Steam account itself - nickname, avatar, profile visibility, creation date, online status, current game - and nothing else. Returns the raw GetPlayerSummaries object plus SteamID conversions; cheapest profile tool, data no older than 48 hours, unknown profiles are fetched live from Steam. Private profiles return the public subset of fields (not an error); unresolvable ids return an error result. Do not use for bans, FACEIT or friends (steam_summary or the narrow tools).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | any SteamID format: steamid64 (17 digits), STEAM_1:0:x, STEAM_0:0:x, [U:1:x], hex, steam:hex, a 32-bit account id, a steamcommunity.com link or a vanity name |
| Name | Required | Description |
|---|---|---|
| ids | No | the same account in every SteamID format |
| steam | No | raw Steam GetPlayerSummaries object |
| canonical | No | steamid64 and canonical URL of this player |
| steamid64 | No | |
| provenance | No | per source: retrieved_at, age_seconds, fresh, cache_ttl |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, it discloses freshness (no older than 48 hours), live fallback behavior for unknown profiles, private-profile behavior (public subset returned, not an error), unresolvable-id behavior (error result), and that the response includes raw GetPlayerSummaries data plus SteamID conversions. It also flags this as the cheapest profile tool.
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?
Three sentences, front-loaded with usage and scope. Each sentence adds distinct information: selection criteria, return/behavioral details, and exclusions. No filler or repetition.
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 annotations covering safety, a fully documented single parameter, and an output schema, the description fills the remaining gaps: freshness, private-profile handling, live fetching, and failure behavior. Nothing an agent needs in order to select or invoke it correctly is 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 coverage is 100% and already documents all accepted SteamID formats, so the schema carries most of the burden. The description still adds relevant parameter behavior by noting SteamID conversion in the response and error handling for unresolvable ids, which goes slightly beyond the schema.
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 names the exact resource (one Steam account) and enumerates the fields returned: nickname, avatar, profile visibility, creation date, online status, current game. It explicitly separates this from bans, FACEIT, and friends, so the agent can distinguish it from every sibling.
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?
It gives explicit when-to-use criteria ('when the user asks about one Steam account itself ... and nothing else') and explicit when-not-to-use guidance ('Do not use for bans, FACEIT or friends'), naming steam_summary and the narrower tools as alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use when the user asks who a Steam player is or wants everything known about one account in a single call: Steam summary, Steam ban status (VAC/game/community), SteamID conversions, FACEIT stats and the first 100 friends. include LIMITS the response to the blocks you list: omit it for everything, ["steam"] for the Steam block only (cheapest), ["bans"] for a ban check only, ["faceit","bans"] to drop the friend list; friends_limit caps the friend list (default 100). Responses carry provenance.fresh and sources/partial - branch on them, not on nulls. Do not use for several players (steam_batch) or for a single fact (steam_bans, steam_faceit, steam_convert are cheaper).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | any SteamID format: steamid64 (17 digits), STEAM_1:0:x, STEAM_0:0:x, [U:1:x], hex, steam:hex, a 32-bit account id, a steamcommunity.com link or a vanity name | |
| include | No | restricts the response to the listed blocks; omit for bans+faceit+friends. Example: ["bans"] returns the Steam summary plus ban status only | |
| friends_limit | No | max friends in the response, default 100 | |
| friends_detail | No | friend entry shape, default full; short/medium are much smaller |
| Name | Required | Description |
|---|---|---|
| ids | No | the same account in every SteamID format |
| steam | No | raw Steam GetPlayerSummaries object, null when the Steam block is unavailable |
| faceit | No | FACEIT player object or null |
| friends | No | friend entries, shape set by friends_detail |
| partial | No | true when at least one source was unavailable |
| sources | No | per block: ok | empty | unavailable | excluded |
| canonical | No | steamid64 and canonical URL of this player |
| steamid64 | No | |
| provenance | No | per source: retrieved_at, age_seconds, fresh, cache_ttl |
| steam_bans | No | Steam ban fields exactly as Steam reports them |
| faceit_bans | No | known FACEIT bans |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the description rightly focuses on what they cannot convey: provenance.fresh and sources/partial fields with the instruction to 'branch on them, not on nulls', plus relative cost signals (cheapest blocks). This is exactly the extra behavioral context an agent needs to interpret empty/partial results correctly.
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?
Front-loaded with the trigger and heavily information-dense with zero filler; the alternatives come last where an agent needs them. It is a single long run-on paragraph with many parentheticals, which reduces scannability slightly but costs no wasted words.
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 needn't enumerate return values, yet it still flags the provenance/sources semantics that the schema alone would leave ambiguous. For a 4-parameter aggregator tool with full schema coverage, nothing an agent needs to call it correctly is 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 coverage is 100%, so baseline is 3; the description goes further by giving concrete include combinations (["steam"] for cheapest, ["bans"] for a ban check, ["faceit","bans"] to drop friends) and reinforcing the friends_limit default. It does not explain friends_detail beyond what the schema says, keeping it just shy of a 5.
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 and resource — returns a Steam player's summary, bans, SteamID conversions, FACEIT stats, and first 100 friends in one call. An agent can immediately distinguish it from steam_bans, steam_faceit, or steam_convert, which are explicitly named as single-fact alternatives.
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?
Opens with an explicit trigger ('Use when the user asks who a Steam player is'), names the tool's scope, and closes with exclusions: 'Do not use for several players (steam_batch) or for a single fact (steam_bans, steam_faceit, steam_convert are cheaper).' Both when-to-use and when-not are covered.
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.
steam_bans1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "bans": {
+ "description": "Steam ban object: VACBanned, NumberOfVACBans, NumberOfGameBans, DaysSinceLastBan, CommunityBanned, EconomyBan"
+ },
+ "provenance": {
+ "description": "freshness of the ban snapshot: retrieved_at, age_seconds, fresh, cache_ttl"
+ },
+ "steamid64": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}steam_batch1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "count": {
+ "description": "players returned",
+ "type": "integer"
+ },
+ "invalid": {
+ "description": "inputs that are not a computable SteamID",
+ "type": "array"
+ },
+ "not_found": {
+ "description": "valid ids unknown to the platform - fetch them with steam_profile",
+ "type": "array"
+ },
+ "players": {
+ "description": "per player: steamid64, ids, steam and the include blocks",
+ "type": "array"
+ }
+ },
+ "type": "object"
+}steam_compare1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "a": {
+ "description": "summary of the first player: identity, account, Steam bans, FACEIT"
+ },
+ "b": {
+ "description": "summary of the second player"
+ },
+ "shared_friends": {
+ "description": "friends present in both snapshots; an empty list is not proof the players are unrelated"
+ }
+ },
+ "type": "object"
+}steam_convert1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "accountid": {
+ "description": "32-bit account id"
+ },
+ "input_format": {
+ "description": "which format the input was recognized as"
+ },
+ "profile_url": {
+ "description": "steamcommunity.com/profiles/ link"
+ },
+ "steam_hex": {
+ "description": "steam:hex form used by FiveM"
+ },
+ "steamid": {
+ "description": "STEAM_1:y:z"
+ },
+ "steamid3": {
+ "description": "[U:1:x]"
+ },
+ "steamid64": {
+ "type": "string"
+ },
+ "steamid64_hex": {
+ "description": "steamid64 in hexadecimal"
+ },
+ "steamid_legacy": {
+ "description": "STEAM_0:y:z"
+ }
+ },
+ "type": "object"
+}steam_faceit1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "bans": {
+ "description": "known FACEIT bans",
+ "type": "array"
+ },
+ "faceit": {
+ "description": "FACEIT player object (nickname, country, games.cs2.skill_level, games.cs2.faceit_elo) or null when no FACEIT profile is known"
+ },
+ "note": {
+ "description": "present only when no FACEIT profile is known"
+ },
+ "provenance": {
+ "description": "freshness of the FACEIT snapshot"
+ },
+ "steamid64": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}steam_friends1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "count": {
+ "description": "friends returned",
+ "type": "integer"
+ },
+ "friends": {
+ "description": "entries shaped by detail: steamid64 strings, {steamid64, personaname} or {steamid64, steam}",
+ "type": "array"
+ }
+ },
+ "type": "object"
+}steam_identity1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "profile_url": {
+ "description": "steamcommunity.com/profiles/ link"
+ },
+ "resolved": {
+ "type": "boolean"
+ },
+ "steam_hex": {
+ "description": "steamid64 in hexadecimal"
+ },
+ "steamid": {
+ "description": "STEAM_1:y:z"
+ },
+ "steamid3": {
+ "description": "[U:1:x]"
+ },
+ "steamid64": {
+ "type": "string"
+ },
+ "vanity": {
+ "description": "custom URL name when known, otherwise null"
+ }
+ },
+ "type": "object"
+}steam_profile1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "canonical": {
+ "description": "steamid64 and canonical URL of this player"
+ },
+ "ids": {
+ "description": "the same account in every SteamID format"
+ },
+ "provenance": {
+ "description": "per source: retrieved_at, age_seconds, fresh, cache_ttl"
+ },
+ "steam": {
+ "description": "raw Steam GetPlayerSummaries object"
+ },
+ "steamid64": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}steam_summary1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "properties": {
+ "canonical": {
+ "description": "steamid64 and canonical URL of this player"
+ },
+ "faceit": {
+ "description": "FACEIT player object or null"
+ },
+ "faceit_bans": {
+ "description": "known FACEIT bans"
+ },
+ "friends": {
+ "description": "friend entries, shape set by friends_detail"
+ },
+ "ids": {
+ "description": "the same account in every SteamID format"
+ },
+ "partial": {
+ "description": "true when at least one source was unavailable",
+ "type": "boolean"
+ },
+ "provenance": {
+ "description": "per source: retrieved_at, age_seconds, fresh, cache_ttl"
+ },
+ "sources": {
+ "description": "per block: ok | empty | unavailable | excluded",
+ "type": "object"
+ },
+ "steam": {
+ "description": "raw Steam GetPlayerSummaries object, null when the Steam block is unavailable"
+ },
+ "steam_bans": {
+ "description": "Steam ban fields exactly as Steam reports them"
+ },
+ "steamid64": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}steam_bans1 field changedInput schema / properties / id / descriptionPrevious value: -"steamid64 (17 digits), STEAM_1:0:x, [U:1:x], steamcommunity.com profile link or vanity name"New value: +"any SteamID format: steamid64 (17 digits), STEAM_1:0:x, STEAM_0:0:x, [U:1:x], hex, steam:hex, a 32-bit account id, a steamcommunity.com link or a vanity name"steam_compare2 fields changedInput schema / properties / id1 / descriptionPrevious value: -"steamid64 (17 digits), STEAM_1:0:x, [U:1:x], steamcommunity.com profile link or vanity name"New value: +"any SteamID format: steamid64 (17 digits), STEAM_1:0:x, STEAM_0:0:x, [U:1:x], hex, steam:hex, a 32-bit account id, a steamcommunity.com link or a vanity name"Input schema / properties / id2 / descriptionPrevious value: -"steamid64 (17 digits), STEAM_1:0:x, [U:1:x], steamcommunity.com profile link or vanity name"New value: +"any SteamID format: steamid64 (17 digits), STEAM_1:0:x, STEAM_0:0:x, [U:1:x], hex, steam:hex, a 32-bit account id, a steamcommunity.com link or a vanity name"steam_faceit1 field changedInput schema / properties / id / descriptionPrevious value: -"steamid64 (17 digits), STEAM_1:0:x, [U:1:x], steamcommunity.com profile link or vanity name"New value: +"any SteamID format: steamid64 (17 digits), STEAM_1:0:x, STEAM_0:0:x, [U:1:x], hex, steam:hex, a 32-bit account id, a steamcommunity.com link or a vanity name"steam_friends1 field changedInput schema / properties / id / descriptionPrevious value: -"steamid64 (17 digits), STEAM_1:0:x, [U:1:x], steamcommunity.com profile link or vanity name"New value: +"any SteamID format: steamid64 (17 digits), STEAM_1:0:x, STEAM_0:0:x, [U:1:x], hex, steam:hex, a 32-bit account id, a steamcommunity.com link or a vanity name"steam_identity1 field changedInput schema / properties / id / descriptionPrevious value: -"steamid64 (17 digits), STEAM_1:0:x, [U:1:x], steamcommunity.com profile link or vanity name"New value: +"any SteamID format: steamid64 (17 digits), STEAM_1:0:x, STEAM_0:0:x, [U:1:x], hex, steam:hex, a 32-bit account id, a steamcommunity.com link or a vanity name"steam_profile1 field changedInput schema / properties / id / descriptionPrevious value: -"steamid64 (17 digits), STEAM_1:0:x, [U:1:x], steamcommunity.com profile link or vanity name"New value: +"any SteamID format: steamid64 (17 digits), STEAM_1:0:x, STEAM_0:0:x, [U:1:x], hex, steam:hex, a 32-bit account id, a steamcommunity.com link or a vanity name"steam_summary1 field changedInput schema / properties / id / descriptionPrevious value: -"steamid64 (17 digits), STEAM_1:0:x, [U:1:x], steamcommunity.com profile link or vanity name"New value: +"any SteamID format: steamid64 (17 digits), STEAM_1:0:x, STEAM_0:0:x, [U:1:x], hex, steam:hex, a 32-bit account id, a steamcommunity.com link or a vanity name"steam_convertsteam_banssteam_batchsteam_comparesteam_faceitsteam_friendssteam_identitysteam_profilesteam_summaryPlayer ban records from 560+ game community ban lists, with Steam's own bans. Reads need no key.
Steam backlog, account value, buy-or-skip verdicts and Steam Machine checks. Hosted, keyless.
Live Steam Market API docs, schemas, products, games, markets and endpoint search.
Steam concurrent player trends for any game over time. Free key at trendsapi.ai
Add one secure layer between your agents and this server.
