Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

mlb_prospect_rankings

Fetch MLB Pipeline prospect rankings—Top 100, team, position, draft, or international—with search, sort, team filters, and pagination to build ranked player lists.

Instructions

Get MLB Pipeline curated prospect rankings. Returns MLB Pipeline's curated Top 100, Top 30 by Team, Top 10 by Position, Draft Top 200, or International Top 50 ranking. The anonymous first-party page embeds full ranked data. Search, sort, team filtering on Top 100, and pagination are applied to the extracted rows. Use mlb_discovery for the exact view, year, team, position, and sort values.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
qNoCase-insensitive player-name substring
sortNoLocal sort field
viewNoRanking view
yearNoRanking year
limitNoRows per page (1-250)
offsetNoZero-based row offset
positionNoRequired for view=position
sort_dirNoLocal sort direction
team_slugNoRequired for view=team; one of the MLB Pipeline team ranking slugs. See mlb_discovery.
team_filterNoOptional organization filter for view=top100; use a team slug from mlb_discovery.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.9

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 disclose meaningful behavior: the data comes from an anonymous first-party page that 'embeds full ranked data,' and search, sort, team filtering, and pagination are applied to extracted rows (local post-processing). It does not mention auth needs, rate limits, or default behavior when view is omitted, but the core retrieval/filter semantics are transparent.

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?

Front-loads purpose and the returned views, then adds behavioral and parameter-routing notes in separate sentences. It is dense but every sentence carries information; minor tightening is possible but nothing is wasted.

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 10-parameter, no-annotation, no-output-schema tool, the description covers the views returned, the extraction/filtering behavior, and how to obtain valid enum values. It leaves defaults (e.g., behavior with no view) and any return-shape detail implicit, but the core calling information is present.

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 real semantics beyond the schema by explaining that sort/search/team filtering/pagination are post-processing on extracted rows and that team filtering applies only to the Top 100 view. It reinforces the view-conditional requirements (position for view=position, team_slug for view=team) rather than merely restating enums.

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 ('Get MLB Pipeline curated prospect rankings') and then enumerates the five distinct ranking views returned (Top 100, Top 30 by Team, Top 10 by Position, Draft Top 200, International Top 50). It also separates itself from the sibling mlb_discovery, so an agent can route correctly without opening a 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?

Explicitly tells the agent to 'Use mlb_discovery for the exact view, year, team, position, and sort values,' which is a concrete companion-tool instruction for obtaining valid enum values. It stops short of stating when-not to use this tool versus ranking alternatives like mlb_prospect_stats, so it is clear context rather than full when/when-not guidance.

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