Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

MCP: one error model and one serializer for every tool (validation errors are returned as success)

Aperta
  • Qualcosa non va?
#92 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Refactoring
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
csharp
Ambito
api, backend, cli

Direzione di ricerca

Start with McpInvocationFilter, McpStdioToolCallTests.McpToolCall_WhenTheApiFails_IsReportedAsAToolError, and OutputHelper.WriteApiError to trace the existing error contract. Then inspect Features/Mcp/Tools, Program.cs, and McpHostCommand for duplicated handling and registration. Done means validation, write-service, serialization, logging, and registration behavior are unified without unreviewed golden or wire-contract changes.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Priority: P1 Type: Refactor

Why

Sharing was started but the MCP side of the contract was never finished, so every other slice of #38 inherits the problem.

  • Validation and auth failures are returned as successful tool results (return """{"error": "..."}"""), about 20 sites across TimesheetMcpTools, LeaveMcpTools and AccountingMcpTools. API failures throw, so the SDK marks them isError. A client checking isError sees the first class as success.
  • A third class escapes as a protocol error: DateOnly.ParseExact in the tools throws FormatException for bad input, even though TimesheetCreateService.ParseDate already turns the same input into a validation exception.
  • TimesheetWriteResult.Success == false is an error on the CLI (UpdateCommand, AcceptCommand, CreateCommand) but serialised as ordinary content by the MCP tools.
  • McpInvocationFilter only records failure on a throw, so the local command log shows returned errors as successes.
  • Serialiser policy is split: OutputHelper.JsonOptions omits nulls, AccountingMcpTools copies that, the timesheet/leave/lookup tool classes write nulls, and CreateTimesheet alone uses OutputHelper.SerializeJson. This is why parity rows need PermittedDifferences like $.timesheet.invoiceId.
  • Adapter boilerplate is copied: three ResolveEmpId helpers with two different semantics, three "not logged in" strings, and the DI registration list duplicated between Program.cs and McpHostCommand (a new service must be registered twice).

Migrate

  • One base validation exception (or error record) that TimesheetValidationException, the leave validation exceptions and the import exceptions derive from; carry message, detail, recovery hint and mayHaveBeenApplied.
  • Map it once, in McpInvocationFilter, to a CallToolResult with IsError = true and the same {"error":{code,message,detail}} body the CLI --json envelope uses. Record the failure in the command log.
  • Remove every catch … return "{\"error\"…}" and every JsonOpts field from Features/Mcp/Tools; serialise through OutputHelper.SerializeJson.
  • Parse dates in tools through one invariant helper that throws the validation exception.
  • Treat Success == false from a write service the same way on both surfaces.
  • One AddTimeProServices() extension used by Program.cs and McpHostCommand; one shared tool helper for tenant/emp-id resolution.

How

Do this first; the other sharing issues assume it. McpStdioToolCallTests.ToolCall_WhenTheApiFails_IsReportedAsAToolError already proves the SDK maps a thrown exception to isError, so the filter can own the mapping and tools stop catching anything. OutputHelper.WriteApiError is the CLI half to mirror for detail and requestId.

Contract

Error payloads and null omission change MCP output. The code can land in a patch behind the existing goldens only if the old shapes are preserved; otherwise hold the wire change for 0.4.0 and regenerate goldens once (#71 first, so the regenerate is reviewable).

Part of #38.

Lingua principale
C#
Stelle
3
Fork
0
Merge medio
6m
PR unite (30g)
1

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

  • Nessun Dockerfile né file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di SSWConsulting/TimePro.Tools

Tutte le issue di SSWConsulting/TimePro.Tools

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.