mcp

Mcp Ingest Code Scan

Post ONE code-scan run: the hardcoded, non-i18n strings found in the repo.

MCP twin of POST /v1/projects/{id}/code-scan, so the whole scan → agent flow runs on ONE mcp:* credential (task 1839).

THE SUBMITTED SET IS AUTHORITATIVE. Every finding already known to this project and ABSENT from this call is flipped to gone. Post the FULL result of one scan of the WHOLE repository — a partial list does not "add" findings, it retires the ones you did not walk, and the project then reads clean because nobody looked.

A run that would retire most of the project's live findings is REFUSED (422) unless confirm_mass_gone is set. If you hit that, the overwhelmingly likely cause is that you scanned a subdirectory or a shallow checkout — check what you walked before overriding it. Every run is written to the audit log with the calling key.

post/v1/mcp/projects/{project_id}/code-scan

Request

  • Base URL: https://api.sonenta.dev
  • URL: https://api.sonenta.dev/v1/mcp/projects/{project_id}/code-scan
  • Auth: none declared

Path parameters

project_idstring required

Request body

findingsobject[]

EVERY hardcoded string this run found, as {file, line, column?, string, suggested_namespace?}. The set is AUTHORITATIVE: anything known to the project and absent here is marked gone. Post the FULL result of one scan — a partial list retires findings that are still in the code.

metaobject nullable

Run context (tool, version, sha).

confirm_mass_goneboolean

Only set this when you INTEND to retire most of the project's live findings. Without it such a run is refused (422). If you hit that refusal, the usual cause is that you scanned part of the repository, not that the strings are gone.

component_prop_inventoryobject[] nullable

Translatable-props inventory, as [{component, prop, is_component?, count?, samples?, first_file?, first_line?}]. PRESENCE is the contract: OMIT the field to leave the inventory untouched; send the list (even empty) to REPLACE it authoritatively. Does not affect findings — a picked prop still comes back as a normal finding when you flag it in this run's findings.

Response

Successful Response

object required

Changes

No recorded changes to this operation across all 1 revision of this API.