Skip to main content
Glama

get_player_peers

Retrieve players frequently matched with a specific Dota 2 player by Steam32 account ID to analyze team dynamics and common allies.

Instructions

Get players who have played with the specified player.

Args:
    account_id: Steam32 account ID of the player
    limit: Number of peers to retrieve (default: 5)

Returns:
    List of players frequently played with

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
account_idYes
limitNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Implementation Reference

  • The core handler function for the 'get_player_peers' MCP tool. It is decorated with @mcp.tool(), which serves as both the implementation and registration in FastMCP. Fetches peer data from OpenDota API endpoint 'players/{account_id}/peers', sorts by games played together, and formats a response listing top peers with stats.
    @mcp.tool()
    async def get_player_peers(account_id: int, limit: int = 5) -> str:
        """Get players who have played with the specified player.
    
        Args:
            account_id: Steam32 account ID of the player
            limit: Number of peers to retrieve (default: 5)
    
        Returns:
            List of players frequently played with
        """
        if limit > 20:
            limit = 20  # Cap for reasonable response size
    
        peers_data = await make_opendota_request(f"players/{account_id}/peers")
    
        if "error" in peers_data:
            return f"Error retrieving peers data: {peers_data['error']}"
    
        if not peers_data or not isinstance(peers_data, list) or len(peers_data) == 0:
            return "No peers found for this player."
    
        # Sort by games played together
        sorted_peers = sorted(peers_data, key=lambda x: x.get("games", 0), reverse=True)
    
        formatted_peers = []
    
        for i, peer in enumerate(sorted_peers[:limit]):
            peer_account_id = peer.get("account_id", "Unknown")
            peer_name = peer.get("personaname", "Anonymous")
            games = peer.get("games", 0)
            wins = peer.get("win", 0)
            win_rate = (wins / games * 100) if games > 0 else 0
    
            formatted_peers.append(
                f"{i+1}. {peer_name} (ID: {peer_account_id})\n"
                f"   Games together: {games}\n"
                f"   Wins: {wins}\n"
                f"   Win Rate: {win_rate:.2f}%"
            )
    
        return f"Peers for Player ID {account_id}:\n\n" + "\n\n".join(formatted_peers)
  • The @mcp.tool() decorator registers the get_player_peers function as an MCP tool with the name matching the function name.
    @mcp.tool()
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool retrieves a list of 'frequently played with' players, hinting at aggregation logic, but lacks details on data freshness, rate limits, authentication needs, error handling, or pagination. The description is minimal and misses key operational traits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose, followed by structured Args and Returns sections. Each sentence earns its place by defining functionality, parameters, and output without redundancy. It is appropriately sized for a simple lookup tool, with zero waste.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's low complexity (2 parameters, no nested objects) and the presence of an output schema (which covers return values), the description is moderately complete. It explains the basic operation and parameters but lacks behavioral context (e.g., how 'frequently played with' is determined). With no annotations, it should do more to guide safe usage.

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 description coverage is 0%, so the description must compensate. It adds meaningful semantics: account_id is explained as 'Steam32 account ID of the player', and limit specifies 'Number of peers to retrieve' with a default value. This clarifies parameter purposes beyond the schema's basic titles, though it could detail format constraints (e.g., integer range for limit).

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?

The description clearly states the tool's purpose with a specific verb ('Get') and resource ('players who have played with the specified player'), distinguishing it from siblings like get_player_by_id (which retrieves a single player's data) or get_player_recent_matches (which focuses on match history). It precisely identifies the target resource and relationship.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing a valid account_id), exclusions, or comparisons to similar tools like get_player_recent_matches (which might include peer data indirectly) or search_player (for finding players by name). Usage context is implied but not explicit.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/asusevski/opendota-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server