SteamGPT

Steam profile summary

steam_summary

Read-onlyIdempotent

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).

Input Schema

Name	Required	Description
`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

Output Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 30, 2026

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"
+}

Changed1 schema field changedAug 18, 2026

changedInput schema / properties / id / description

Previous 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"

First observedAug 18, 2026

TDQS

A4.8/5.0

Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines5/5

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.

All SteamGPT tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?