球云体育 Sports Data

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

Annotations already establish this is a read-only, non-open-world call, so the safety profile is covered. The description adds real behavioral context beyond that: halftime matches are included in the result set, scores and minutes are live, and the cross-midnight coverage gap versus get_matches_by_date is disclosed. It does not discuss rate limits or result ordering/volume caps, which keeps it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, each with a distinct job: what is returned, when to invoke it, and a subtle coverage caveat. No filler or repetition of the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no parameters, no output schema, and minimal annotations, the description still tells the agent what the return contains (matches, live score, minute) and where the tool's scope ends. There is no material gap an agent would need to resolve before calling it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so there is nothing to document and the baseline is 4. The description correctly implies the call is unfiltered and global, consistent with an empty schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb and resource: it returns all matches currently in play (including halftime), with live scores and elapsed minutes. It also implicitly distinguishes itself from the date-based sibling by framing the resource as '此刻正在进行' rather than a calendar day.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit trigger phrasing ('现在有什么比赛在踢', '实时比分') and an explicit exclusion case: matches that span midnight, common for European leagues at China time, will NOT appear in get_matches_by_date and must come from this tool. That is a concrete when-to-use/when-not-to-use rule naming the alternative.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context by disclosing the returned structure (score/status/venue/round plus a chronological event timeline), which tells the agent what kind of data to expect without an output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads what is returned, then the usage triggers, then the parameter sourcing in three tight sentences with no filler. Slightly dense but every clause carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by enumerating the returned fields and event types, and it closes the parameter-provenance loop via sibling tools. Only minor gaps remain (no mention of pagination or error behavior for invalid ids), which is acceptable for a read-only single-record lookup.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema itself documents the id format and an example, so the baseline is 3. The description goes further by telling the agent where to obtain matchId (get_matches_by_date or get_live_matches), adding chaining guidance the schema does not provide.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific resource (单场比赛) and enumerates the payload precisely: 比分、状态、场地、轮次, plus a minute-by-minute event timeline (进球、红黄牌、换人、VAR). This clearly distinguishes it from the sibling list tools get_matches_by_date and get_live_matches.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete user-intent triggers ('谁进的球', '第几分钟进的', '详细过程') that tell the agent when this tool is the right call, and points to get_matches_by_date / get_live_matches as the source of matchId. It stops short of stating exclusions (e.g., bulk/date-range queries should go elsewhere), so it is clear context but not 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.

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely useful behavioral context beyond that: the omitted-date default (today, UTC+8) and the queryable window (365 days back to 7 days forward), which an agent cannot infer from structured fields. It does not describe result volume or pagination, so it falls short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with what the tool returns before the usage triggers and the alternative. No filler, and the redirect to the sibling is placed last where it does not interrupt the primary description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-optional-param read tool with no output schema, the definition covers purpose, defaults, limits, and the sibling alternative. The only gap is what the returned payload looks like (fields, ordering, size), which the absence of an output schema leaves slightly under-specified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single param is fully documented with format and example, so the baseline would be 3. The description adds the default-on-omission behavior and the valid date range, which the schema does not express, giving it real added value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (查询赛程与比分), the coverage (足球、篮球、网球、棒球等全部联赛与杯赛), and the date granularity. It also explicitly contrasts itself with get_live_matches, so an agent can distinguish it from siblings 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete trigger phrasings (「今天有什么比赛」「昨天的赛果」「周末的赛程」) and names the alternative with the condition that selects it: use get_live_matches if only currently-playing matches are wanted. Both when-to-use and when-not-to-use are covered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: the supported competition set (hot leagues only, e.g. EPL, La Liga, UCL, CSL) and the fact that unsupported competitions return an error rather than empty data — a failure mode an agent must anticipate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, front-loaded with the return payload then the usage triggers then coverage limits; each sentence earns its place. Minor redundancy in re-listing league names that the schema already enumerates.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by enumerating the returned fields, and it also covers competition coverage and the error case. For a single-parameter read-only tool with its safety profile already in annotations, nothing material is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single 'league' parameter already documents id examples and points to /llms-full.txt for the full list. The description repeats the hot-league names but adds no syntax, format, or alias guidance beyond the schema, so this is the baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (returns the full standings table for a given league) and enumerates exactly what each row contains: rank, played, W/D/L, goals for/against, goal difference, points, last-five form. This clearly separates it from siblings like get_match_detail and get_live_matches, which are about individual matches rather than league tables.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete trigger phrasing for the agent ("英超积分榜", "西甲第几名", "谁是榜首"), which is strong implied usage guidance, and states coverage limits plus the error behavior for unsupported competitions. It stops short of naming an alternative tool or an explicit when-not-to-use condition, so it falls just below the top.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description usefully adds behavioral context the annotations lack: this is an aggregate read returning several distinct blocks of data (rank, form, past and future matches), which tells the agent to expect a compound response rather than a single record.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences with zero padding: the returned payload is front-loaded, then trigger examples, then ID sourcing. Every clause carries actionable information for the agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a single fully documented parameter and no output schema, the description carries the burden of describing return contents, which it does explicitly. Nothing an agent needs to select or invoke this tool is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, and the description goes beyond it by explaining that teamId is numeric and shares the same identifier space as the /team/{teamId} web page, plus naming two concrete sibling tools (get_matches_by_date home.id/away.id, get_standings teamId) from which it can be obtained. That provenance guidance is not in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource (return a single team's profile) and enumerates the exact contents: league ranking, season record, last-5 form, most recent finished match, and upcoming fixtures. This is clearly separable from siblings like get_standings and get_matches_by_date, which provide only one slice of that data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives concrete trigger phrasings ("how is Arsenal doing", "who does Man City play next", "where does team X rank") and routes the agent to the sibling tools that supply a valid teamId. It never states when NOT to use it or how it differs from get_standings for pure ranking lookups, so it is clear but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: which fields a hit can match, the default time-descending ordering, and the fixed five-value category taxonomy — something the schema does not expose. It stops short of describing result volume or paging, hence 4 rather than 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded in the first clause, followed by triggers, default behavior, and the category enum — four clauses, each carrying distinct information with no filler or restatement of the tool name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

One optional string parameter, no output schema, no nested objects, read-only. Matching fields, default ordering, default (empty-query) behavior, and the category domain are all covered, so an agent has everything needed to call it and interpret results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3 and the schema already documents query. The description still contributes the default semantics (omit → all reports, sorted by publish time descending) and the closed category vocabulary, which the schema lacks entirely. This is a modest but genuine addition over the structured fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource (检索站内报道) and immediately enumerates the searched fields (标题、摘要、正文、标签、分类), so the agent knows exactly what corpus is hit. The sibling set is all match/standings/team lookups, so the news-search scope is unmistakably distinct.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete trigger phrasings (「有没有关于某队的报道」「最新的转会新闻」) and an explicit second mode: omitting query returns everything time-descending for open-ended asks like「最近有什么新闻」. Both when-to-use and the alternative invocation shape are spelled out.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.