Skip to main content
Glama
Sign In
voxfactura-mcp

voxfactura-mcp

by VoxFactura
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

marge_chantier

Calculate a construction site's margin by subtracting assigned expenses from invoiced revenue, using the site number in the account. Requires invoice and expense permissions.

Instructions

Ancien regroupement, gardé pour compatibilité : préférer marge_client. Marge d'un chantier (par son numéro dans le compte) : chiffre d'affaires facturé moins les dépenses rangées sur ce chantier. Nécessite une clé avec les permissions factures + dépenses.

Input Schema

NameRequiredDescriptionDefault
dossierNo
chantier_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.2.1
    • addedInput schema / properties / dossier
      Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Dossier"
+}
  2. First observedv0.1.1

TDQS

A4.2/5.0
Behavior4/5

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

No annotations are provided, so the description carries the full burden and does reasonably well: it discloses the auth/permission requirement (invoices + expenses scope) and the exact computation semantics (billed revenue minus site expenses). It does not describe the response shape or how the value is returned, which is the remaining gap.

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?

Three compact sentences with the deprecation/alternative notice front-loaded, followed by definition and prerequisites. Every sentence earns its place; no filler or repetition.

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 annotations and no output schema, the description does most of the load-bearing work: it explains what is computed, so the return value is inferable, and it states required permissions. The unexplained `dossier` parameter is the one meaningful omission.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It partially clarifies `chantier_id` ('par son numéro dans le compte' — the account's site number), but the optional `dossier` parameter is never mentioned anywhere, leaving half the input surface undocumented in both schema and prose.

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 the resource (chantier margin) and defines it precisely: billed revenue minus expenses attributed to that site. It also marks itself as a deprecated compatibility shim and points to `marge_client`, so an agent can distinguish it from the near-identical sibling without opening either schema.

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 gives explicit routing guidance: 'préférer `marge_client`' for new work, and states this tool is kept only for backward compatibility. It also names the required key permissions (factures + dépenses), which is an actionable prerequisite for invocation.

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

Deploy Server

Other Tools