The PlayFab MCP Server acts as middleware enabling AI models and large language models to interact with PlayFab services seamlessly. You can:
Search for items using the search_items API, with filtering options
Get all segments via the get_all_segments API
Query player profiles within specified segments
Get all players using the get_all_players API
Retrieve current inventory items via get_inventory_items
Fetch inventory collection IDs using get_inventory_collection_ids
Convert PlayFab IDs to Title Player Account IDs using get_title_player_account_id_from_playfab_id
Allows GitHub Copilot in Agent mode to query and interact with Azure Cosmos DB data, supporting operations like listing vehicles and other database queries
Runs the MCP server that facilitates communication between AI models and Azure Cosmos DB, processing queries and returning results
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@PlayFab MCP Server show me the inventory for player PF123456789"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
This server is a middleware that enables large language models (like Claude and VS Code) to interact directly with PlayFab services. Acting as a secure and efficient translator, it connects your AI assistant with various PlayFab functionalities, such as item search, segment inquiries, player profile lookups, inventory management, and PlayFab ID conversion.
You: "Show me the latest 10 items."
Claude: *calls the PlayFab search_items API and returns the results in plain text*Related MCP server: Azure Cosmos DB MCP Server
This server leverages the Model Context Protocol (MCP) to establish a universal interface between AI models and PlayFab services. Although MCP is designed to support any AI model, it is currently available as a developer preview.
Follow these steps to get started:
Set up your project.
Add your project details to your LLM client's configuration.
Start interacting with PlayFab data naturally!
Search for items using PlayFab's search_items API.
Catalog Management (Economy v2):
Create new draft items with the create_draft_item API.
Update existing draft items with the update_draft_item API.
Delete items from catalog with the delete_item API.
Publish draft items to make them available with the publish_draft_item API.
Get detailed item information with the get_item API.
Retrieve comprehensive segment information.
Query player profiles within specified segments.
Convert a PlayFab ID to a Title Player Account ID via the get_title_player_account_id_from_playfab_id API.
Get detailed user account information with the get_user_account_info API.
Get Operations:
Retrieve current inventory items with the get_inventory_items API.
Fetch inventory collection IDs using the get_inventory_collection_ids API.
Add/Remove Operations:
Add items to inventory with the add_inventory_items API.
Delete items from inventory with the delete_inventory_items API.
Subtract specific amounts with the subtract_inventory_items API.
Modify Operations:
Update item properties with the update_inventory_items API.
Execute batch inventory operations with the execute_inventory_operations API.
Note: In Economy v2, virtual currencies are managed as inventory items.
Ban players by ID, IP, or MAC address with the ban_users API.
Unban players completely with the revoke_all_bans_for_user API.
Retrieve player custom data with the get_user_data API.
Update player custom data with the update_user_data API.
Set global title data with the set_title_data API.
Retrieve title data with the get_title_data API.
Set server-only internal data with the set_title_internal_data API.
Retrieve internal data with the get_title_internal_data API.
Node.js 18 or higher.
A valid PlayFab account (obtain your Title ID and Developer Secret Key via PlayFab Game Manager).
A supported LLM client such as Claude Desktop.
Obtain your PlayFab Title ID and Developer Secret Key from the PlayFab Game Manager, then create a .env file in the project root with the following content (replace the placeholders with your actual credentials):
PLAYFAB_TITLE_ID=
PLAYFAB_DEV_SECRET_KEY=Install Dependencies
In the project root, run the following command to install all necessary dependencies:
npm installBuild the Project
Compile the project by executing:
npm run buildStart the Server
Start the server by executing:
npm startConfirmation Message
Upon startup, you should see this message:
PlayFab Server running on stdioESLint: Configured for TypeScript with recommended rules for code consistency
Prettier: Automatic code formatting with project-specific settings
TypeScript: Strict mode enabled for enhanced type safety
Jest: Testing framework configured for TypeScript
# Build the project
npm run build
# Development mode with file watching
npm run watch
# TypeScript type checking
npm run typecheck
# Run ESLint
npm run lint
# Run ESLint and fix issues
npm run lint:fix
# Format code with Prettier
npm run format
# Check code formatting
npm run format:check
# Run tests
npm test
# Run tests in watch mode
npm run test:watch
# Run tests with coverage
npm run test:coverageThis project uses TypeScript with strict mode enabled, ensuring:
Strict null checks
No implicit any types
Strict function types
Always strict mode
Tests are written using Jest and can be found in __tests__ directories or files with .test.ts extension. Run tests before committing changes to ensure code quality.
Install CLI: uv tool install specify-cli --from git+https://github.com/akiojin/spec-kit.git
Create spec/plan/tasks: ./.specify/scripts/bash/create-new-feature.sh "feature summary"ïŒăăă©ă«ăăŻăă©ăłăăäœæăăȘăăćż
èŠăȘă --branchïŒ
Assets: .specify/templates/*, .specify/scripts/bash/*, specs under specs/
Claude/Codex slash commands: /speckit.constitution, /speckit.specify, /speckit.plan, /speckit.tasks, /speckit.implement
The repository ships with a lightweight dev container (Node 22, tooling, GitHub CLI).
# Build image
docker compose build
# Open a shell inside the container
docker compose run --rm playfab-mcp-server bash
# Inside the container
npm ci
npm run build
npm startVolumes keep your workspace (.), Codex/Claude configs, and shell history. Set PLAYFAB_TITLE_ID / PLAYFAB_DEV_SECRET_KEY in the container env when running the server.
To use the PlayFab MCP server with Cursor, follow these steps:
Install Cursor Desktop if you haven't already.
Open a new instance of Cursor in an empty folder.
Copy the mcp.json file from this repository into your folder and update the values according to your environment.
Launch Cursor; the PlayFab MCP Server should appear in the tools list.
For example, try a prompt like "Show me the latest 10 items" to verify that the server processes your query correctly.
Open Claude Desktop and navigate to File â Settings â Developer â Edit Config. Then, replace the claude_desktop_config file content with the following snippet:
{
"mcpServers": {
"playfab": {
"command": "npx",
"args": [
"-y",
"@akiojin/playfab-mcp-server"
],
"env": {
"PLAYFAB_TITLE_ID": "Your PlayFab Title ID",
"PLAYFAB_DEV_SECRET_KEY": "Your PlayFab Developer Secret Key"
}
}
}
}With these steps, you have successfully configured the PlayFab MCP server for use with your LLM client, allowing seamless interaction with PlayFab's services.
This repository follows the Spec Kit SDD/TDD workflow used in akiojin/gwt.
Requirements: Python 3.11+ and uv
Install CLI: uv tool install specify-cli --from git+https://github.com/akiojin/spec-kit.git
Assets: templates under .specify/templates, scripts under .specify/scripts/bash, specs live in specs/
Create a new spec/plan: ./.specify/scripts/bash/create-new-feature.sh "feature summary" (add --branch if you also want a branch)
Generated files include spec.md, plan.md, tasks.md; keep them reviewed/committed alongside code
Claude/Codex slash commands (if available): /speckit.constitution, /speckit.specify, /speckit.plan, /speckit.tasks, /speckit.implement
This project follows Conventional Commits for automated versioning and release.
<type>(<scope>): <subject>
<body>
<footer>feat: A new feature (triggers MINOR version bump)
fix: A bug fix (triggers PATCH version bump)
docs: Documentation only changes
style: Changes that do not affect the meaning of the code
refactor: A code change that neither fixes a bug nor adds a feature
perf: A code change that improves performance
test: Adding missing tests or correcting existing tests
chore: Changes to the build process or auxiliary tools
MAJOR version: When commit message contains BREAKING CHANGE in footer or ! after type/scope
Example: feat!: remove deprecated API endpoints
Example: feat: new API\n\nBREAKING CHANGE: removed old endpoints
MINOR version: When commit type is feat
Example: feat: add new PlayFab API integration
PATCH version: When commit type is fix
Example: fix: correct error handling in API calls
Prepare release PR: Run the prepare-release.yml workflow to open a PR from develop to main
Actions UI: Prepare Release â run with ref develop
CLI: gh workflow run prepare-release.yml --ref develop
If a PR from develop already exists, it will be reused; PRs opened from develop can be auto-merged by the workflow.
Release automation: When main is updated, release.yml runs release-please (manifest) to bump versions, update CHANGELOG.md, and create the GitHub Release/tag.
Publish: Tag push v* triggers publish.yml to run tests, build, typecheck, and npm publish --access public.
Required secrets:
PERSONAL_ACCESS_TOKEN (optional; used by prepare-release/release when provided, falls back to GITHUB_TOKEN)
NPM_TOKEN (for publish.yml)
Branch protection: keep protections on main; release PRs should satisfy required checks before merge.
Script | Description |
| Start the MCP server |
| Build TypeScript to JavaScript |
| Build in watch mode for development |
| Run TypeScript type checking |
| Run ESLint checks |
| Fix ESLint issues automatically |
| Format code with Prettier |
| Check code formatting |
| Run all tests |
| Run tests in watch mode |
| Generate test coverage report |
We take security seriously. If you discover a security vulnerability within this project, please follow these steps:
DO NOT create a public GitHub issue for security vulnerabilities
Instead, please report security issues via GitHub's private vulnerability reporting:
Go to the Security tab of this repository
Click on Report a vulnerability
Provide detailed information about the vulnerability
A description of the vulnerability
Steps to reproduce the issue
Potential impact
Any suggested fixes (optional)
We will acknowledge receipt of your report within 48 hours
We will provide regular updates on our progress
We will credit you for the discovery (unless you prefer to remain anonymous)
When using this server:
Never commit credentials: Always use environment variables for sensitive data
Keep dependencies updated: Regularly run npm audit and update packages
Use least privilege: Only grant the minimum required permissions
Rotate keys regularly: Change your PlayFab Developer Secret Keys periodically
If you encounter any issues or have questions about using the PlayFab MCP Server, here are the best ways to get support:
GitHub Issues: For bug reports and feature requests, please create an issue
Discussions: For general questions and community support, use GitHub Discussions
Documentation: Check the README and code comments for usage examples
Please check if your issue has already been reported by searching existing issues. If you find a similar issue, you can add additional information as a comment.
Installation and setup questions
Bug reports with reproducible steps
Feature requests and suggestions
Documentation improvements
General PlayFab API questions (please refer to PlayFab Documentation)
Issues with third-party tools or services
Custom implementation requests
This project is licensed under the MIT License - see the LICENSE file for details.
PlayFab get all players
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action without disclosing behavioral traits such as pagination, rate limits, authentication needs, or what 'all players' entails (e.g., active only, includes metadata). This leaves significant gaps for safe and effective use.
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 phrase 'PlayFab get all players', which is concise but under-specified. It front-loads the core action but lacks necessary context to be fully helpful. While not verbose, it misses opportunities to add value in a compact form.
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 annotations, no output schema, and a simple but vague description, this is incomplete for a tool that likely returns a list of players. The description doesn't explain return values, error handling, or operational constraints, leaving the agent with insufficient information for reliable use.
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 tool has 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here. Baseline is 4 for zero parameters, as the schema fully covers the absence of inputs.
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 'PlayFab get all players' states the action ('get') and resource ('players'), but lacks specificity about scope or format. It distinguishes from siblings like 'get_all_segments' by resource type, but doesn't clarify if this retrieves all players globally or within a context. The purpose is understandable but vague.
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 versus alternatives like 'search_items'. The description doesn't mention prerequisites, limitations, or typical use cases. Without annotations or context, the agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PlayFab get all segments
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states the action ('get all segments') without any details on what this entailsâe.g., whether it's a read-only operation, if it requires authentication, how it handles pagination or rate limits, or what the output looks like. This is inadequate for a tool with no annotation support.
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 ('PlayFab get all segments'), which could be efficient, but it under-specifies the tool's purpose and context. While it avoids unnecessary words, it fails to provide essential information that would help an agent use the tool correctly, making this brevity more of a deficiency than a strength.
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 lack of annotations, no output schema, and a simple input schema with no parameters, the description is incomplete. It does not explain what 'segments' are, how the tool behaves, or what to expect in return, leaving significant gaps for an agent to understand and invoke the tool effectively in the context of sibling tools like 'get_all_players'.
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 0 parameters with 100% coverage, meaning there are no parameters to document. The description does not add parameter details, which is appropriate here. A baseline of 4 is applied since no parameters exist, and the description does not mislead about inputs.
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 'PlayFab get all segments' restates the tool name with minimal elaboration. It specifies the action ('get all') and resource ('segments'), but lacks specificity about what 'segments' are in the PlayFab context or how this differs from sibling tools like 'get_all_players' or 'search_items'. This is borderline tautological, as it essentially repeats the name with the platform prefix added.
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 no guidance on when to use this tool versus alternatives. It does not mention sibling tools like 'get_all_players' or 'search_items', nor does it specify contexts, prerequisites, or exclusions for usage. This leaves the agent with no information to make an informed choice among available tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
PlayFab search items
| Name | Required | Description | Default |
|---|---|---|---|
| continuationToken | No | An opaque token used to retrieve the next page of items, if any are available. | |
| count | Yes | Number of items to retrieve. This value is optional. Maximum page size is 50. Default value is 10. | |
| filter | No | An OData filter used to refine the search query (For example: "type eq 'ugc'"). More info about Filter Complexity limits can be found here: https://learn.microsoft.com/en-us/gaming/playfab/features/economy-v2/catalog/search#limits | |
| orderBy | No | An OData orderBy used to order the results of the search query. For example: "rating/average asc" | |
| search | No | The text to search for. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It reveals nothing about whether this is a read/write operation, authentication requirements, rate limits, pagination behavior (beyond what's implied by continuationToken in schema), error conditions, or response format. For a search tool with 5 parameters and no output schema, this is critically inadequate.
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?
While technically concise (two words), this is under-specification rather than effective brevity. The description fails to front-load essential information and doesn't earn its place - it provides almost no value beyond the tool name itself. A truly concise description would still convey core purpose and context.
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 complexity (5 parameters, no output schema, no annotations), the description is completely inadequate. It doesn't explain what 'items' are, what search capabilities exist, how results are returned, or any behavioral characteristics. For a search operation that likely returns structured data, the absence of output schema means the description should at minimum indicate the nature of returned results.
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 fully documents all 5 parameters. The description adds no parameter information beyond what's already in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info 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 'PlayFab search items' is a tautology that merely restates the tool name with a platform prefix. It doesn't specify what 'items' refers to (catalog items, inventory items, etc.), what action 'search' performs (filtering, text search, or both), or what resource domain this operates in. While it distinguishes from the sibling tools (which target players/segments rather than items), the purpose remains vague.
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 no guidance on when to use this tool versus alternatives. There's no mention of prerequisites, appropriate contexts, or comparison with other search methods. The sibling tools (get_all_players, get_all_segments) target different resources, but the description doesn't help an agent decide between searching items versus retrieving players/segments.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a clearly distinct purpose targeting different PlayFab resources: players, segments, and items. There is no overlap in functionality, making it easy for an agent to select the correct tool without confusion.
All tool names follow a consistent verb_noun pattern (get_all_players, get_all_segments, search_items), using snake_case throughout. This predictability enhances readability and usability.
With only 3 tools, the server feels under-scoped for a platform like PlayFab, which typically involves more operations such as creating/updating players, managing items, or handling segments. This limited set may hinder agent workflows.
The toolset is severely incomplete for PlayFab's domain, covering only retrieval operations (get_all and search) without any create, update, or delete capabilities. This leaves significant gaps that will likely cause agent failures in broader tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
GibsonAI MCP server: manage your databases with natural language
Official Microsoft MCP Server to query Microsoft Entra data using natural language
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
The Ramp MCP server enables users to securely connect Ramp with AI assistants like ChatGPT and Claude to query financial data and take actions using natural language. It transforms Ramp's developer API into a SQL interface that LLMs can query, allowing admins to analyze spend trends, identify cost savings, and run complex SQL analyses on comprehensive datasets (transactions, purchase orders, vendors, users), while all users can manage cards, view transactions, request reimbursements, and get expense policy answers.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/akiojin/playfab-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
