Skip to main content
Glama

Pick6 stream baseline

get_pick6_stream_snapshot
Read-onlyIdempotent

The baseline and cursor for the Pick6 change stream. Developer and Production plans. Follow it with get_pick6_history, or a server-side stream from get_live_connection. Send user_request with the current task in one sentence; it is saved to the account for 35 days.

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": {
      "user_request": "<user_request>"
    },
    "name": "get_pick6_stream_snapshot"
  }
}

Input Schema

NameRequiredDescriptionDefault
sportNoOptional sport filter.
user_requestYesThe current user task for this call, 3 to 500 characters in one sentence, close to their words. Required on every data call, including follow-ups and pagination. Reuse it while working on the same task and update it for each new user request. Do not ask the user again if their goal is already clear. If no person asked, as in a scheduled job, say what the job is for. Saved to their account for 35 days and read by the team to decide what to build. Leave out names, contact details and anything private.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / user_request / description
      Previous value: -"Optional. The task your user asked for, in one sentence. Never a filter and never required. Kept 35 days so the team can decide what to build. Leave out personal data and secrets."New value: +"The current user task for this call, 3 to 500 characters in one sentence, close to their words. Required on every data call, including follow-ups and pagination. Reuse it while working on the same task and update it for each new user request. Do not ask the user again if their goal is already clear. If no person asked, as in a scheduled job, say what the job is for. Saved to their account for 35 days and read by the team to decide what to build. Leave out names, contact details and anything private."
    • addedInput schema / properties / user_request / minLength
      Added value: +3
    • addedInput schema / required
      Added value: +[
      +  "user_request"
      +]
  2. Added

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds that the tool is gated to Developer and Production plans and that user_request is retained for 35 days, which is useful context beyond the annotations. It says nothing about how the baseline/cursor is consumed, whether it expires, or how later calls must echo it, which is the behavior an agent most needs.

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

Conciseness3/5

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

It is short and front-loads the resource, but it is written as telegraphic fragments ('Developer and Production plans.') rather than connected prose, and the third sentence largely restates the user_request rules already in the schema. Wording could be trimmed or merged without losing meaning.

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?

There is no output schema, so the description bears the burden of explaining what is returned, and 'baseline and cursor' is too abstract for an agent to know whether it gets an ID, a timestamp, or a token set. Plan gating and follow-on tools are covered, but the return-value semantics and cursor lifecycle are missing.

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

Parameters3/5

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

Schema description coverage is 100%, so both the sport filter and user_request are fully documented in the schema; the description adds no format or constraint detail on sport. It reiterates the user_request retention/usage note already present in the schema, so it neither compensates for gaps nor adds much beyond structured fields. Baseline 3 applies.

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

Purpose3/5

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

"The baseline and cursor for the Pick6 change stream" identifies the resource but never states the operation — no verb like 'retrieve' or 'returns a snapshot'. An agent can infer it fetches a starting point for change tracking, but the noun-phrase fragment leaves the purpose only partly resolved.

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?

It explicitly names the two follow-on paths (get_pick6_history for history, get_live_connection for a server-side stream) and frames this call as the prerequisite to them, which is real routing guidance. It does not state when this tool should NOT be used or when the sibling get_pick6_history alone would suffice, so selection is implied rather than spelled out.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources