Skip to main content
Glama
Sign In

Rempa

by ai.rempa
OverviewDiscussionsAdmin

Get the perception

get_perception
Read-only

Get how the AI answers of one update perceive the brand and its competitors: per brand, the average sentiment (0 to 100, 50 neutral), the number of positive, neutral and negative answers, and the share of voice (plain, and weighted by position: a mention weighs 1 when named first, 1/2 when second…); plus, for one brand, a summary of its strengths, weaknesses and the words used about it. Use it for "what do AI assistants say about us?". Read-only. The summary is written by AI from the answers the first time it is asked for an update, then kept; requests with a summary are limited to 60 per hour per account, beyond which it comes back as unavailable.

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": {
      "project": "<project>"
    },
    "name": "get_perception"
  }
}

Input Schema

NameRequiredDescriptionDefault
brandNoThe brand to sum up: the project's brand or a brand named in the update. Default: the project's brand.
modelNoAn AI model id from get_project (ai_models[].id, for example "chatgpt" or "gemini"), to keep only that model's answers. Default: all models.
topicNoA topic name or id from get_project (topics), to keep only that topic's prompts. Default: all topics.
updateNoAn update (run) id from list_updates, to read an earlier update. Default: the latest update.
projectYesThe project: its id or its address (for example "acme-france"), as returned by list_projects.
summaryNoInclude the AI summary of the brand. Default true; false returns only the numbers, faster.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • changedInput schema / properties / brand / description
      Previous value: -"The brand to sum up. Default: your brand. Leave the summary out with summary: false."New value: +"The brand to sum up: the project's brand or a brand named in the update. Default: the project's brand."
    • changedInput schema / properties / model / description
      Previous value: -"An AI model id (for example \"chatgpt\", \"gemini\") to keep only its answers. See get_project."New value: +"An AI model id from get_project (ai_models[].id, for example \"chatgpt\" or \"gemini\"), to keep only that model's answers. Default: all models."
    • changedInput schema / properties / project / description
      Previous value: -"The project: its id, or its address (for example \"acme-france\"). See list_projects."New value: +"The project: its id or its address (for example \"acme-france\"), as returned by list_projects."
    • changedInput schema / properties / summary / description
      Previous value: -"Include the AI summary of the brand. Default true."New value: +"Include the AI summary of the brand. Default true; false returns only the numbers, faster."
    • changedInput schema / properties / topic / description
      Previous value: -"A topic name or id to keep only its prompts. See get_project."New value: +"A topic name or id from get_project (topics), to keep only that topic's prompts. Default: all topics."
    • changedInput schema / properties / update / description
      Previous value: -"An update (run) id from list_updates. Default: the latest update."New value: +"An update (run) id from list_updates, to read an earlier update. Default: the latest update."
  2. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Goes well beyond the readOnly/openWorld annotations: discloses that the summary is AI-generated on first request and then cached, that summary requests are capped at 60/hour per account and degrade to 'unavailable' past that, and that summary=false is faster. These are exactly the cost/throttle traits an agent needs before calling.

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?

Front-loads the core purpose and returned metrics, and the rate-limit caveat lands at the end. The long semicolon-chained sentence is dense but every clause (weighting rule, caching, limit) carries real 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?

With no output schema, the description carries return-value burden and does well, naming each metric and the summary contents. Minor gaps: no mention of response shape/nesting or how sentiment aggregation handles missing models, but nothing essential is missing for correct invocation.

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 already 100%, but the description still adds value: it explains the share-of-voice weighting rule (1 for first mention, 1/2 for second…) and the speed tradeoff of summary=false. The brand and summary parameters gain meaning beyond their schema text.

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?

States a specific verb and resource ('Get how the AI answers of one update perceive the brand and its competitors') and enumerates the returned metrics (sentiment, answer counts, share of voice). It is clearly distinguishable from get_answer (single answer) and get_demand/get_sources by its sentiment/aggregation scope, though it never names a sibling explicitly.

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?

Gives a concrete use-case framing ('what do AI assistants say about us?') that tells the agent when to reach for it. It offers no explicit exclusions or pointer to an alternative when the agent wants raw answers rather than perception, so it falls short of full routing guidance.

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

All Rempa 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