Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

faceit_hub

Fetch a FACEIT hub’s full details by ID, including game, region, organizer, player counts, skill band, join rules, prizes, and queue settings; unknown IDs return 404.

Instructions

FACEIT hub detail by id. Returns one FACEIT hub: identity, description, game/region/category, organizer, publication and featured flags, slot and player counts, skill band, join permissions, rules id, images, geo/region/game checks, nested child hubs, role identities, FACEIT points, prize counts and queue/application/chat settings. An unknown id answers 404.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

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

Input Schema

NameRequiredDescriptionDefault
idYesHub UUID from faceit-hub-memberships.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations supplied, the description carries the full burden and does a solid job: it declares the cardinality (returns exactly one hub), lists the substantive fields returned, and discloses the failure behavior ("An unknown id answers 404"). It omits authentication requirements, rate limiting, and whether soft-deleted or private hubs are visible to the caller, which keeps it out of 5 territory.

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?

Two sentences, purpose front-loaded, then the field inventory, with the error case last. The field enumeration is long but earns its place because there is no output schema to document the return shape; only minor redundancy from listing overlapping concepts like "geo/region/game checks" and "region".

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 one-parameter read tool with no output schema and no annotations, the definition covers what an agent needs: what comes back, how much comes back, and what happens on a bad id. The remaining gap is operational context such as auth or rate limits, which is defensible for a read-only detail endpoint 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?

Schema description coverage is 100% and the single id parameter is documented in-schema as a "Hub UUID from faceit-hub-memberships", so the schema already does the work. The description only restates that lookup is by id and adds no format, validation, or edge-case semantics (e.g. case sensitivity or whether slug ids are accepted), so the baseline 3 applies.

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?

"FACEIT hub detail by id" names a specific resource (a single hub) and a specific lookup key, and the following sentence enumerates exactly what the returned hub contains, so the agent knows this is a single-object fetch rather than a listing. It stops short of a 5 because the neighbouring names faceit_hubs and faceit_hubs_detailed are not addressed, so the boundary between "hub detail" and those tools must be inferred.

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: "by id" plus the schema note that the id comes from faceit-hub-memberships tells the agent a known hub UUID is a precondition, and the 404 note signals what a bad id does. There is no explicit statement of when to prefer this over faceit_hubs or faceit_hubs_detailed, and no guidance on bulk or search scenarios.

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