Refora

Prompt performance

get_prompt_performance

Read-onlyIdempotent

Detailed performance for one prompt (one question Refora asks the AI models on a schedule): visibility over time, per-model visibility and answers, and the URLs cited in its answers.

Use this tool when the user asks about a specific prompt -- phrases like 'how are we doing on the prompt about X', 'details on this prompt', or as drill-down after seeing prompts from get_competitor_visibility_gap.

Name the prompt by its text: the full text as another Refora tool returned it, or a distinctive part of it. Prompts with the same text are one question and are measured together. If several prompts match, the response lists them so the user can pick.

Example: 'How are we doing on the prompt about enterprise CRM?'

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": {
      "workspace_id": "<workspace_id>",
      "prompt_text": "<prompt_text>"
    },
    "name": "get_prompt_performance"
  }
}

Input Schema

Name	Required	Description
`days`	No	How many days back to look, counted back from end_date (default today). Default 30, max 90. Ignored when start_date is given. Prompts are re-run on a schedule, so a window shorter than a week can be empty.
`end_date`	No	Optional end of the window, as an ISO date (YYYY-MM-DD). Default today. Cannot be in the future.
`start_date`	No	Optional explicit start of the window, as an ISO date (YYYY-MM-DD). A full ISO datetime is accepted and its date is used. Overrides days.
`prompt_text`	Yes	The prompt's text, exactly as another Refora tool returned it, or a distinctive part of it. Matched case-insensitively.
`workspace_id`	Yes	The workspace's numeric id, as returned by list_workspaces.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 15, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds genuinely non-obvious behavior: prompts sharing the same text are treated as one question and measured together, and multiple matches return a list for the user to pick from. It does not discuss pagination or result size limits, 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?

Front-loaded with the core purpose, then usage triggers, then the naming rule, then a single concrete example. Each paragraph carries distinct information with no restatement of the schema or annotations.

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?

With no output schema, the description carries the burden of describing returns, and it does so at a useful level of abstraction (visibility over time, per-model visibility and answers, cited URLs). The ambiguity-handling behavior is also disclosed. Minor gap: no indication of response shape or size for the multi-match case.

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

Parameters4/5

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 prompt_text accepts either the exact text or a distinctive fragment and that matching is on prompt identity rather than a prompt id. It says nothing about days/start_date/end_date interplay, but the schema already documents that fully, including the override rule and the empty-window caveat.

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?

States a specific verb and resource ('Detailed performance for one prompt') and immediately defines the domain object ('one question Refora asks the AI models on a schedule'), then enumerates the returned dimensions: visibility over time, per-model visibility and answers, and cited URLs. An agent can distinguish this from siblings like get_visibility_trend or get_ai_answers 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.

Usage Guidelines5/5

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

Gives explicit when-to-use triggers with example user phrasings ('how are we doing on the prompt about X', 'details on this prompt') and names a concrete entry path as a drill-down after get_competitor_visibility_gap. It also explains how to identify the prompt and what happens on ambiguity, which is the main failure mode for this tool.

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

All Refora 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?