vex-mcp-server

Server Quality Checklist

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

Latest release: v2.0.1
Disambiguation5/5
Each tool targets a distinct resource and action, from team and event searches to forum post retrieval and match analysis. No two tools have overlapping purposes, and even the closely related awards tools are clearly separated by team vs. event context.
Naming Consistency5/5
All tool names follow a consistent snake_case verb_noun pattern (e.g., search-teams, get-team-info, list-forum-categories, analyze-match-opponents). The pattern is predictable and easy to navigate.
Tool Count5/5
With 15 tools, this server sits at the upper boundary of the ideal range but each tool covers a distinct need within VEX scouting and forum browsing. The count feels well-scoped for the breadth of data exposed.
Completeness5/5
The tool surface covers the full lifecycle for VEX data consumption: team search/details/awards/rankings/skills, event search/details/awards, and forum search/topic/post/user/category access. The added match-opponent analysis fills a key scouting gap, leaving no obvious dead ends.
Average 3.5/5 across 15 of 15 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on September 11, 2025
- 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

Behavior2/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 only says 'Get detailed information' but does not disclose what fields are returned, whether both parameters can be used together, what happens if neither is provided (both are optional), or any potential errors. This is a significant gap for a data-retrieval tool.
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, concise sentence that is front-loaded with the main action. There is zero wasted language, and it effectively communicates the core purpose. For a simple tool, this length is appropriate.
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?
With no output schema and no annotations, the description should clarify what 'detailed information' entails and confirm the behavior when both or neither parameters are supplied. It fails to do so. The tool has only two optional parameters, but the ambiguity around required inputs and return format makes the description incomplete.
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 input schema already provides a 100% description coverage for the two parameters, with clear descriptions ('RobotEvents team ID' and 'Team number (e.g., '229V')'). The description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.
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 states a clear verb and resource: 'Get detailed information about a specific VEX team'. It is specific to retrieving details for a known team, distinguishing it from siblings like search-teams which are for finding teams. However, it does not explicitly differentiate itself from other team-related tools (e.g., get-team-awards), nor does it list what 'detailed information' includes, so it is not a full 5.
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, exclusions, or contrasts with sibling tools like search-teams. The only implied usage is that you must know either a team ID or team number, but this is not explicitly stated as a condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 only states that the tool 'searches' and lists criteria, but does not explain pagination, result ordering, how filters combine, or what the response contains, leaving the agent with minimal insight into the tool's actual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that is easy to parse and sufficiently concise. The one content flaw is the misleading 'program' example, but the overall structure is efficient and unwasteful.
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?
With 7 parameters, no output schema, and no annotations, the description should clarify what the search returns and how criteria interact. It only says 'search for events' without stating that a list is returned, whether filters are combined with AND, or whether results are paginated, leaving significant gaps for an agent to operate correctly.
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% and each parameter already has a detailed description, so the baseline is 3. The tool description adds a high-level summary of criteria but mildly misrepresents the schema by mentioning 'program', which is not a real parameter, offering no additional semantic value beyond the schema's existing detail.
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 uses the specific verb 'Search' and identifies the resource as 'VEX robotics events', clearly distinguishing it from sibling tools like search-teams and get-event-details. However, it lists 'program' as a criterion while the schema has no 'program' property, introducing slight ambiguity about the exact filterable fields.
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 implies the tool is used for finding events but gives no explicit guidance on when to use it over alternatives like get-event-details. It does not mention exclusions, prerequisites, or a preferred search-then-detail workflow, so the agent receives no clear usage context beyond the basic purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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. While the description implies a read-only listing, it does not disclose specifics like ordering by date, whether it returns full topic content or summaries, or any rate limits or authentication requirements. The behavior is under-specified beyond the basic purpose.
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, clear sentence with no redundant or filler content. It efficiently conveys the core function and the optional filter in a minimal footprint.
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?
For a simple listing tool with fully documented parameters, the description covers the essential purpose. However, without annotations or an output schema, it lacks usage context, ordering semantics, and a clear distinction from sibling search tools, making it minimally sufficient but not comprehensive.
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%, so each parameter is already described. The description adds 'optionally filtered by category' which aligns with category_id and category_slug, but does not provide additional meaning beyond the schema's per-parameter descriptions.
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 states the verb 'Get' and the resource 'latest topics from the VEX Forum', with an optional category filter. It distinguishes itself from sibling tools like search-forum by specifying 'latest topics', implying a feed rather than a search, but it does not explicitly compare to alternatives.
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 on when to use this tool versus search-forum, get-forum-topic, or list-forum-categories. The description simply states what it does without indicating appropriate contexts or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of disclosure. It states what is returned (topic details and posts/replies) but does not mention default behavior for max_posts, include_raw semantics, pagination, error handling, or the structure of the response. For a read tool, this is a moderate gap.
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 that states the core function clearly without unnecessary words. Every word earns its place, and it is appropriately concise.
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?
With no output schema and no annotations, the description is expected to explain what the tool returns. It does mention 'topic details and posts/replies' but omits details about defaults, ordering, or potential limits. For a relatively simple read tool, this is adequate but leaves some gaps.
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 description coverage is 100% — all three parameters have clear descriptions in the schema. The tool description adds no additional parameter context beyond noting that posts/replies are included. Baseline 3 is appropriate since the schema already documents parameters fully.
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 uses a specific verb ('Get'), names the resource ('VEX Forum topic by ID'), and specifies the scope ('including the topic details and posts/replies'). This clearly distinguishes it from siblings like get-forum-post (which gets a single post) and search-forum (which searches).
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 given on when to use this tool versus alternatives. It does not mention exclusions or provide context about when this is preferred over get-forum-post or search-forum. The intended usage is only implied by the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only mentions output contents (award titles, events, seasons) but omits any caveats, prerequisites, or behaviors like how team selection works or how missing teams are handled.
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 concise sentences with no wasted words, front-loaded with the primary action and followed by relevant output details.
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?
The tool has four parameters with no required fields, but the description doesn't clarify that a team must be identified via team_id or team_number, nor does it mention the optional event/season filters. No output schema exists, so the description only partially covers return values.
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%, so parameters are fully described in the schema. The description adds no additional meaning beyond what the schema already provides, though it hints at response content.
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?
Description clearly states the tool retrieves all awards for a specific VEX team, with a scope of competitive history. It distinguishes from sibling tools like get-event-awards by focusing on team instead of event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The phrase 'throughout their competitive history' implies a general use case, but no exclusions or alternative tool references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It only states the search capability and omits behavioral details like result ordering, pagination, registration status filtering, or client-side filtering for team_name and organization.
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?
A single, front-loaded sentence efficiently communicates the tool's purpose with an illustrative list of criteria, with no wasted words.
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?
With 8 optional parameters, no output schema, and no annotations, the description is too sparse. It doesn't explain default behavior with no filters, how criteria combine, or the response format, making it inadequate for complex selection decisions.
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 description coverage is 100%, so baseline 3 applies. The description reiterates some criteria but adds no additional meaning beyond a summary of the searchable fields.
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 uses the specific verb 'Search' with the resource 'VEX teams' and lists key criteria (team number, event, country, program, grade), making it clear what the tool does and distinguishing it from sibling search-events.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies use for finding teams by criteria but provides no explicit guidance on when to use it versus get-team-info for a specific team or search-events. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It only states the action and does not describe what 'profile information' includes, the return format, error handling for unknown usernames, or any authentication requirements. Minimal behavioral transparency.
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, concise sentence (11 words) that is front-loaded with the verb and resource. Every word is necessary, and there is no wasted or redundant text.
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 is simple (one parameter) and the description covers the basic purpose, but with no output schema and no annotations, it leaves gaps such as the structure of the returned profile and possible error responses. Adequate for a low-complexity tool, but not fully complete.
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 already fully documents the single parameter 'username' with a clear description, and schema coverage is 100%. The description's phrase 'by username' adds no additional meaning beyond the schema, 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 an unambiguous action: 'Get a VEX Forum user's profile information by username.' It specifies the resource (VEX Forum user profile), the method (by username), and is distinct from sibling tools like search-forum or get-forum-topic, which handle content rather than user profiles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the tool's unique purpose among siblings (no other tool retrieves user profiles), but there is no explicit guidance on when to use this tool versus alternatives, nor any mention of prerequisites or edge cases. The description relies on the user inferring when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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. The description implies a read operation ('Get') but does not explicitly state it is read-only. It also uses 'either...or' language that may misrepresent the schema's allowance for both event_id and team_id simultaneously, and does not disclose behavior when no parameters are supplied.
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 sentence that front-loads the core purpose and efficiently communicates the two modes. Every word earns its place, and there is no redundancy.
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?
With 4 optional parameters, no output schema, and no annotations, the description is insufficient. It fails to clarify behavior when no parameters are provided, whether event_id and team_id can be combined, or how type and season filters interact. The either/or phrasing further obscures the full parameter space.
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 description coverage is 100%, so the baseline is 3. The description does not add meaning beyond the schema's individual parameter descriptions; it merely restates the two main parameters. No new semantic detail is provided for type or season.
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 uses a specific verb ('Get') and resource ('skills scores for VEX teams'), and clearly distinguishes the two modes of operation (specific event or team history). This differentiates it from sibling tools like get-team-rankings or get-team-awards.
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 explicitly states the two primary use cases: retrieving scores for a specific event or for a team's skills history. This gives clear context for when to use the tool, though it does not mention exclusions or alternative tools by name.
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 alone carries the transparency burden. It discloses the type of data returned (team winners, individual winners, award details), but does not mention pagination, authentication, or any limitations. This is adequate for a simple read operation but lacks depth.
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 concise sentence, front-loaded with the action and resource. It is free of redundancy and gets directly to the point.
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 a low-complexity GET operation with a clear description and complete schema, but no output schema or annotations. The description adequately summarizes return content, though it does not address edge cases like empty results or pagination, leaving minor gaps.
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 description coverage is 100%, so the baseline is 3. The description does not add meaningful parameter details beyond the schema; it merely restates the event context. No extra value is provided for the optional team and winner filters.
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 retrieves awards information for a specific VEX event, using the verb 'Get' with a specific resource and scope. It distinguishes from siblings like get-team-awards by emphasizing event-level awards rather than team-level awards.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving event awards, but it does not explicitly mention when to use this tool over alternatives like get-team-awards or get-event-details. No exclusions or contextual conditions are provided, leaving the agent to infer applicability.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states the input methods (event ID or SKU) but does not disclose what 'detailed information' includes, whether both parameters are required despite schema showing 0 required, or any response format/error behavior. This is insufficient for a tool with no output schema.
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 with no unnecessary words. It states the verb, resource, and input method efficiently.
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?
For a simple get tool with two parameters, the description is adequate but incomplete. Since there is no output schema, it does not specify what 'detailed information' contains, leaving ambiguity about whether it includes rankings, awards, or other event data. The lack of annotations increases the need for more contextual disclosure.
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 schema already describes both parameters with examples, but the description adds the key semantic relationship that sku and event_id are alternative identifiers ('by event ID or SKU code'). This clarifies how to use the parameters together, which is not explicit in the schema.
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: retrieving detailed event information by ID or SKU code. It distinguishes itself from sibling tools like search-events and get-event-awards by focusing on direct retrieval of event details for a known identifier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have an event ID or SKU code, but it does not explicitly state when not to use this tool or mention alternatives like search-events for finding events by criteria. The guidance is implicit rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 states the action but does not disclose error behavior, response format, or read-only guarantees. There is no contradiction, but the transparency is minimal.
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 with no superfluous words. Every word earns its place.
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?
For a tool with one well-documented parameter and no output schema, the description is mostly complete. It covers what the tool does but omits details about return value structure or error cases, which are not critical for such a straightforward operation.
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 provides 100% coverage of the single parameter (post_id) with a clear description. The tool description adds no additional semantic meaning beyond 'by its ID', so a 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 uses the verb 'Get' with a specific resource ('a single VEX Forum post') and the method ('by its ID'). This clearly distinguishes it from sibling tools like search-forum or get-forum-topic, which have 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 implies usage when a specific post ID is available, but it does not explicitly state when not to use it or mention alternatives. The context is clear enough for a simple getter, but no exclusions or comparative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of disclosing behavioral traits. It only restates schema-visible capabilities (filtering, sorting) and does not add context about read-only nature, return format, pagination, or any special constraints. The lack of added value beyond the schema results in a low score.
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 primary purpose, and briefly notes supported filters. Every word earns its place; there is no redundancy or fluff.
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?
For a search tool with no output schema, the description adequately explains the tool's role and capabilities. It mentions topics and posts, and the schema covers parameter details. Minor missing context like default sorting or pagination behavior is not critical but prevents a perfect score.
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 description coverage is 100%, so the schema fully documents all seven parameters. The description only summarizes the filter categories (category, user, date, sorting) without adding additional meaning or format details. This aligns with the baseline of 3 for high schema coverage.
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 searches the VEX Forum for topics and posts. The verb 'search' and resource 'VEX Forum' are specific, and it is distinguished from sibling tools like search-teams and search-events by explicitly naming the forum.
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 a forum search tool with filtering and sorting capabilities. While it does not explicitly mention alternatives or when-not-to-use, the scope is unambiguous enough for an agent to select it for forum searching.
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 provided, the description must disclose behavior itself. It states the tool 'Shows each team's recent award history,' implying a read-only analysis. However, it does not detail the output format, any potential side effects, or limitations (e.g., data size for 'all matches'). This is moderate but not rich behavioral 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 concise and well-structured: three short sentences that state the core function, the value-add (award history), and the intended use case. Every sentence adds meaningful information without redundancy, making it easy to scan.
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 description explains the purpose and use case but lacks details about the return value or output structure. Since there is no output schema, the description does not compensate for that gap. It also doesn't explicitly note that both team and event identifiers are needed, though the schema hints at this. The description is adequate but incomplete for a tool of moderate complexity.
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 input schema provides complete descriptions for all four parameters, covering their types and conditional requirements. The tool description does not add extra meaning beyond the schema—it doesn't clarify the relationship between team and event parameters or provide additional constraints. Given the 100% schema coverage, a baseline 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: 'Analyze teammates and opponents for all matches of a team at an event.' It names the specific resource (matches for a team/event) and differentiates from siblings by combining match analysis with 'recent award history' for competitive context. The verb 'Analyze' is somewhat broad, but the resource and scope are well-defined.
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 a clear use case: 'Useful for pre-competition scouting and match preparation.' This gives context for when to use the tool. However, it does not explicitly mention alternatives or when not to use it, 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. 'List' implies a read-only operation, but it does not disclose response format, pagination, authentication needs, or any other side effects. It is minimally transparent but lacks depth.
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 one short sentence that immediately conveys the purpose. There is no obsolete or redundant information, and it is appropriately front-loaded.
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 simplicity (0 params, no output schema), the description is adequate but not rich. It does not explain what a 'category' is, what fields are returned, or any limitations. It is a minimal viable description but leaves room for more context.
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 tool has no parameters, and schema coverage is 100% (vacuously). With 0 parameters, the baseline is 4 per the rubric. No additional parameter explanation is needed.
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 (list) and the resource (categories on the VEX Forum), with scope ('all'). This distinct tool from siblings like 'search-forum' or 'get-forum-topic'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving available categories, but does not explicitly mention when to use it versus other forum tools or any prerequisites. No alternatives or exclusions are given, so it relies on the agent's inference.
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 provided, the description itself must convey behavioral safety. 'Get' implies a read-only operation, which is a basic behavioral trait. However, it does not disclose what happens if neither team_id nor event_id is supplied, whether season filters apply across both modes, or the shape of the response. For a simple retrieval tool this is adequate but lacks completeness.
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 that immediately states the tool's purpose and primary modes. Every word earns its place; there is no fluff or repetition of schema information.
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?
The tool has no output schema, no annotations, and all parameters optional, so the description must carry substantial contextual weight. It explains two modes but leaves critical ambiguity: what if no parameters are provided? Are team_id and event_id mutually exclusive? How does season interact with the other filters? These gaps make the description incomplete for safe, correct invocation.
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 schema already describes all three parameters at 100% coverage, so the baseline is 3. The description adds meaningful semantics by explaining that event_id retrieves rankings for all teams at an event and team_id retrieves historical rankings. However, the season parameter is not mentioned in the description, so the added value is partial.
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: 'Get ranking information for VEX teams' and immediately specifies the two primary modes: 'for a specific event or a team's historical rankings.' This verb-resource pair is specific and distinguishes it from sibling tools like get-team-info or get-skills-scores.
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 guidance on when to use each mode ('for a specific event' vs 'a team's historical rankings') and implicitly differentiates from alternative ranking or score tools. However, it does not explicitly state exclusions or mention the season filter as a third usage context, so it falls short of full guidance.
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:

[![vex-mcp-server MCP server](https://glama.ai/mcp/servers/yangjack8192/vex-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/yangjack8192/vex-mcp-server)

Score Badge

Copy to your README.md:

[![vex-mcp-server MCP server](https://glama.ai/mcp/servers/yangjack8192/vex-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/yangjack8192/vex-mcp-server)

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/yangjack8192/vex-mcp-server'

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