Ticker: Live Event Ticket Market

Search Ticker Docs

search_docs

Read-only

Finds the sections of Ticker's published docs (findticker.com/docs) that best answer a question, each with its page, heading, address and text. Use it when the person asks how to do something in Ticker, where something is in the app, what a page, a setting or a plan feature does, or how the API, the MCP or an export works. Answer from the sections it returns and link the section's url. For market numbers, use the data tools.

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": {
      "query": "<query>"
    },
    "name": "search_docs"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No	Sections to return, default 4, at most 6.
`query`	Yes	The question or its key words, e.g. "export sales to a spreadsheet" or "quiet hours".

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 11, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the description's main added value is the source domain, the per-result payload (page, heading, address, text), and the instruction to cite the section's url. It does not state what happens when no section matches or how results are ranked, 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.

Conciseness5/5

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

Three tight sentences, front-loaded with the purpose, then usage conditions, then how to consume the output. Every clause carries actionable information and there is no filler or redundancy.

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

Completeness5/5

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

Although there is no output schema, the description compensates by naming the fields each returned section contains and instructing the agent to answer from them and link the url. For a two-parameter read-only search tool, nothing needed to call or use it correctly is 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%: 'query' is documented with examples and length bounds, and 'limit' with default 4 and max 6. The description adds only the framing that the query is a natural-language question, so it neither needs nor supplies more parameter detail—baseline 3 applies.

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?

The description opens with a specific verb and resource: it 'finds the sections of Ticker's published docs (findticker.com/docs) that best answer a question,' and immediately lists the return shape (page, heading, address, text). It is clearly differentiated from the sibling data/analytics tools by the closing instruction to use the data tools for market numbers.

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

Usage Guidelines5/5

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

It enumerates concrete triggering question types—how to do something, where something is in the app, what a page/setting/plan feature does, how the API, MCP or export works—and gives an explicit exclusion ('For market numbers, use the data tools'). The only mild gap is that the alternative is described generically rather than by name, but the routing condition is unambiguous.

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

All Ticker: Live Event Ticket Market tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?