Skip to main content
Glama
Sign In

Sightkick

by so.sightkick
OverviewDiscussionsAdmin

Get tracked prompts

get_prompts
Read-only

The buyer prompts Sightkick tracks in AI answers, and their answers. view:

  • list: Every tracked prompt with its visibility, sentiment, position, brands named and gap verdict.

  • prompt(promptId): One prompt in depth: its sources and its runs per AI model (each runId opens an answer).

  • answer(runId): One stored answer in full: its text, cited sources, brands found.

  • suggestions(keyword?, limit?): Questions buyers ask that nobody tracks yet, from People Also Ask and the site's own searches. A keyword opens its Google results page for more, free (as check_web serp).

  • rechecks: Questions booked to be asked again (ask_ai recheck): the answer then and, once asked again, now.

  • models: Every AI model, which are tracked, and the plan's count.

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": {
      "view": "<view>"
    },
    "name": "get_prompts"
  }
}

Input Schema

NameRequiredDescriptionDefault
viewYes
limitNo
runIdNo
keywordNo
promptIdNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already establish readOnlyHint=true and destructiveHint=false, so the safety profile is covered. Beyond that, the description adds real behavioral context with no output schema present: it describes what each view returns, signals a cost distinction ('free (as check_web serp)'), and notes the plan's model count. It does not explain pagination or whether limit applies outside suggestions.

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?

The structure is strong: a one-line framing sentence followed by a bulleted view map, so an agent can scan directly to the mode it needs. Some phrasing is dense and slightly ungrammatical ('and their answers', 'its sources and its runs'), and a few parenthetical references need domain knowledge, but almost every line carries information.

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 six-mode dispatcher with a 5-parameter schema, no output schema, and 0% schema coverage, the description is largely self-sufficient: it explains each view's payload and the optional keyword/serp behavior. The notable remaining hole is limit semantics for the list-style views, which an agent would have to guess at.

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 0%, so the description carries the parameter burden. It does well on view (all six values explained) and decently on keyword and the ID parameters via the view signatures, but limit is only mentioned inside 'suggestions(keyword?, limit?)', leaving its role and the 1-50 bound unexplained, and runId/promptId formats are never described.

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

Purpose4/5

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

The opening sentence names the resource (buyer prompts tracked in AI answers) and the description then enumerates six distinct modes with the data each returns, so an agent can tell what the tool does. It is not fully differentiated from siblings like get_visibility or get_keywords in the top-line sentence, but the per-view breakdown compensates.

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

Usage Guidelines3/5

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

Usage guidance is implicit: each view line implies the situation that selects it (e.g. 'answer(runId)' when you have a runId, 'suggestions' for untracked buyer questions). It also cross-references siblings ('as check_web serp', 'ask_ai recheck'), but never states when NOT to use this tool or how to choose between it and get_visibility/get_keywords.

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

All Sightkick toolsInspect
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