Skip to main content
Glama
Sign In
Crawlora MCP

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

futgg_fc27_sbc_set_by_ea

Retrieve FC27 SBC set and challenge metadata using the native EA set ID (eaId), returning public reward details without solver execution.

Instructions

Read FC27 SBC set by EA set ID. Uses the native EA set identity from listing eaId, not the set database id or an EA challenge ID. Returns the same public set/challenge/reward metadata as the slug resource. No account, biography or solver execution.

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

Input Schema

NameRequiredDescriptionDefault
idYesPositive EA set ID from set eaId

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.20

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does a fair job: it declares the operation is a read, describes the returned metadata class (public set/challenge/reward metadata, same as the slug resource), and explicitly excludes account, biography and solver execution. It omits error behavior for an invalid or non-existent eaId and any caching or rate-limit notes.

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?

Four short sentences, front-loaded with the action and identifier constraint; little waste. The final fragment ("No account, biography or solver execution.") is telegraphic, but it still conveys scope exclusions efficiently.

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 single-parameter read tool with no output schema and no annotations, the description covers identifier semantics, what is returned, and what is out of scope. Only the failure mode for bad ids is unaddressed, which is a minor gap given the tool's simplicity.

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?

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema by naming the identifier namespace: the value must come from the listing's eaId and is not a set database id or challenge id. That disambiguation prevents a common wrong-parameter call.

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 ("Read FC27 SBC set") and pins the key to the "EA set ID". It then explicitly distinguishes itself from the siblings that take other identifiers (set database id, EA challenge ID), so an agent can pick it without opening another schema.

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?

The clause "Uses the native EA set identity from listing eaId, not the set database id or an EA challenge ID" tells the agent exactly which situation selects this tool and which situations do not, effectively routing to the by-challenge and by-slug variants. It stops short of naming those sibling tools directly or stating what to do when no eaId is available.

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