get_history_summaryThe authenticated user's imported betting-history ledger: W-L record, stake and net over lifetime/30d/7d windows, sync freshness, and their most recent bets. Numbers come only from the user's own imported slips; nothing is fabricated.
| Name | Required | Description | Default |
|---|---|---|---|
| recent | No | How many recent bets to include (default 5). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable context by stating the data comes exclusively from the user's own imported slips and that nothing is fabricated, which sets expectations about data provenance and reliability. It also mentions sync freshness, hinting at potential staleness. This exceeds the annotation baseline.
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?
The description is a single, grammatically clear sentence that front-loads the core purpose and lists the key return elements without redundancy. Every clause contributes to understanding, and there is no filler or unnecessary elaboration.
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 carries the responsibility of explaining the return payload. It covers the main components (W-L, stake, net, time windows, freshness, recent bets) sufficiently for a read-only tool. Minor gaps exist (e.g., how sync freshness is reported), but given the tool's simplicity, it is nearly complete.
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 schema provides 100% coverage for the single 'recent' parameter, including its limits and default. The description indirectly references 'recent bets' but does not elaborate on the parameter's semantics beyond the schema. Since the schema already handles it well, the baseline of 3 is appropriate; the description adds no extra meaning.
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 uses a specific verb 'get' with a clear resource: the user's imported betting-history ledger. It enumerates specific outputs (W-L record, stake, net over time windows, sync freshness, recent bets) and inherently distinguishes from siblings like get_saved_reports or get_todays_board, which are for different data. This is a model of purpose clarity.
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?
The description implies usage by stating it returns the user's own betting history summary, but it does not explicitly state when to use this tool versus alternatives. No exclusions or alternatives are named, relying on the agent to infer that this is the dedicated history summary tool. A clear 'use when you need a summary of the user's betting history; for saved reports use get_saved_reports' would improve it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct resource or action: history summary, saved reports, live board, tracked slips, grade, price shop, and track. Even the two slip-analysis tools, grade_slip and price_shop_slip, are clearly separated by their outputs and purpose.
All tools use snake_case with a clear verb_noun structure: get_* for read operations and verb_slip for actions like grade, price_shop, and track. The pattern is predictable and easy for an agent to reason about.
Seven tools is well-scoped for the domain: reading history, reports, the board, and tracked slips, plus three actionable tools for grading, price shopping, and tracking. Each tool earns its place without redundancy.
Core workflows are covered: grade a slip, shop prices, save/fetch reports, read history, and create/revise tracking. Minor gaps exist around lifecycle management, such as deleting saved reports or untracking slips, but they are not blocking for the primary use case.