Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

fotmob_lineup_builder_players

Fetch public metadata for 1 to 11 FotMob lineup players by numeric IDs, so you can validate and build lineups; unknown or incomplete IDs return 404.

Instructions

FotMob lineup builder player metadata. Returns public metadata for 1 to 11 selected lineup players. Player ids are open-ended and can be discovered through /fotmob/search or /fotmob/lineup-builder-team. Unknown ids without complete public metadata return 404.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
player_idsYesComma-separated list of 1 to 11 numeric FotMob player ids

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.6

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 behavioral burden. It usefully discloses the 1-11 id limit and the 404 outcome for unknown ids lacking complete metadata, but says nothing about auth needs, rate limits, or payload shape. Solid partial disclosure but clearly incomplete for an unannotated read tool.

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 tight sentences: purpose first, then id sourcing, then the error condition. No filler, and the most decision-relevant information (what it returns and where ids come from) is front-loaded.

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 annotations and no output schema, the description covers purpose, input sourcing, and the failure mode, which is enough to call it correctly. The absence of any return-shape hint is the only notable gap.

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 the single parameter is fully documented as a comma-separated list of 1-11 numeric ids. The description's 'open-ended' note adds minor context about id discoverability but does not extend parameter meaning beyond the schema, 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?

States a specific verb and resource: returns public metadata for selected lineup-builder players. The 'lineup builder' framing and the reference to /fotmob/lineup-builder-team help an agent distinguish this from the plain fotmob_player sibling, though the differentiation is implicit rather than explicit.

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?

Names concrete alternatives for obtaining ids (/fotmob/search and /fotmob/lineup-builder-team), which tells the agent where input comes from. It does not state when to prefer this over fotmob_player or what scenario calls for the lineup-builder variant, so it stops short of full when-to-use coverage.

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