Skip to main content
Glama
Sign In
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

vlr_match_economy

Retrieve Valorant match economy data from VLR.gg by match ID, including pistol and bonus-round records, buy-level win rates, round banks, loadout values, and round winners per map and match.

Instructions

VLR.gg Valorant match economy. Returns the Economy tab of one VLR.gg match for every map and for the whole match: each team's pistol rounds, pistol conversion and bonus-round records, win records by buy level (eco under 10k, half 10k to 18k, full 18k and over) against each opponent buy level, and round by round banks, loadout values, buy levels, the winner and the winning side. available is false while VLR has not published the tab, which is normal for a match that just ended.

Input Schema

NameRequiredDescriptionDefault
idYesNumeric VLR match id from vlr-matches, vlr-results or vlr-event-matches

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.18

TDQS

A3.9/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does disclose a genuinely non-obvious behavior: `available` is false until VLR publishes the tab, which is normal for a just-finished match. That staleness signal prevents an agent from misinterpreting an empty result. It doesn't cover error modes, auth, or whether the call is a plain read, which keeps it below a 5.

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?

One dense, front-loaded paragraph that leads with the resource and then enumerates returns; the inline buy-level thresholds (`eco` under 10k, `half` 10k–18k, `full` 18k+) earn their space because they define otherwise ambiguous labels. It is a long sentence chain, but no clause is filler.

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?

No output schema exists, so the description must describe the return surface, and it does so thoroughly — per-map and aggregate scope, each statistical block, and the `available` flag. Only the absence of any hint on error/empty handling beyond `available` keeps it from a 5.

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?

There is a single parameter at 100% schema description coverage; the schema already explains that `id` is a numeric VLR match id sourced from vlr-matches, vlr-results or vlr-event-matches. The description adds no further detail about the id format or validation, so this is the baseline case where the schema does the work.

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?

States a specific verb and resource: it returns the Economy tab of one VLR.gg match, broken out per map and for the whole match. The enumeration of contents (pistol rounds, bonus records, buy-level win records, per-round banks) makes it clearly distinct from siblings like vlr_match_rounds or vlr_match_performance.

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 makes the use case implicit (analyzing team economy/buy-level performance in a match) and the schema points at where to obtain the id. However, it never states when to choose this over adjacent tools such as vlr_match_rounds, which also carries round-by-round data, nor any prerequisites or exclusions.

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

Deploy Server

Other Tools