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., "@bringfour what beats my trick room team?"
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.
Give your AI assistant a competitive Pokémon brain. An MCP server (plus a local web dashboard) that turns Claude, Cursor, or any MCP client into a VGC teambuilding partner — real usage stats, real damage calcs, and threat reports grounded in math instead of type-chart guessing.
🚧 Pre-1.0: the npm publish is imminent — until it lands, use the from-source setup; everything works today.
Ask "what beats my trick room team?" and get back OHKO/2HKO lines computed
with @smogon/calc against the top meta Pokémon at their actual most common
spreads — not vibes. Defaults to the current official format (Pokémon
Champions, Regulation Set M-B); SV Regulation I and other formats are one
format parameter away.
claude mcp add bringfour -- npx -y bringfour{
"mcpServers": {
"bringfour": {
"command": "npx",
"args": ["-y", "bringfour"]
}
}
}git clone <this repo> && cd <repo> && npm installThe repo ships a project-scoped .mcp.json, so Claude Code picks the server
up automatically when working in this directory. For other clients, run
npx tsx src/index.ts (stdio transport).
Related MCP server: Poke-MCP
Tool | What it does |
| Top meta Pokemon with usage/win rates for a format. |
| One Pokemon's common items, abilities, moves, spreads, natures, Tera types (SV), teammates. |
| Calc-backed threat report: for the top N meta Pokemon at their most common sets, real OHKO/2HKO threats against your actual EVs, plus speed tiers and speed-control flags (Tailwind/Trick Room/Icy Wind...). |
| Damage calc via |
| Store Showdown-export pastes as plain text, so "analyze my worlds team" works without re-pasting. |
npm run ui # http://localhost:4747A local dashboard (dark, sprite-heavy, no build step) over the same data layer as the MCP tools:
Threats — pick a saved team, get the calc-backed threat report as cards with OHKO/2HKO badges, damage bars, a speed ladder, and speed-control flags.
Damage Calc — attacker/defender panels that pre-fill the most common meta set (grayed-italic until you override a field), live results, field conditions, swap sides.
Teams — create/edit Showdown pastes, or import from a pokepast.es link.
Meta / deep-dive — sortable usage table; click through to per-Pokemon items, moves, spreads, natures, and teammates.
Running from a checkout (or any directory containing a teams/ folder) keeps
teams in ./teams/ and the 24h usage-data cache in ./.cache/, as always.
Running via npx/global install falls back to ~/.bringfour/. Override with:
Env var | Effect |
| Base directory for both ( |
| Teams directory only |
| Cache directory only |
Pikalytics (pikalytics.com) is the primary usage source — in-game ranked battle data for Champions, HOME battle data for SV. Pikalytics asks for attribution when citing its stats; every tool response carries it.
Smogon usage stats (smogon.com/stats, Showdown ladder chaos JSON) are the automatic fallback when Pikalytics lacks a format.
Usage dumps are monthly; the service walks back up to 7 months to find the newest published data, and caches responses for 24h.
Teams are plain Showdown-export text files — edit them freely.
Champions EVs run 0–32 per stat. For damage/stat math they are mapped onto
the classic 0–252 scale (×8, capped); every calc that does this says so in
its assumptions. Treat very close rolls with caution.
Champions Mega formes ("Charizard-Mega-Y") mostly exist in @smogon/calc's
data already; anything the calc doesn't know is reported explicitly instead
of guessed at.
v2: EV-spread optimization; tournament results/team lists via the documented Limitless API.
Hosted copilot: a web app where a frontier model writes full team coaching reports over these tools — in design, gated on this repo proving demand. Star the repo if you want it to exist.
If this saves you a ladder session of scouting, a star is the best signal you can send.
MIT — see LICENSE.
Unofficial fan tool — not affiliated with, endorsed, or supported by Nintendo, Creatures Inc., GAME FREAK, or The Pokémon Company. Pokémon and all respective names are trademarks of their owners. Usage data courtesy of Pikalytics (attribution requested) and Smogon usage stats; damage math by @smogon/calc (MIT); sprites served from Pokémon Showdown's public sprite sets.
Calc-backed threat report for your team vs the top meta: real OHKO/2HKO threats at common spreads, speed tiers, and speed-control flags. Provide team_paste (Showdown export) or team_name (a saved team).
| Name | Required | Description | Default |
|---|---|---|---|
| top_n | No | How many top meta Pokemon to check (default 30) | |
| format | No | VGC format. Default: current Champions Reg M-B. Known ids: champions-reg-mb, sv-reg-i; other Pikalytics/Smogon format ids pass through as-is. | |
| team_name | No | ||
| team_paste | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool is calc-backed and specifies the kind of analysis it produces (OHKO/2HKO threats, speed tiers, speed-control flags). It doesn't cover edge cases like what happens if no input is provided, but the core behavior is transparent.
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, front-loaded with the tool's purpose and followed by input instructions. Every word earns its place; no fluff or repetition of schema details.
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 description covers the main purpose, inputs, and output highlights. With no output schema, it tells the user what kind of report to expect. It omits details like default behavior when no input is given or exact report structure, but it is sufficient for a moderately complex 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 coverage is only 50%, so the description must compensate. It does: team_paste is defined as a Showdown export and team_name as a saved team, and implies one or the other should be used. This adds meaning beyond the bare schema entries for these parameters.
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 produces a calc-backed threat report for a team against the top meta, listing OHKO/2HKO threats, speed tiers, and speed-control flags. This specific output distinguishes it from sibling tools like calc_damage (raw calcs) and meta_snapshot (meta overview).
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 clear context: use it to get a team-specific threat report versus the current top meta. It also tells the user to provide either a team_paste or team_name. However, it doesn't explicitly mention alternatives or when not to use this tool versus siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
VGC damage calc via @smogon/calc. Unspecified items/abilities/natures/EVs auto-fill from meta data and every assumption is echoed back — override any field and re-call to refine.
| Name | Required | Description | Default |
|---|---|---|---|
| move | Yes | ||
| format | No | VGC format. Default: current Champions Reg M-B. Known ids: champions-reg-mb, sv-reg-i; other Pikalytics/Smogon format ids pass through as-is. | |
| reflect | No | ||
| terrain | No | e.g. Electric, Grassy, Psychic, Misty | |
| weather | No | e.g. Sun, Rain, Sand, Snow | |
| attacker | Yes | ||
| defender | Yes | ||
| aurora_veil | No | ||
| helping_hand | No | ||
| light_screen | No | ||
| single_target | No | Skip the doubles spread reduction |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden and discloses a key behavioral trait: every assumption is echoed back, and unspecified fields auto-fill. This goes beyond the schema by explaining the tool's default-filling behavior and iterative refinement, making it more transparent than a simple 'calculates damage' statement.
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, front-loaded with the purpose, and every clause adds value. It avoids fluff and is appropriately sized for 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 no output schema and a complex 11-parameter tool, the description does not explain the return format or what the damage output looks like. It also does not mention that attacker, defender, and move are required, leaving a noticeable gap for a tool that needs those core inputs.
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 low (36%), so the description's statement that unspecified items/abilities/natures/EVs auto-fill adds semantic meaning to those optional fields. However, it does not explain the format of values for move, nature, ability, etc., leaving some parameters under-described.
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 opens with 'VGC damage calc via @smogon/calc', which clearly identifies the tool as a damage calculator for VGC using a specific library. This distinguishes it from sibling tools like analyze_team or meta_snapshot, 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 provides operational guidance: unspecified items/abilities/natures/EVs auto-fill from meta data, and users can override fields and re-call to refine. This clearly tells when and how to use the tool, though it does not explicitly mention alternatives or exclusions, which are evident from the distinct sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List saved teams and their Pokemon.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It implies a read operation ('List') and adds that Pokemon are included, but does not disclose any potential behaviors such as ordering, filtering, or whether it returns all saved teams. For a simple list operation, this is minimally adequate, but lacks explicit behavioral context.
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, efficient sentence that front-loads the primary action ('List saved teams'). Every word is useful, with no fluff or redundancy.
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?
This is a simple tool with no parameters, no output schema, and no annotations. The description adequately conveys the core function, but could add small context like 'all saved teams' or 'read-only' to be fully complete. Still, for its complexity, it is largely sufficient.
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 zero parameters, so the baseline is 4. The description adds no parameter details, but none are needed. The mention of 'their Pokemon' gives some output context, though not directly about parameters.
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 'List saved teams and their Pokemon' clearly states the verb ('List'), the resource ('saved teams'), and the scope (including Pokemon). It distinguishes itself from sibling tools like save_team (saving) and analyze_team (analyzing), 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 clearly implies this tool is used to view saved teams, and the sibling tool names provide context for alternatives. However, it does not explicitly state when not to use it or mention any alternative tools by name, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Top Pokemon in the current VGC metagame with usage/win rates. Pikalytics primary, Smogon usage stats fallback, cached ~24h.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many Pokemon to return (default 30) | |
| format | No | VGC format. Default: current Champions Reg M-B. Known ids: champions-reg-mb, sv-reg-i; other Pikalytics/Smogon format ids pass through as-is. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses important behavioral traits: it uses Pikalytics primarily, falls back to Smogon usage stats, and caches data for ~24 hours. This adds transparency beyond a simple 'list top Pokemon' statement.
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, well-structured sentence that front-loads the main purpose and includes relevant details (sources, fallback, caching) without any unnecessary words or repetition.
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 has two optional parameters and no output schema, but the description sufficiently covers what is returned (top Pokemon with usage/win rates) and provides contextual details about data sources and caching. Although it doesn't explicitly describe the response structure, the simplicity of the tool makes this 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 coverage is 100%: both parameters (limit and format) have clear descriptions in the schema. The tool description adds no extra parameter-specific semantics, so the 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 the tool's function: it returns top Pokemon in the current VGC metagame with usage/win rates. The verb and resource are specific, and the mention of usage/win rates distinguishes it from sibling tools like pokemon_deep_dive or analyze_team.
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 clear context: it is for retrieving current VGC meta data, with details about data sources and caching. While it doesn't explicitly name alternative tools or exclusions, the context makes it obvious when this tool would be appropriate (e.g., quick meta overview).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Common items, abilities, moves, spreads/natures, Tera types (SV), and teammates for one Pokemon in a VGC format.
| Name | Required | Description | Default |
|---|---|---|---|
| format | No | VGC format. Default: current Champions Reg M-B. Known ids: champions-reg-mb, sv-reg-i; other Pikalytics/Smogon format ids pass through as-is. | |
| pokemon | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It usefully lists the data categories returned, which helps set expectations, but it does not mention data source, return format, error handling, or limitations for uncommon Pokemon or formats.
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, compact sentence that front-loads all key data categories. Every phrase contributes meaning 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?
The tool has no output schema, so the description should explain what the return contains; it does list the main categories. However, it omits important context like how the data is sourced, what happens for missing data, and how the default format is determined, leaving some ambiguity for a 'deep-dive' 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 only 50%: the required 'pokemon' parameter has no schema description, and the description only says 'for one Pokemon,' offering minimal help. The 'format' parameter's semantics are fully covered by the schema, but the description adds no value for it, leaving the pokemon parameter weakly explained.
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 enumerates what the tool returns: common items, abilities, moves, spreads/natures, Tera types, and teammates for a single Pokemon in a VGC format. This is specific about the resource and scope, though it lacks an explicit verb like 'retrieves' and does not reference sibling tools.
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 about when to use this tool versus alternatives such as meta_snapshot, analyze_team, or calc_damage. The phrase 'for one Pokemon' implies a single-Pokemon analysis use case, but there are no explicit exclusions or references to sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a Showdown-export team paste under a name (stored as plain text in teams/).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| team_paste | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that teams are stored as plain text in teams/, which is useful. However, it does not specify whether saving over an existing name overwrites or errors, nor does it mention any validation or response behavior. This is a partial disclosure.
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, front-loaded sentence. It communicates the action, object, key parameter roles, and storage detail with zero redundancy, making it both concise and well-structured.
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?
Although the tool is simple, it is a mutation with no annotations or output schema. The description omits critical behavior like whether an existing team with the same name is overwritten, and it does not explain what the tool returns (if anything). These gaps are significant for an agent to invoke it safely, so the description is incomplete.
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 0% schema coverage, the description effectively maps both parameters: 'name' is the label to save under, and 'team_paste' is the Showdown-export paste. It adds the important format context ('Showdown-export') and storage location, going beyond raw schema property names.
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 action ('Save'), the object ('Showdown-export team paste'), and the context ('under a name', stored in teams/). It is distinct from sibling tools like analyze_team or list_teams, which focus on analysis or listing, making this the only save operation.
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 intended use is clear: save a team for later retrieval. While no alternatives or exclusions are mentioned, the sibling tool names make it obvious that this tool is for persisting teams, not analyzing or listing them. This provides clear context without requiring explicit when-not guidance.
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: one for meta overview, one for single-pokemon details, one for team analysis, one for damage calculation, and two for team persistence. No overlapping or ambiguous roles.
Most tools follow a verb_noun pattern (analyze_team, calc_damage, save_team, list_teams), but meta_snapshot and pokemon_deep_dive are noun phrases. All names are snake_case and readable, so the inconsistency is minor.
With six tools, the server is well-scoped for a VGC Pokemon assistant. Each tool covers a distinct workflow without unnecessary bloat or missing essentials.
The server covers the core VGC workflow: meta information, pokemon deep dives, team threat analysis, damage calculation, and team storage. A minor gap is lack of delete/update team operations, but these are not critical for the primary use case.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that integrates with Discord to provide AI-powered features.
MCP server for building and testing AI agents with multi-model experimentation and insights.
Driflyte MCP server which lets AI assistants query topic-specific knowledge from web and GitHub.
Official MCP server for Agentwork — delegate tasks to AI agents with human-in-the-loop
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/LuciPengu/bringfour'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
