bringfour

by LuciPengu

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 4/5 across 6 of 6 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
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 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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![bringfour MCP server](https://glama.ai/mcp/servers/LuciPengu/bringfour/badges/card.svg)](https://glama.ai/mcp/servers/LuciPengu/bringfour)

Score Badge

Copy to your README.md:

[![bringfour MCP server](https://glama.ai/mcp/servers/LuciPengu/bringfour/badges/score.svg)](https://glama.ai/mcp/servers/LuciPengu/bringfour)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/LuciPengu/bringfour'

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