Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

faceit_banlist_stats

Retrieve aggregate FACEIT ban counters for the past 12 months and 30 days to monitor ban activity trends without per-reason or per-game breakdowns.

Instructions

FACEIT ban list aggregate counters. Returns the aggregate FACEIT ban counters: bans in the last 12 months and bans in the last 30 days. The upstream publishes no per-reason or per-game breakdown on this anonymous surface.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "faceit_banlist_stats"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

A3.6/5.0
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 usefully discloses that this is an anonymous surface with no per-reason or per-game breakdown, which sets expectations. It does not mention rate limits, caching, or anything about ordering beyond the two counters.

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?

Three short sentences, front-loaded with the tool's identity and return values. The phrase 'aggregate counters' / 'aggregate FACEIT ban counters' is slightly redundant but not costly.

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 no-parameter, no-output-schema read tool, the description covers what comes back and the granularity limit. A note on the response envelope shape would be the only remaining gap, and that is minor here.

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 takes zero parameters, so the baseline is 4. The description correctly contains no parameter discussion and instead spends its words on output expectations.

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?

Names a specific resource (FACEIT ban list aggregate counters) and states the two returned metrics (bans last 12 months, bans last 30 days). The note about no per-reason or per-game breakdown separates it from faceit_ban_reasons, though it does not name siblings directly.

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 only implied: an agent can infer this is for aggregate ban counts rather than individual ban entries. There is no explicit 'use faceit_banlist for individual bans' or 'use faceit_ban_reasons for reason breakdown' routing statement.

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