Steam profiles, SteamID conversion, bans, FACEIT stats, friends and comparisons. Free, no API key.
Steam ban status of a player: VACBanned, NumberOfVACBans, NumberOfGameBans, DaysSinceLastBan, CommunityBanned, EconomyBan - fields exactly as Steam reports them. First thing to check when reviewing a cheating report. Unresolvable ids or an unavailable upstream return an error result, never guessed data.
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds significant value beyond these: it lists the exact output fields, states they are returned 'exactly as Steam reports them' (no transformation), and clarifies that the tool never returns guessed data, only errors for unresolvable IDs or upstream failures. No contradictions with 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 two sentences long, front-loaded with the core purpose and field list, followed by usage context and error handling. Every sentence adds unique value; no redundancy 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?
Given the tool's simplicity (one parameter, no output schema), the description adequately covers return values by listing all fields, provides a clear use case, and explains error behavior. No major gaps remain for an agent to use this tool effectively.
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% (the 'id' parameter is thoroughly documented with all accepted formats). The tool description does not add any additional meaning about the input parameter beyond what the schema already provides. Baseline 3 is appropriate as the schema carries the full burden.
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 clearly states the tool returns 'Steam ban status of a player' and lists the specific fields (VACBanned, NumberOfVACBans, etc.). It distinguishes itself from siblings by positioning it as 'First thing to check when reviewing a cheating report,' which implies a primary, focused role among the sibling tools (e.g., steam_profile, steam_friends).
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 description provides a strong use case: 'First thing to check when reviewing a cheating report.' It also clarifies error behavior ('Unresolvable ids or an unavailable upstream return an error result, never guessed data'). However, it does not explicitly mention when not to use this tool or suggest sibling alternatives, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Up to 100 Steam profiles in one call. When you need several players, ALWAYS use this instead of per-player calls - one batch of 100 costs one request. Accepts any SteamID format as STRINGS - steamid64, STEAM_1:0:x, STEAM_0:0:x, [U:1:x], hex, steam:hex, a 32-bit account id or a /profiles/ link. Never send them as JSON numbers (a 17-digit number loses precision and points at another account) and note that vanity names are not supported here - resolve those with steam_identity first. Players unknown to the platform come back in not_found - fetch those with steam_profile. include can add FACEIT (one query for the batch) and Steam bans (one upstream call for the batch) - the cheapest way to review a full match roster.
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false, which are consistent with a read-only batch query. The description adds context beyond annotations: it notes that unknown players appear in not_found, that IDs must be strings (not numbers to avoid precision loss), and that include fetches FACEIT and bans with one call per batch. These are valuable behavioral details not in 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 a single paragraph of about 5 sentences, front-loading the key efficiency benefit. Every sentence adds value—no fluff. Could be slightly more structured (e.g., bullet points for ID formats), but still concise and informative given the tool's complexity.
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 the input schema covers 100% of parameters, 2 simple params, no output schema, and no nested objects, the description is largely complete. It covers usage boundaries (max 100, format rules, exclusion of vanity), behavior for unknown players, and extra include options. Minor gap: no explicit mention of return format or error behavior, but the schema-less output is acceptable here due to complexity.
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?
Despite 100% schema coverage, the description adds significant meaning: it lists all accepted SteamID formats, warns about numeric precision, and explains that not_found indicates unknown players. It also clarifies that `include` adds FACEIT and bans via a single batch call. This exceeds what the schema's brief descriptions provide.
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 clearly states 'Up to 100 Steam profiles in one call' and emphasizes batch efficiency, which distinguishes it from sibling tools like steam_profile (single player). It uses a specific verb+resource combination and highlights the cost benefit.
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 description explicitly advises to always use this tool over per-player calls for multiple players, explains the cost advantage, and warns that vanity names are not supported (delegate to steam_identity). However, it does not explicitly state when NOT to use it (e.g., if only one player is needed, steam_profile may be simpler).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Two players side by side: 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; for a single player prefer steam_summary.
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description warns that this tool is the 'HEAVIEST' and explains why: it builds two summaries plus both friend graphs. This adds significant behavioral context beyond the annotations (readOnlyHint etc.), informing the agent of high computational cost and data load.
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 two sentences: the first clearly explains what the tool does, the second provides critical usage guidance. Every sentence is essential and front-loaded. No verbosity.
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 the tool has no output schema, the description explains what data will be returned (identity, account age, etc.) but does not detail the structure of the friend graph or shared friends output. It is complete enough for a high-level compare tool, but could specify output format minimally.
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%, so the schema already documents the two parameters well. The description adds no additional parameter details beyond the schema, but the schema itself is thorough. Score 4 reflects that the description does not detract and the schema is complete.
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 specifies the verb 'compare' and the resource 'two players', and lists the exact data fields (identity, account age, visibility, Steam bans, FACEIT, shared friends). It also distinguishes this tool from siblings by noting the comparison of full friend lists and the building of friend graphs.
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 description explicitly states this is the 'HEAVIEST tool' and advises using 'steam_summary' for a single player instead. This provides clear when-to-use and when-not-to-use guidance, with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
SteamID converter: turns one identifier into EVERY other form, instantly. Accepts steamid64, STEAM_1:0:x, STEAM_0:0:x, [U:1:x], hex (110000...), steam:hex (FiveM), a 32-bit account id or a steamcommunity.com/profiles/ link. Returns steamid64 (dec and hex), SteamID, legacy STEAM_0 form, SteamID3, account id, steam:hex and the profile URL. CHEAPEST TOOL - prefer it over steam_identity whenever you only need format conversion. Vanity names (steamcommunity.com/id/name) are not a computable format: use steam_identity for those.
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. Description adds that it is instant and cheap, which are useful behavioral traits beyond annotations. No contradiction.
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?
Description is 4-5 sentences, front-loaded with purpose, then inputs, outputs, and usage guidance. No fluff, every sentence is informative and earns its place.
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?
All key aspects are covered: purpose, inputs, outputs, usage guidance, limitations (vanity names), and alternative tool. No output schema but returns are fully described. Complete for a simple conversion tool.
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%, so baseline is 3. Description adds examples (hex (110000...), steam:hex (FiveM)) and reinforces format details, providing marginal value beyond 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?
Clearly states it converts one Steam identifier into all other forms, lists all accepted inputs and outputs, and distinguishes from sibling steam_identity by specifying it does not handle vanity names.
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?
Explicitly says 'CHEAPEST TOOL - prefer it over steam_identity whenever you only need format conversion' and directs the agent to use steam_identity for vanity names, providing clear when-to-use and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
FACEIT player object (nickname, country, per-game skill level and ELO) plus known FACEIT bans. Players without a FACEIT account return an error result saying so - absence of FACEIT data is reported explicitly, never silently.
| 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 |
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 clear. The description adds valuable behavioral context: it explicitly states that absence of FACEIT data results in an error message, not silent omission. This is beyond the annotations and helps the agent understand error handling.
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 concise (two sentences) and front-loaded with the key purpose. The first sentence is slightly dense with parentheses, but it remains efficient and avoids unnecessary detail.
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 the tool's simplicity (1 parameter, no output schema, rich annotations), the description covers the essential behavior: what data is returned, error handling, and the explicit nature of missing accounts. It is complete enough for an agent to use 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?
The input schema has 100% description coverage, fully detailing the 'id' parameter with multiple SteamID formats. The description adds no additional parameter-specific meaning beyond what the schema provides. Baseline score of 3 is appropriate.
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 clearly states it returns a FACEIT player object with specific fields (nickname, country, per-game skill level, ELO) plus bans. It also clarifies behavior when no account exists. However, it does not explicitly differentiate from sibling tools like steam_profile or steam_bans, which could also return player or ban data.
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?
No guidance is provided on when to use this tool vs. alternatives such as steam_bans, steam_profile, or steam_identity. The description only mentions error handling for missing accounts, which is helpful but does not help the agent decide between tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Known friends of a player from the platform's snapshot of the public Steam friend graph (cache only, no live Steam call; the snapshot can be partial). detail picks token cost: short - steamid64 array, medium - steamid64 + personaname, full - raw Steam objects. Use short unless you need names.
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral traits beyond annotations: it uses a cache snapshot (no live Steam call), may be partial, and provides token cost per detail level. Annotations already declare readOnly and idempotent, which the description confirms. This adds value by explaining data freshness and response format implications.
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 three concise sentences with no wasted words. First sentence states purpose and key behavioral trait (cache snapshot). Second sentence explains detail levels and their cost. Third sentence gives explicit recommendation. Each sentence earns its place, and the structure front-loads the most critical information.
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 output schema, the description explains short and medium output formats and states that full mode returns raw Steam objects. This gives adequate expectations for return values. The limit parameter is documented in the schema but not repeated in the description, which is acceptable given schema coverage. The partial snapshot note fills a gap. Slightly more detail on limit behavior or pagination would push to 5.
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 adds significant value for the 'detail' parameter by specifying exact output structures (short: steamid64 array, medium: steamid64+personaname, full: raw Steam objects), which is not in the schema. It also recommends 'short' for efficiency, aiding parameter selection beyond schema descriptions.
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 clearly states the tool retrieves 'Known friends of a player from the platform's snapshot of the public Steam friend graph.' The verb 'retrieve' is implied, and the resource is 'Steam friends.' It distinguishes itself from siblings like steam_profile and steam_summary by specifying it deals with the friend graph, not individual profiles or summaries.
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 description offers guidance on the detail parameter ('Use short unless you need names') but does not explicitly state when to use this tool versus sibling tools. While the tool's name and purpose imply it for friend list retrieval, no alternatives or exclusions are mentioned, leaving the agent to infer context from the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Pure identifier resolver: steamid64, SteamID (STEAM_1:0:x), SteamID3 ([U:1:x]), steam hex, vanity name and profile URL. No profile data - fewest tokens. If the id cannot be resolved, returns an error result with a machine-readable message - never a partial guess.
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is well-covered. The description adds behavioral nuances beyond annotations: it returns only the resolved ID ('fewest tokens'), fails with a machine-readable error (no partial guesses), and handles many formats. This is valuable context about error behavior and scope.
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, every clause earns its keep: lists accepted formats, sets scope boundary, makes token cost claim, and describes error behavior. No fluff.
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 resolver tool with 100% schema coverage and comprehensive annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false), the description provides sufficient behavior, scope, and error details. It's missing explicit output format documentation (e.g., what the successful response looks like), but given no output schema, it still conveys the minimal data promise clearly.
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%, so the schema already documents the single parameter 'id' with a clear list of acceptable formats. The description adds no new parameter-level details (no change from baseline 3). However, given the parameter count is 1 and the schema is exhaustive, the description's lack of additional param info is acceptable.
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 clearly states it resolves Steam identifiers (steamid64, SteamID, SteamID3, hex, vanity names, URLs) and sets expectations by noting it's a pure identifier resolver with no profile data. It distinguishes from potential profile-related siblings but doesn't explicitly differentiate from steam_convert or steam_batch.
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 description clarifies when to use this tool (for resolving any Steam identifier format to steamid64) and what not to use it for ('No profile data'). It implies this is the minimal, cheap option for ID resolution, contrasting with sibling tools that likely return richer data. No explicit alternatives named, but the context signals and sibling list allow inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Steam summary only (raw GetPlayerSummaries object + 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.
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, openWorldHint, idempotentHint, destructiveHint=false), the description adds critical behavioral details: caching policy (48 hours), lazy fetching for unknown profiles, private profile handling (public subset, not error), and unresolvable ID behavior (error). This fully informs the agent of the tool's behavior.
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 concise at three sentences, each serving a distinct purpose: purpose, usage context, and edge cases. It is front-loaded with the core purpose and wastes no 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?
Given the tool's simplicity (one parameter, no output schema), the description covers purpose, caching, private profile behavior, and error handling. It does not detail the return structure beyond 'raw GetPlayerSummaries object', but that is a known Steam API object. Minor gap: no mention of rate limits or authentication, but annotations imply open access. Overall adequate.
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 input schema already provides 100% coverage with a detailed description of the 'id' parameter. The tool description does not add new semantic meaning about the parameter beyond what the schema specifies. Baseline 3 is appropriate as the schema carries the burden.
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 clearly states the tool returns a 'raw GetPlayerSummaries object + SteamID conversions' and identifies it as a 'cheapest profile tool', distinguishing it from siblings like steam_summary and steam_convert. It specifies the verb (summary only) and resource (profile), making the purpose unambiguous.
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 description provides context for when to use this tool: 'cheapest profile tool' and mentions data freshness ('no older than 48 hours, unknown profiles fetched live'). It does not explicitly exclude alternatives or state when not to use it, but the guidance is clear enough for an agent to infer its lightweight, cached nature.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Steam player overview in one call. presets: include=[] equals full; for competitive checks pass include ["faceit","bans"]. Responses carry provenance.fresh and sources/partial - branch on them. Overview: 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).
| 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 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered. The description adds valuable behavioral details: responses carry 'provenance.fresh' and 'sources/partial' flags that the agent must branch on, and the 'friends_limit' caps the friend list. The only minor gap is not explaining what 'sources/partial' indicates exactly, but the mention is sufficient for an agent to handle branching.
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 well-structured: it starts with the core promise, then introduces the 'include' presets, then the response structure, then detailed parameter guidance. It's efficient but could be slightly tighter by removing the redundant 'Overview:' line which restates the first sentence. The inline examples are helpful without being verbose.
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 the tool has no output schema, the description does a good job explaining the return structure (blocks, provenance flags). It covers all four parameters clearly. The sibling tools are meaningful (steam_friends, steam_bans, etc.) and the description differentiates this aggregator. The only gap is not explaining the 'friends_detail' parameter's impact on rate/size, but the schema's enum hints are sufficient for an agent.
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 the baseline is 3. The description adds significant value beyond the schema: it explains the 'include' presets in practical terms (e.g., 'omit it for everything'), gives a concrete example for ban checks, and clarifies the interaction between 'include' and the friends list. The 'friends_limit' is described in context of the default. Only minor improvement would be explicitly stating that 'friends_detail' defaults to 'full', but the schema already says 'default full'.
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 clearly states the tool provides a 'Steam player overview in one call' and lists exactly which blocks are included: Steam summary, ban status, SteamID conversions, FACEIT stats, and the first 100 friends. It distinguishes itself from sibling tools like steam_bans, steam_faceit, and steam_friends by being the comprehensive aggregation endpoint.
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 description gives explicit guidance on when to use each option of the 'include' parameter: omit for full, ['steam'] for cheapest, ['bans'] for ban check only, ['faceit','bans'] to drop friends. It also provides a use case ('competitive checks') and explains the trade-off between cost and completeness.
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. Dates show when Glama detected each change.
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_summaryClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Steam Web API: profiles, owned games, achievements, app news, player counts.
Roblox public profile + friends + badges + games + groups lookups.
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.
Tools are mostly distinct: steam_identity for ID resolution, steam_bans for bans, steam_faceit for FACEIT, steam_friends for friends, steam_batch for bulk, steam_compare for comparison. Minor overlap exists between steam_profile and steam_summary, but descriptions clarify steam_profile is the raw/cheapest summary while steam_summary is a richer overview with includes.
All tool names follow a consistent steam_<noun> pattern in lowercase snake_case. The prefix clearly groups them under the Steam domain, and each noun reflects the specific data type or operation, making the naming predictable and readable.
With 8 tools, the server is well-scoped for a Steam data API. Each tool covers a distinct aspect (identity, bans, profile, friends, FACEIT, batch, compare), and none feel redundant or unnecessary. The count is within the ideal 3-15 range.
The toolset covers core player data needs: identity resolution, profile summaries, bans, friends, FACEIT, batch lookups, and comparison. Minor gaps exist (e.g., no direct game/playtime data), but for the apparent purpose of player review and cheating reports, the coverage is solid.
