Skip to main content
Glama
Sign In

Rempa

by ai.rempa
OverviewDiscussionsAdmin

Get the recommendations

get_recommendations
Read-only

Get the project's action plan to be named more often by AI assistants, built from its latest update and ranked by the monthly searches at stake: websites to get listed on (cited when competitors are named and the brand is not), pages to publish (questions the brand loses), and fixes to its website (AI crawlers blocked in robots.txt, llms.txt, structured data). Each item has an id, status (todo, doing, done, dismissed), summary, steps, impact, effort and evidence; the page published once done (and whether Rempa found it online and naming the brand); the date it is set aside until; and its workspace: the outreach message, content brief (outline, questions, competitors, sources to cite, the brand's pages that should link to it) and draft written in the app, the draft as a title and length (get_recommendation has its text). Use it for "what should we do?"; record progress with update_recommendation. Read-only. Paid plans only: on a free plan it returns an error.

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_recommendations"
  }
}

Input Schema

NameRequiredDescriptionDefault
projectYesThe project: its id or its address (for example "acme-france"), as returned by list_projects.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • 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."
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already cover readOnlyHint and openWorldHint, but the description adds real behavior: results are ranked by monthly searches at stake, items carry a status lifecycle (todo, doing, done, dismissed) and a set-aside date, and completed pages are checked to see whether Rempa found them online naming the brand. The paid-plan error behavior is disclosed. "Read-only" merely restates the annotation, and nothing is said about result volume or limits.

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?

Purpose and usage are correctly front-loaded, but the bulk is one sprawling sentence stitched together with parentheticals and semicolons, which makes the field inventory hard to scan. The content largely earns its place given there is no output schema, but the structure could be far tighter.

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?

With no output schema, the description must carry the return-value burden, and it does: item fields, status values, the workspace artifacts (outreach message, content brief components, draft title/length), and the pointer to get_recommendation for full text. Combined with the paid-plan gate and the update sibling, an agent has everything needed to call and interpret it.

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% and the single `project` parameter is already documented as an id or address as returned by list_projects. The description adds no syntax, format, or edge-case meaning beyond that, so the baseline of 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 names a specific verb and resource ("Get the project's action plan") and immediately scopes it to three concrete recommendation categories: sites to get listed on, pages to publish, and website fixes such as robots.txt/llms.txt/structured data. It also distinguishes itself from the singular sibling by noting "get_recommendation has its text" and routes writes to update_recommendation.

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 states the triggering question explicitly ("Use it for 'what should we do?'") and names the alternative for the write path ("record progress with update_recommendation"). It also gives a hard gating condition — paid plans only, error on free plan — which prevents a whole class of misinvocation.

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