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.

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 · 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:

Read the thread · 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, issues #25–#34, PRs #21, #22, #23), the six design decisions that cohort embodies were

Read the thread · 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) from the v0.10 case stress test.

RFC-001 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 · 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, 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 · 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, 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 · 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, 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 · 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 · 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

Read the thread · 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:

Read the thread · 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:

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 · 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:

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 · 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 · 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:

Read the thread · 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 · 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 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 · 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, 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 · 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, 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 · 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, 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 · 2026-08-23 · open · 0 comments

The remaining reports are on the project's issue tracker.