# Reported issues for Servicialo MCP Server

Pod holds 19 of 27 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to [Servicialo MCP Server](/mcp/servicialo-mcp-server).

## Most discussed

### Proposal: add `provenance` field to delivery and payment events

## Summary

The protocol today treats `entrega_verificada` and 
`pago_verificado` as binary assertions: either the event fired 
for a given `correlationId` or it didn't. This loses information 
that every mature implementation ends up needing: **who or what 
asserted the fact, and how strong is that assertion**.

This issue proposes adding a `provenance` field to both 
primitives, so consumers can reason about trust, audit chains, 
and dispute resolution without each implementation inventing 
it

[Read the thread](https://github.com/servicialo/mcp-server/issues/7) · 2026-04-18 · open · 2 comments

### [binding] Wire body fields are camelCase, and one operation is in Spanish

## Problem

Tool *inputs* are snake_case (`to_state`, `evidence_type`, `service_id`, `starts_at`). The *bodies they send* are camelCase:

| Operation | Sends |
|---|---|
| `lifecycle.transition` | `toState` |
| `delivery.record_evidence` | `evidenceType` |
| `scheduling.book` | `serviceId`, `providerId`, `clientId`, `startTime`, `resourceId` |
| `scheduling.reschedule` | `startTime` |
| `clients.get_or_create` | `lastName` |
| `documentation.create` | `templateId` |
| `payments.create_sale` | `u

[Read the thread](https://github.com/servicialo/mcp-server/issues/41) · 2026-08-24 · open · 1 comment

### [protocol] Are obligations projections or first-class objects? Assignment and set-off as the test

## Context

**Where this comes from.** After the v0.10 stress-test cohort was published
([PR #24](https://github.com/servicialo/mcp-server/pull/24), issues
[#25](https://github.com/servicialo/mcp-server/issues/25)–[#34](https://github.com/servicialo/mcp-server/issues/34),
PRs [#21](https://github.com/servicialo/mcp-server/pull/21),
[#22](https://github.com/servicialo/mcp-server/pull/22),
[#23](https://github.com/servicialo/mcp-server/pull/23)), the six design decisions
that cohort embodies were 

[Read the thread](https://github.com/servicialo/mcp-server/issues/36) · 2026-08-23 · open · 1 comment

### [implementation] Implement version negotiation and deprecation signalling in the reference MCP server

## Context

Surfaced while drafting the vocabulary migration plan ([PR #23](https://github.com/servicialo/mcp-server/pull/23)) from the
[v0.10 case stress test](https://github.com/servicialo/mcp-server/blob/main/docs/servicialo-stress-test-casos.md).

[RFC-001](https://github.com/servicialo/mcp-server/pull/13) specifies version
coexistence (§3.7) and deprecation signalling (§3.6). **Neither exists in the
reference implementation**, and at least two v1.0 changes are already written
assuming both 

[Read the thread](https://github.com/servicialo/mcp-server/issues/33) · 2026-08-23 · open · 1 comment

### [settlement] Core billing.status cannot represent an unconsented reversal (chargeback)

## Context

Surfaced by the [v0.10 case stress test](https://github.com/servicialo/mcp-server/blob/main/docs/servicialo-stress-test-casos.md),
**Case 7 — wedding photography: partial delivery + chargeback**, while checking
what a conforming implementation records after the reversal.

100% prepaid by card. Coverage delivered and accepted; album never delivered. The
client charges back **the total** through the card rail. The provider contests it.

## What is already answered — do not re-litigate

[Read the thread](https://github.com/servicialo/mcp-server/issues/32) · 2026-08-23 · open · 1 comment

### [conformance] Define a consumer conformance profile and verify mandate scope enforcement

## Context

Surfaced by the [v0.10 case stress test](https://github.com/servicialo/mcp-server/blob/main/docs/servicialo-stress-test-casos.md),
**Case 6 — home care with a delegated agent** (question 11 of 12).

The daughter's mandate authorizes her agent to schedule and reschedule up to 8
visits a month within a spend cap, and explicitly forbids cancelling the series.
Later the agent attempts to cancel the series. Nothing in the conformance surface
today says what a conforming system must do abo

[Read the thread](https://github.com/servicialo/mcp-server/issues/30) · 2026-08-23 · open · 1 comment

### [settlement] Support conditional holdback (hold → release) in the Settlement extension

## Context

Surfaced by the [v0.10 case stress test](https://github.com/servicialo/mcp-server/blob/main/docs/servicialo-stress-test-casos.md),
**Case 2 — industrial repair by milestones** (question 6 of 12).

The Order retains 10% of each milestone. The retention is released 60 days later
**if no warranty claim is filed**. This is an extremely common B2B construction and
industrial term, and it is the first settlement condition in the case set that is
triggered by the *absence* of an event rathe

[Read the thread](https://github.com/servicialo/mcp-server/issues/26) · 2026-08-23 · open · 1 comment

### Proposal: declare canonical state as a function of lifecycle transitions

## Summary

In a conforming implementation, the enumerated 
`lifecycle.current_state` field is redundant with the transition 
history stored in `lifecycle.transitions[]`. The current state 
of an entity is always the `to` value of the most recent 
transition record. Today the spec defines `current_state` as 
REQUIRED and `transitions[]` as OPTIONAL — so implementations 
are free to store the state without the history, and the 
consistency invariant between them is undefined.

This issue proposes

[Read the thread](https://github.com/servicialo/mcp-server/issues/11) · 2026-04-18 · open · 1 comment

## Most recent

### [conformance] RFC-lite (retroactive): CORE normative sentence and scheduling.check_availability as a required operation

## Status — retroactive RFC-lite, open for objection

| | |
|---|---|
| **Category** | Editorial clarification with one conscious decision (below) |
| **Venue** | This issue |
| **Objection window** | **through 2026-09-06** — in parallel with [RFC-005](https://github.com/servicialo/mcp-server/pull/21) |
| **Closure criterion** | Closed with a note in the HTTP Profile release. If an objection lands before the date, it is answered here and the CORE list changes before that release. |
| **Shipped i

[Read the thread](https://github.com/servicialo/mcp-server/issues/45) · 2026-08-24 · open · 0 comments

### [binding] Decide the node /v1/manifest response shape — four exist, the manifest declares none

## Problem

`registry.manifest` is a **required** CORE operation (`conformance.core.required_operations`) — a node must serve `GET /v1/manifest`. Four different shapes describe what it returns, and `protocol/manifest.yaml` declares none of them:

| Source | Shape |
|---|---|
| HTTP Profile 1.0.0 §4.0 example | `{"servicialo": "0.7", "name", "description", "endpoints"}` |
| Live resolver `/api/servicialo/manifest` | `{servicialo_version: "1.0", name, description, resolver, registry, endpoints, …}

[Read the thread](https://github.com/servicialo/mcp-server/issues/44) · 2026-08-24 · open · 0 comments

### [conformance] CORE requires an agent card while the A2A binding is experimental

## Problem

`public/spec/certification.md` CORE requirement 5 makes an agent card mandatory at the minimum conformance level:

> 5. **Discovery Endpoint** — Expose a Level 2 agent card at `/.well-known/agent.json`

But `protocol/manifest.yaml` declares the A2A binding **experimental**:

```yaml
a2a:
  maturity: experimental   # partial surface: discovery + booking intents, not the full tool surface
  version: "0.3"
  agent_card: /.well-known/agent.json
```

So the minimum bar for calling an impl

[Read the thread](https://github.com/servicialo/mcp-server/issues/43) · 2026-08-24 · open · 0 comments

### [binding] Error envelope and codes are not exercised by the reference client

## Problem

`HttpAdapter` treats every non-2xx as a failure and raises an error carrying method, path, status and the response body **as text**:

```ts
if (!res.ok) {
  const body = await res.text();
  throw new Error(`GET ${path} failed (${res.status}): ${body}`);
}
```

It never parses JSON on the error path. No reference code reads `errors[]`, `code`, `title`, `source`, or any of the eleven codes the profile lists (`INVALID_TRANSITION`, `MANDATE_REQUIRED`, `SCOPE_INSUFFICIENT`, …).

Profile 1

[Read the thread](https://github.com/servicialo/mcp-server/issues/42) · 2026-08-24 · open · 0 comments

### [binding] Profile 2.0 — JSON:API envelope, with the 1.0.0 design as historical reference

## Context

`spec/HTTP_PROFILE.md` 1.0.0 specified a full JSON:API binding: `{"data":{"type","id","attributes"}}` envelopes on every request and response, `meta`/`links` pagination, `application/vnd.api+json` content negotiation, and an `{"errors":[…]}` envelope with eleven codes.

**None of it was ever implemented.** Every reference tool handler returns `res.json()` verbatim; an implementation that wrapped its payloads as 1.0.0 described would hand agents an object one level deeper than any con

[Read the thread](https://github.com/servicialo/mcp-server/issues/40) · 2026-08-24 · open · 0 comments

### HTTP contract: profile, suite and tools disagree — document the running wire, one CORE list, honest suite output

## Problem

Three surfaces describe the same operations and no two agree. A second implementer building from the documents would not interoperate with the reference implementation.

### 1. The profile describes a binding that was never implemented

`spec/HTTP_PROFILE.md` 1.0.0 specifies a JSON:API envelope, a `/servicialo/v1/` base path, an `X-Servicialo-Actor` header, and paths no reference client calls. Same operation, three contracts:

| | Path | Body |
|---|---|---|
| Tool → adapter (what ru

[Read the thread](https://github.com/servicialo/mcp-server/issues/39) · 2026-08-24 · open · 0 comments

### Version drift in doc bodies, examples and telemetry default — the guardrail only reads headers

## Problem

`scripts/verify-versions.mjs` checks six header lines and three package fields. It never reads a document body, an example payload, or a code default — so **17 stale version literals sat in green CI**.

The load-bearing one: `spec/HTTP_PROFILE.md` §2.2 documented `X-Servicialo-Version` as `0.8` **and labelled it "Protocol version"**, while `lib/servicialo/response.ts` and `lib/servicialo/proxy.ts` have always emitted `1.0`. The mislabel is what invited the drift — a reader bumps a he

[Read the thread](https://github.com/servicialo/mcp-server/issues/38) · 2026-08-24 · open · 0 comments

### [docs] Two spec clarifications surfaced by the v0.10 stress test

## Context

Two of the twelve questions raised by the
[v0.10 case stress test](https://github.com/servicialo/mcp-server/blob/main/docs/servicialo-stress-test-casos.md)
turned out to be answered by the spec on verification — one by construction rather
than by statement, one by a version number that drifted. Neither is a protocol
change. Both are worth fixing because a reader who asked the question had to
reconstruct the answer.

Editorial per RFC-001 §3.2 (1 week comment window, no implementation

[Read the thread](https://github.com/servicialo/mcp-server/issues/34) · 2026-08-23 · open · 0 comments

### [settlement] Declare allocation of Order-level settlement amounts across deliveries

## Context

Surfaced by the [v0.10 case stress test](https://github.com/servicialo/mcp-server/blob/main/docs/servicialo-stress-test-casos.md),
**Case 7 — wedding photography: partial delivery + chargeback** (question 12 of
12, allocation half).

One Order, two deliveries: event coverage (delivered impeccably, confirmed by the
client) and a physical album (never delivered). The package was 100% prepaid by
card. The client charges back **the total** through the card rail.

The resulting state is t

[Read the thread](https://github.com/servicialo/mcp-server/issues/31) · 2026-08-23 · open · 0 comments

### [evidence] Declare acceptance authority in Order policy — the client side is not one actor

## Context

Surfaced by the [v0.10 case stress test](https://github.com/servicialo/mcp-server/blob/main/docs/servicialo-stress-test-casos.md),
**Case 6 — home care with a delegated agent** (question 10 of 12).

The daughter is payer and principal, and delegates scheduling to her agent. The
mother is the beneficiary. On visit 5 the assigned carer never arrives, a
substitute arrives two hours late, **the mother confirms the visit**, and **the
daughter disputes the charge**.

Both statements are tr

[Read the thread](https://github.com/servicialo/mcp-server/issues/29) · 2026-08-23 · open · 0 comments

### [evidence] Let Evidence reference content-addressed artifacts shared across deliveries

## Context

Surfaced by the [v0.10 case stress test](https://github.com/servicialo/mcp-server/blob/main/docs/servicialo-stress-test-casos.md),
**Case 5 — 20-student cohort** and **Case 9 — subcontracting chain** (question 9
of 12).

One physical fact, N commercial truths:

- Case 5: one class session, one signed attendance sheet, one recording — and 20
  bilateral Orders, therefore 20 deliveries, each of which needs that same sheet
  as evidence.
- Case 9: one window cleaning, two independent bi

[Read the thread](https://github.com/servicialo/mcp-server/issues/28) · 2026-08-23 · open · 0 comments

The remaining reports are on [the project's issue tracker](https://github.com/servicialo/servicialo/issues).