Frihet MCP Server

Update Quote

update_quote

Idempotent

Update selective fields of an existing quote, such as status, items, or client info, while leaving other data intact.

Instructions

Update an existing quote using PATCH semantics. Only the provided fields will be changed. Example: id='abc123', status='accepted' to mark a quote as accepted. / Actualiza un presupuesto existente. Solo se modifican los campos proporcionados.

Input Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	Quote ID / ID del presupuesto
`items`	No	Line items / Conceptos
`notes`	No	Notes / Notas
`status`	No	Status / Estado
`dueDate`	No	Due date in ISO 8601 (YYYY-MM-DD) / Fecha de vencimiento
`taxRate`	No	Tax rate % (e.g. 21 IVA, 7 IGIC) / Porcentaje de impuesto
`clientId`	No	Existing client ID — server back-fills taxId/address / ID de cliente existente
`irpfRate`	No	IRPF withholding % (retencion autonomo ES) / Retencion IRPF %
`issueDate`	No	Issue date in ISO 8601 (YYYY-MM-DD), defaults to today / Fecha de emision
`clientName`	No	Client name / Nombre del cliente
`validUntil`	No	Expiry date (YYYY-MM-DD) / Fecha de validez
`clientTaxId`	No	Client tax ID (NIF/CIF/VAT) / NIF/CIF del cliente
`clientAddress`	No	Client billing address / Direccion fiscal del cliente
`clientLocation`	No	Fiscal zone driving IVA vs IGIC vs exempt / Zona fiscal
`equivalenceSurchargeRate`	No	Recargo de equivalencia % / Recargo de equivalencia %

Output Schema

TableJSON Schema

Name	Required	Description	Default
`id`	Yes
`items`	No
`notes`	No
`total`	No
`status`	No
`createdAt`	No
`updatedAt`	No
`clientName`	No
`validUntil`	No

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.16.3Jul 22, 2026
Removedv1.15.2Jul 18, 2026

Changed3 schema fields changedv1.15.0Jul 11, 2026

addedOutput schema / properties / clientName / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

removedOutput schema / properties / clientName / type
```
Removed value: -"string"
```

changedOutput schema / required

Previous value: -[
-  "id",
-  "clientName",
-  "items"
-]New value: +[
+  "id"
+]

Changed9 schema fields changedv1.14.5Jul 7, 2026

addedInput schema / properties / clientAddress

Added value: +{
+  "description": "Client billing address / Direccion fiscal del cliente",
+  "type": "string"
+}

addedInput schema / properties / clientId

Added value: +{
+  "description": "Existing client ID — server back-fills taxId/address / ID de cliente existente",
+  "type": "string"
+}

addedInput schema / properties / clientLocation

Added value: +{
+  "description": "Fiscal zone driving IVA vs IGIC vs exempt / Zona fiscal",
+  "enum": [
+    "peninsula",
+    "canarias",
+    "ceuta_melilla",
+    "eu",
+    "world"
+  ],
+  "type": "string"
+}

addedInput schema / properties / clientTaxId

Added value: +{
+  "description": "Client tax ID (NIF/CIF/VAT) / NIF/CIF del cliente",
+  "type": "string"
+}

addedInput schema / properties / dueDate

Added value: +{
+  "description": "Due date in ISO 8601 (YYYY-MM-DD) / Fecha de vencimiento",
+  "type": "string"
+}

addedInput schema / properties / equivalenceSurchargeRate

Added value: +{
+  "description": "Recargo de equivalencia % / Recargo de equivalencia %",
+  "maximum": 100,
+  "minimum": 0,
+  "type": "number"
+}

addedInput schema / properties / irpfRate

Added value: +{
+  "description": "IRPF withholding % (retencion autonomo ES) / Retencion IRPF %",
+  "maximum": 100,
+  "minimum": 0,
+  "type": "number"
+}

addedInput schema / properties / issueDate

Added value: +{
+  "description": "Issue date in ISO 8601 (YYYY-MM-DD), defaults to today / Fecha de emision",
+  "type": "string"
+}

addedInput schema / properties / taxRate

Added value: +{
+  "description": "Tax rate % (e.g. 21 IVA, 7 IGIC) / Porcentaje de impuesto",
+  "maximum": 100,
+  "minimum": 0,
+  "type": "number"
+}

Changed2 schema fields changedv1.13.1Jun 17, 2026

changedInput schema / properties / validUntil / description

Previous value: -"Expiry date / Fecha de validez"New value: +"Expiry date (YYYY-MM-DD) / Fecha de validez"

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "clientName": {
+      "type": "string"
+    },
+    "createdAt": {
+      "type": "string"
+    },
+    "id": {
+      "type": "string"
+    },
+    "items": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "description": {
+            "type": "string"
+          },
+          "quantity": {
+            "type": "number"
+          },
+          "unitPrice": {
+            "type": "number"
+          }
+        },
+        "required": [
+          "description",
+          "quantity",
+          "unitPrice"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "notes": {
+      "type": "string"
+    },
+    "status": {
+      "type": "string"
+    },
+    "total": {
+      "type": "number"
+    },
+    "updatedAt": {
+      "type": "string"
+    },
+    "validUntil": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "clientName",
+    "items"
+  ],
+  "type": "object"
+}

First observedv1.1.0Mar 12, 2026

TDQS

A3.7/5.0

Behavior3/5

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

The description adds that only provided fields change (PATCH semantics) and gives an example, consistent with idempotentHint annotation. However, it does not disclose potential side effects like triggers upon status change or validation constraints.

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?

The description is very concise, with two clear sentences in English (plus a Spanish translation that doesn't harm). The example is front-loaded, making the purpose immediately clear.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the high parameter count and presence of an output schema, the description is somewhat complete but lacks details on behavioral nuances like updating nested objects or side effects. The relationship to sibling tools is not explained.

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 coverage is 100%, so the schema already describes all parameters. The description only adds an example for id and status, providing marginal value beyond the schema.

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 clearly states the verb 'Update' and resource 'existing quote' with 'PATCH semantics', and provides an example. It distinguishes from sibling tools like create_quote and delete_quote by specifying the update method and behavior.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

The description implies usage for modifying existing quotes but does not explicitly state when to use this tool versus others or provide exclusions. The example gives a common use case but lacks direct guidance.

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

Deploy Server