Skip to main content
Glama
Sign In

Rempa

by ai.rempa
OverviewDiscussionsAdmin

Update a recommendation

update_recommendation
Idempotent

Set the status of one of the project's recommendations, as on the app's Recommendations page: "doing" when the work starts, "done" once it is applied (the next updates show whether the AI answers changed), "dismissed" when it does not apply, "todo" to reopen it. To mark a "source" or "content" recommendation done, give published_url: the page that now mentions the brand, or the page published (ask the user for it, never guess it); Rempa opens it to check it, then looks for it in the AI answers of the next updates. set_aside_days hides an open recommendation for 14 or 30 days (it comes back by itself), 0 brings it back now; give it instead of a status, or with one. The only tool that writes: it changes the status, the page published and the set-aside date, nothing else; it can be undone and repeating it is harmless. Returns the recommendation's id, title, status, page published and set-aside date. Paid plans only; an OAuth connection needs the permission to update.

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>",
      "recommendation_id": "<recommendation_id>"
    },
    "name": "update_recommendation"
  }
}

Input Schema

NameRequiredDescriptionDefault
statusNoThe new status: todo, doing, done or dismissed.
projectYesThe project: its id or its address (for example "acme-france"), as returned by list_projects.
published_urlNoWith status "done": the full address (https://…) of the page that now mentions the brand (source) or of the page published (content). Required for those two types.
set_aside_daysNoHide the recommendation for 14 or 30 days; 0 brings it back now.
recommendation_idYesThe recommendation's id, from get_recommendations.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / published_url
      Added value: +{
+  "description": "With status \"done\": the full address (https://…) of the page that now mentions the brand (source) or of the page published (content). Required for those two types.",
+  "type": "string"
+}
    • addedInput schema / properties / set_aside_days
      Added value: +{
+  "anyOf": [
+    {
+      "const": 0,
+      "type": "number"
+    },
+    {
+      "const": 14,
+      "type": "number"
+    },
+    {
+      "const": 30,
+      "type": "number"
+    }
+  ],
+  "description": "Hide the recommendation for 14 or 30 days; 0 brings it back now."
+}
    • changedInput schema / required
      Previous value: -[
-  "project",
-  "recommendation_id",
-  "status"
-]New value: +[
+  "project",
+  "recommendation_id"
+]
  2. Changed2 schema fields 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."
    • changedInput schema / properties / status / description
      Previous value: -"The new status."New value: +"The new status: todo, doing, done or dismissed."
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations, the description bounds the write scope precisely ("changes the status, the page published and the set-aside date, nothing else") and discloses access constraints the annotations cannot express: paid plans only and an OAuth connection with update permission. It also explains what happens downstream (next updates reveal whether AI answers changed) and lists the returned fields despite there being no output schema.

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-loaded with the core operation and overall efficient, but the single dense paragraph mixes status semantics, URL rules, set-aside behavior, side effects, and prerequisites with interleaved parentheticals ("the next updates show whether the AI answers changed"), which makes it a slower read than a short bulleted structure would be.

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?

For a 5-parameter mutation tool with no output schema, the description covers everything needed to call it correctly: per-status meaning, conditional parameter requirements, mutual exclusivity of set_aside_days and status, auth and plan gating, reversibility, and the returned fields. Nothing material is left to inference.

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; the description earns one more by adding semantics the schema lacks, notably that published_url is required for "source" and "content" recommendations specifically and must be obtained from the user, and that set_aside_days is an alternative to a status rather than an addition. It does not add format detail beyond what the schema already documents.

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?

"Set the status of one of the project's recommendations" names a specific verb and resource, and the addition "The only tool that writes" cleanly separates it from the many read siblings (get_recommendation, get_recommendations, list_updates). The description also enumerates the secondary effects (published_url, set_aside_days) so the agent knows the tool's full surface, not just status.

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?

Each status value is given a when-to-use condition ("doing" when work starts, "done" once applied, "dismissed" when it does not apply, "todo" to reopen), and the published_url requirement is scoped to "source"/"content" types with an explicit instruction to ask the user rather than guess. The set-aside vs status relationship is spelled out ("give it instead of a status, or with one"), and prerequisites (paid plan, OAuth update permission) are stated.

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