SteamGPT

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is clear. The description adds value by listing the exact output fields (VACBanned, NumberOfVACBans, etc.), which compensates for the absence of an output schema. No behavioral traits are hidden beyond what is disclosed.

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 extremely concise: two sentences that front-load the purpose and list the output fields, then add usage guidance. Every sentence contributes value, and there is no redundant or verbose content.

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?

The tool is simple (one parameter, no output schema). The description adequately covers what the tool returns (list of ban fields) and when to use it. It doesn't explain error handling or interpretation of fields, but for a straightforward ban-check tool, this is sufficient for most agents.

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?

There is only one parameter 'id' with a comprehensive schema description covering multiple Steam ID formats (steamid64, STEAM_1:0:x, etc.). The tool description does not add any additional meaning to the parameter beyond what the schema already provides, so the baseline score of 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?

The description clearly states the tool checks 'Steam ban status of a player' and enumerates the specific ban fields returned (VACBanned, NumberOfVACBans, etc.). This distinguishes it from sibling tools like steam_profile or steam_friends, which serve different purposes.

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 recommends this tool as the 'first thing to check when reviewing a cheating report,' providing clear context for when to use it. While it doesn't mention when not to use it or alternatives, the recommendation is strong and sufficient for a simple tool.

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

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

Annotations already mark it as readOnlyHit, idempotent, openWorld, non-destructive. The description adds valuable beyond-annotation details: batch pricing (one request for 100), constraints on input (only steamid64 strings, precision issues with numbers), handling of unknowns (not_found array), and cost benefits of batched includes. It doesn't contradict 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?

Five focused sentences, no fluff. The core value proposition ('one batch of 100 costs one request') leads, followed by key constraints and options. Every sentence 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?

Given no output schema, the description mentions not_found but doesn't explicitly describe the full response structure (e.g., array of profiles). However, for a batch tool, the usage context, constraints, and optimization advice cover most practical needs. A slight gap on return format prevents a 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%, but the description adds critical nuance: 'Accepts ONLY steamid64 STRINGS (no vanity resolution, no numbers - a 17-digit JSON number loses precision and points at another account)' for the ids parameter, and explains what each include enum yields ('faceit level/ELO, Steam ban status'). This significantly enhances understanding 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 clearly states the tool fetches 'Up to 100 Steam profiles in one call' and distinguishes it from per-player calls (e.g., steam_profile). The verb 'batch' and resource 'Steam profiles' are specific, and the advice to prefer this over per-player calls for multiple players differentiates it from siblings.

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 instructs 'ALWAYS use this instead of per-player calls' and explains the cost benefit. It provides alternative actions for unknown players ('fetch those with steam_profile') and details when to use the optional include parameters (FACEIT, bans). This gives clear when-to and when-not-to guidance.

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

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 valuable behavioral context beyond that: it reveals that the tool builds two summaries plus both friend graphs, and labels itself as the heaviest tool, which implies significant computational cost and possible rate limits. 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?

Two sentences with zero waste: the first front-loads the purpose and scope, the second provides critical usage guidance. Every word serves a clear function, making it highly efficient for an agent to parse.

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 moderate complexity (2 required params, no nested objects, no output schema) and the richness of annotations, the description covers the essential aspects: what it does, what data it compares, and when to avoid it. It does not describe the return format, but the purpose is well-understood. A slight gap for completeness but 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?

Schema description coverage is 100%, so both parameters are well-documented in the schema. The description does not add any meaning beyond what the schema provides for the parameters themselves; it only contextualizes their use (two players). Baseline 3 is appropriate as the description adds no extra syntactic or semantic detail.

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 compares two players side-by-side, listing specific data points compared (identity, account age, visibility, Steam bans, FACEIT, shared friends). It distinguishes from siblings by emphasizing the comparative aspect and full friend list analysis, leaving no ambiguity about the tool's function.

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 warns this is the 'HEAVIEST tool' and advises using steam_summary for a single player, providing clear when-to-use and when-not-to-use guidance. This effectively helps an agent choose between sibling tools.

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

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

Annotations already provide readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, giving the agent a clear safety profile for a non-destructive read operation. The description adds meaningful behavioral context by specifying that ban information is included, which goes beyond the annotation signals. No contradictions exist.

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 sentence with a parenthetical list of returned data, perfectly efficient. It conveys all essential information without extraneous words, fitting the conciseness criteria optimally for a simple tool.

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 low complexity (1 parameter, no output schema, no nested objects), the description adequately covers what the tool returns and its purpose. The absence of an output schema means the description compensates by listing specific fields returned. However, it does not mention what happens if the player has no FACEIT profile or bans, or any error scenarios, which would be ideal for completeness.

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% for the single 'id' parameter, which already has a detailed description in the schema listing accepted formats. The tool's description does not add further parameter documentation, but with full schema coverage and only one parameter, the baseline is 3. However, the description's mention of 'play object content (nickname, country...)' adds implicit context about the parameter's purpose (identifying which player to look up), justifying a slight increase.

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 FACEIT player object containing specific fields (nickname, country, per-game skill level and ELO) plus known bans. It specifies the resource (FACEIT player profile) and the verb is implied by returning object data, distinguishing it clearly from siblings like steam_profile which likely returns Steam profile 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?

The description does not explicitly state when to use this tool versus alternatives like steam_profile or steam_bans. The context from sibling names suggests this is specialized for FACEIT data, but no direct comparison or guidance on selection criteria is provided. The usage is implied by the tool's name and description, but lacks explicit when-not-to-use or alternative recommendations.

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

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

The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint as false, so the description carries the burden of adding context. The description transparently discloses that the data is from a cache ('cache only, no live Steam call') and that the snapshot can be partial, which is valuable behavioral context beyond the annotations. No contradiction 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 concise with three sentences, all of which serve a purpose: defining the resource, explaining the caching behavior, and providing parameter usage guidance. It is front-loaded with the core purpose. 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?

Given the tool has 3 parameters, 100% schema coverage, no output schema, and detailed annotations, the description adequately covers the key behavioral aspects (cache, partial snapshot, detail levels). It could be improved by mentioning the return format (e.g., array or objects) since there is no output schema, but the detail parameter description partially addresses this.

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 schema coverage is 100%, so the baseline is 3. The description adds significant value by explaining the 'detail' parameter's token cost ('short - steamid64 array, medium - steamid64 + personaname, full - raw Steam objects') and recommending a default ('Use short unless you need names'). This goes beyond the schema's enum description of 'response detail level'.

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 fetches 'known friends of a player from the platform's snapshot of the public Steam friend graph', specifying a specific verb, resource, and data source. It distinguishes from siblings like steam_profile, which focuses on individual player data, and steam_bans, which is about bans, making it clear that this tool is specifically for the friend list.

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 explicit guidance on when to use the different detail levels ('Use short unless you need names'), which helps the agent choose the appropriate parameter. However, it does not offer guidance on when to use this tool over alternatives like steam_batch or steam_compare, though the function is straightforward enough that the context of 'friends' implies its use case.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint, covering safety and idempotency. The description adds that it is a 'pure identifier resolver' with 'fewest tokens', but it does not disclose potential error handling or what happens if the identifier is invalid. The description adds marginal behavioral context beyond the 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 extremely concise: two sentences that front-load the core purpose and list supported formats. Every word contributes value, and there is 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, rich annotations, no output schema), the description is complete. It explains what the tool does, what it does not do, and the supported input formats. The agent can confidently select and invoke this tool based on the provided information.

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 description already lists the accepted formats. The tool description repeats a similar list but does not add new meaning beyond what the schema provides. Baseline 3 is appropriate as the description does not increase parameter understanding 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 clearly states it is a 'pure identifier resolver' and lists the specific input formats: steamid64, SteamID, SteamID3, steam hex, vanity name, and profile URL. It also distinguishes itself from sibling tools like steam_profile or steam_summary by stating 'No profile data - fewest tokens', 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 implies when to use this tool: when you need to resolve various Steam identifiers to a standard form without retrieving profile data. It contrasts with siblings that likely return profile data, but it does not explicitly state when not to use it or provide alternatives. The context is clear enough for an agent to infer usage.

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

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

Annotations already mark the tool as readOnlyHint: true, idempotentHint: true, and destructiveHint: false, covering safety. The description adds value by disclosing the 48-hour cache TTL and the conditional live fetch for unknown profiles, which are behavioral details beyond the 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?

Two sentences with no filler. Each sentence adds distinct value: what the tool returns, its cost/performance characteristic, data freshness policy, and special handling for unknown profiles.

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 single-parameter schema with full coverage, no output schema, and annotations that already declare safety, the description adequately covers purpose, usage, and behavioral detail. A minor gap is lacking an explicit note about error conditions (e.g., invalid ID), but the parameter documentation mitigates this.

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 lists many accepted formats for the 'id' parameter. The description adds clarity by summarizing those formats as 'steamid64 (17 digits), STEAM_1:0:x, [U:1:x], steamcommunity.com profile link or vanity name', making it easier to understand without reading the full 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 it returns 'raw GetPlayerSummaries object + SteamID conversions', clearly identifying the resource and output format. It also notes this is the cheapest profile tool, distinguishing itself from siblings like steam_summary or steam_identity.

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 says it's the cheapest profile tool and mentions data staleness rules ('no older than 48 hours, unknown profiles fetched live'), implying when to use it. However, it doesn't contrast with specific siblings (e.g., when to prefer steam_summary over this).

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well-covered. The description adds beyond annotations by disclosing that responses carry 'provenance.fresh and sources/partial - branch on them', which is behavioral context about caching/incompleteness that the agent needs to handle correctly. One minor gap: it doesn't describe what happens if the profile is private or invalid.

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 purpose in the first sentence. It efficiently covers behavior, presets, and filtering in 4 sentences. Slightly dense with comma-separated explanations in the overview list, but every sentence earns its place. One sentence could be restructured for readability (the 'include LIMITS...' part slightly repeats 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?

Given there is no output schema, the description provides a comprehensive overview of what each block returns (Steam summary, bans, identity conversions, FACEIT stats, first 100 friends). It covers the key behavioral trait (sources/partial branching) and the include/friends_limit parameters. For a complex aggregator tool with 4 parameters and 7 sibling tools, this is remarkably complete.

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 meaningfully by explaining that include=[] equals full and that limit caps the friend list with a default of 100. It also provides concrete examples like ['steam'] for cheapest and ['bans'] for ban check only. These examples go beyond the schema's enum values. The only minor gap is that friends_detail values are mentioned in schema but not elaborated in description.

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 starts with a clear verb and resource ('Steam player overview'), immediately establishes what the tool aggregates (Steam summary, ban status, SteamID conversions, FACEIT stats, first 100 friends), and differentiates from siblings like steam_bans, steam_faceit, and steam_friends by offering them all in one call with the include filter.

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 tells the agent when to use the tool ('for competitive checks pass include ["faceit","bans"]'), and provides clear alternatives within the tool itself via the include parameter (omit for everything, ['steam'] as cheapest, ['bans'] for ban check only). It also explains when to drop the friend list with ['faceit','bans']. This provides strong usage guidance without needing external sibling names.

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