Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

futgg_fc27_price_index

Retrieve the published FC27 card-price index with native delta-coded EA item identifiers and sparse price/token metadata, preserving zero or absent values. Not a historical price series.

Instructions

Get FC27 published card-price index. Returns native delta-coded EA item identifiers and sparse price/token metadata, preserving source wire fields and zero/absent values. The index is not a historical-price series.

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": "futgg_fc27_price_index"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

A3.5/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, and it does disclose payload traits: delta-coded EA item identifiers, sparse price/token metadata, preserved source wire fields, and preserved zero/absent values. That is meaningful behavioral context, but 'delta-coded' is never explained, so an agent cannot tell whether it must reconstruct values or pass them through, and nothing is said about size, caching, or rate limits.

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 with the identification front-loaded and the negative scoping clause placed last where it functions as a routing caveat. The wording is jargon-dense ('native delta-coded EA item identifiers', 'source wire fields') but no sentence is filler.

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 zero-arg fetch with no output schema, the description must stand in for the return contract, and it partially does by describing sparseness and preserved zero values. It falls short on the two things a caller most needs: what 'delta-coded' means operationally and how the returned identifiers relate to futgg_fc27_players or futgg_fc27_catalog.

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 there is nothing for the description to disambiguate and the baseline of 4 applies. The description correctly avoids inventing filter options that do not exist in the empty schema.

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 gives a specific verb and resource ('Get FC27 published card-price index'), so the agent knows this fetches a price index dataset rather than a filtered query. It implicitly separates itself from the historical-series siblings via 'The index is not a historical-price series,' but it never names futgg_fc27_prices or any price_history tool, so the boundary is only partly drawn.

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 one exclusionary statement ('not a historical-price series') is genuinely useful routing signal and hints the caller should prefer a history tool when they want trends. However, there is no positive guidance on when this index is the right choice versus futgg_fc27_prices, and no prerequisites or context conditions are given.

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