Publishes the builder's reply to a review (moderated).
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Builder reply (5-1000 characters). ONE time only. | |
| reviewId | Yes | Id of the review (from my_reviews). |
| Name | Required | Description | Default |
|---|---|---|---|
| ok | Yes | Always true: the reply has been saved. | |
| inModeration | Yes | Always true: the reply goes through moderation before it can be seen. |
Changes observed during successful MCP inspections.
Input schema / allOfRemoved value: -[
- {
- "anyOf": [
- {
- "required": [
- "reviewId"
- ]
- },
- {
- "required": [
- "resenaId"
- ]
- }
- ]
- },
- {
- "anyOf": [
- {
- "required": [
- "text"
- ]
- },
- {
- "required": [
- "texto"
- ]
- }
- ]
- }
-]Input schema / properties / resenaIdRemoved value: -{
- "deprecated": true,
- "description": "DEPRECATED alias of `reviewId`: it still works, but use `reviewId` (it will be removed in a future round, no date yet). Id of the review (from my_reviews).",
- "type": "string"
-}Input schema / properties / textoRemoved value: -{
- "deprecated": true,
- "description": "DEPRECATED alias of `text`: it still works, but use `text` (it will be removed in a future round, no date yet). Builder reply (5-1000 characters). ONE time only.",
- "type": "string"
-}Input schema / requiredAdded value: +[
+ "reviewId",
+ "text"
+]Input schema / x-bernuvia-aliasesRemoved value: -{
- "reviewId": "resenaId",
- "text": "texto"
-}Input schema / properties / resenaId / descriptionPrevious value: -"ALIAS RETIRADO de `reviewId`: sigue funcionando, pero usa `reviewId` (se quitará en una tanda futura, aún sin fecha). / DEPRECATED alias of `reviewId`. Id de la reseña (de my_reviews)."New value: +"DEPRECATED alias of `reviewId`: it still works, but use `reviewId` (it will be removed in a future round, no date yet). Id of the review (from my_reviews)."Input schema / properties / reviewId / descriptionPrevious value: -"Id de la reseña (de my_reviews)."New value: +"Id of the review (from my_reviews)."Input schema / properties / text / descriptionPrevious value: -"Respuesta del builder (5-1000 caracteres). UNA sola vez."New value: +"Builder reply (5-1000 characters). ONE time only."Input schema / properties / texto / descriptionPrevious value: -"ALIAS RETIRADO de `text`: sigue funcionando, pero usa `text` (se quitará en una tanda futura, aún sin fecha). / DEPRECATED alias of `text`. Respuesta del builder (5-1000 caracteres). UNA sola vez."New value: +"DEPRECATED alias of `text`: it still works, but use `text` (it will be removed in a future round, no date yet). Builder reply (5-1000 characters). ONE time only."Output schema / properties / inModeration / descriptionPrevious value: -"Siempre true: la respuesta pasa por moderación antes de verse."New value: +"Always true: the reply goes through moderation before it can be seen."Output schema / properties / ok / descriptionPrevious value: -"Siempre true: la respuesta se ha guardado."New value: +"Always true: the reply has been saved."Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses the meaningful trait that replies are moderated, and the schema adds the one-time-only constraint, but nothing is said about auth requirements, what happens after moderation, or whether the reply is publicly visible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with zero wasted words; the verb and object come immediately. It is efficient, though arguably terse for a moderated publish action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be explained, and the schema fully covers both params. However, for a mutation tool with no annotations and no usage guidance, the description leaves the moderation workflow and post-publish behavior unexplained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: both params are documented with length limits, one-time constraint, and where reviewId originates. The description adds no parameter 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.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ("Publishes") and resource ("the builder's reply to a review"), so the operation is unambiguous. It does not explicitly distinguish itself from the sibling reply_to_case, but the resource differs clearly enough that an agent can route correctly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use guidance, no prerequisites, and names no alternatives. The only hint of context ("from my_reviews") lives in the schema's reviewId field, not in the description itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.