malinoto/tracepass-mcp-server

События цепочки поставок GS1 EPCIS 2.0. export, capture, capture_job и query доступны на любом тарифе, включая Free. Захваченные события списываются из лимита событий тарифа (10 в месяц на Free); при превышении capture возвращает сообщение о превышении или жёсткой блокировке. Действия (передаются через action, вместе с args): - export - args: { id }. Экспортирует события паспорта в виде документа EPCIS 2.0 JSON-LD. Только чтение. - export_by_serial - args: { serial, gtin? }. То же, что export, но адресуется по вашему собственному серийному номеру. Серийный номер уникален только В ПРЕДЕЛАХ GTIN - если он не уникален в вашем аккаунте, вызов возвращает 409 ambiguous_serial; передайте gtin (или используйте export по id). Только чтение. - capture - args: { events }. events - это EPCISDocument, одно событие или массив событий (JSON-LD). Возвращает 202 с captureJobId. - capture_job - args: { jobId }. Опрашивает асинхронную задачу захвата. Только чтение. - query - args: { params? }. params - это карта ключ/значение стандартных параметров запроса EPCIS (EQ_bizStep, GE_eventTime, MATCH_epc, …). Только чтение.

Обновляет значения полей в Digital Product Passport. Каждое изменение записывается в журнал аудита паспорта вместе с учётными данными, под которыми оно сделано (API-ключ или подключённое приложение), и этим каналом MCP. source (необязательный) указывает, откуда пришло значение. Пропустите его или передайте "manual", когда пользователь дал вам значение или оно взято из его собственных записей: оно записывается с правами пользователя (одобряется для API-ключа или администратора; отправляется на проверку для подключённого приложения, действующего от имени редактора). Передайте "ai_suggested", когда вы сами нашли или вывели значение (веб-исследование, чтение документа): оно попадает в очередь проверки в панели управления, чтобы человек одобрил, и отклоняется для полей, которые может указывать только экономический оператор или которые должны быть измерены (например, battery stateOfHealth). Действия (передаются через action, вместе с args): - update - args: { id, fieldKey, value, source? }. Тип value соответствует dataType поля (string, number, boolean, array, object). - update_by_serial - args: { serial, fieldKey, value, gtin?, source? }. То же, что update, но адресуется по вашему собственному serial. Serial уникален только ВНУТРИ GTIN - если он не уникален в вашем аккаунте, вызов возвращает 409 ambiguous_serial; передайте gtin (или используйте update по id), чтобы точно определить.

Управляет сторонами-экономическими операторами в паспорте: manufacturer, importer, authorisedRepresentative, distributor, recycler, producerResponsibilityOrg. Каждая сторона имеет юридическое наименование и хотя бы один идентификатор. Правила идентификаторов (EN 18219 §6.2-6.5): стороне требуется хотя бы один из gln, legacyOperatorId или operatorIdentifier. Если указаны и gln, и operatorIdentifier (схема gln), они должны совпадать; при несовпадении возвращается 400. operatorIdentifier со схемой gln также заполняет поле gln верхнего уровня; facilityIdentifier не заполняет его никогда. Типизированные идентификаторы (operatorIdentifier / facilityIdentifier) не задаются при AI-извлечении или импорте CSV. Схемы operatorIdentifier: • iso6523 - { scheme:"iso6523", icd:"<4 цифры>", value } - ICD 0199 = LEI (ISO 17442), 0088 = GLN, 0060 = DUNS. • gln - { scheme:"gln", gln:"<13 цифр>" } - также заполняет gln верхнего уровня. • did - { scheme:"did", did:"did:<method>:<id>" } - проверяется только синтаксически (EN 18219 §6.4.2(b)). • doi - { scheme:"doi", doi:"10.<registrant>/<suffix>" } - префикс doi:/https://doi.org/ принимается и отбрасывается. Схемы facilityIdentifier: те же четыре; вариант gln также принимает необязательный extension (сублокация GS1 SGLN). Действия (передаются через action, с args): - set - args: { id, role, legalName, gln?, country?, legacyOperatorId?, operatorIdentifier?, facilityIdentifier? }. Устанавливает или обновляет одну роль. - remove - args: { id, role }. Удаляет сторону для этой роли.

Управляет цифровыми паспортами продуктов: создаёт, читает и выполняет действия жизненного цикла. ВАЖНО: create расходует слоты DPP и ТРЕБУЕТ ОПЛАТЫ. Создание сверх квоты влечёт плату за каждый паспорт; инструмент выдаёт сообщение в стиле 402 - повторно запускайте с args.confirmOverage=true только после того, как пользователь явно согласится. archive НЕОБРАТИМ (публичный QR навсегда возвращает 404); предпочитайте suspend, когда изменение можно отменить. СХЕМЫ ИДЕНТИФИКАТОРОВ (EN 18219): паспорта идентифицируются одной из пяти схем. Паспорта батарей (Battery Regulation Art. 77(3)) принимают ТОЛЬКО gs1 и iso15459. • gs1 - { scheme:"gs1", gtin, serialNumber } - GS1 GTIN + serial; gtin состоит из 8/12/13/14 цифр, хранится как GTIN-14. • iso15459 - { scheme:"iso15459", issuingAgencyCode, primaryId, serial? } - ISO/IEC 15459; сервер выводит raw (IAC + primaryId + serial). • iec61406 - { scheme:"iec61406", uri } - IEC 61406 Identification Link (https URI). Недействителен для батарей. • did - { scheme:"did", did, method } - W3C DID Core. Недействителен для батарей. • doi - { scheme:"doi", doi, granularity:"model"|"batch"|"item" } - ISO 26324 DOI, хранится в виде 10.<registrant>/<suffix> без префикса (любой префикс https://doi.org/ или doi: удаляется на входе; разрешается как https://doi.org/<doi>); granularity ОБЯЗАТЕЛЕН согласно EN 18219 §5.6.2(b). Недействителен для батарей. Старая пара gtin + serialNumber верхнего уровня всё ещё принимается как устаревший псевдоним для scheme:"gs1". Действия (передаются через action, с args): - list - args: { page?, limit? (≤100), productId?, status?, search? }. status ∈ draft|in_review|approved|published|suspended|expired|archived. Только чтение. - get - args: { id, format? (summary|full), lang? }. Только чтение. Ответ включает identifier, identifierKey и (для паспортов GS1) gs1. - get_by_serial - args: { serial, format?, lang?, gtin? }. Только чтение. Обращается к паспорту по вашему собственному serial. serial уникален только В ПРЕДЕЛАХ GTIN - если один и тот же serial существует под двумя GTIN в вашей учётной записи, вызов возвращает 409…

Управляет каталогом продуктов TracePass. Продукт — это слой каталога: один продукт может иметь множество паспортов (один на сериализованную единицу). Продукты сами по себе не тарифицируются. Действия (передаются через action с аргументами args): - list: аргументы { page?, limit? (≤100), category?, status?, search? }. Только для чтения. - get: аргументы { id }. Только для чтения. - create: аргументы { name, model, category, description? }. category — одно из: battery, textile, electronics, construction, steel, detergents, paints-coatings, packaging, furniture, tyres, jewelry, toys, fmcg. - update: аргументы { id, name?, model?, description? }; необходимо передать хотя бы одно поле для изменения. - create_batch: аргументы { products: [ { name, model, category, description? }, … ] }, до 100. Частичный успех: ответ содержит статус по каждому элементу, так что одни элементы могут быть созданы, а другие — с ошибкой. Весь пакет потребляет N записей заранее; если это превышает дневной лимит, НЕ создается ничего (429). - archive: аргументы { id }. Мягко архивирует продукт. Блокируется с кодом 409, пока хотя бы один неархивированный паспорт ссылается на него — сначала заархивируйте эти паспорта. Это обратимо и НЕ является удалением.

Проверьте, что говорит законодательство ЕС для типа продукта, соответствующего заданным фактам: нужен ли ему Digital Product Passport, с какого времени, на каком уровне, по какому акту и статье, и обязанности каждой роли. Также прочитайте отчёт о области применения по всему каталогу компании и запустите обновление каталога. ЖЁСТКИЕ ПРАВИЛА - всегда применяйте их к ответам по области применения: - Ответы сообщают, что говорит закон для типов продуктов, соответствующих заданным фактам. Это не юридическая консультация; никогда не пишите 'вы должны' - используйте формулировки для типа продукта ('LMT batteries need a passport from 18 February 2027, Battery Regulation Art. 77(1)'). - Ссылайтесь на статью, которую даёт ответ, для каждого вердикта и обязанности. Регламент без статьи - не ссылка. Ответ not_covered не опирается ни на какую статью: скажите, что наши правила не покрывают этот продукт, и назовите ближайший акт, который он приводит, но никогда не ссылайтесь на этот акт как на основание. - Дата с точностью 'quarter', 'month' или 'year' - это план, НИКОГДА не дедлайн и не дата начала. Пишите 'planned for Q2 2027 (planned, not law yet)', никогда 'from', 'by' или 'deadline'. - Передавайте not_covered и needs_input как результаты, которыми они являются, а не как ошибки. not_covered = продукт выходит за рамки этих правил области применения. needs_input = остаются без ответа блокирующие вопросы - передайте вопросы из ask[] пользователю, прежде чем выносить вердикт. - Пункты в списке planned акта ещё не являются законом: всегда помечайте их 'Planned, not law yet' (labelText), с их wording. - ruleStatus: 'needs_recheck' означает, что закон, лежащий в основе акта, изменился, и наши правила для него перепроверяются (с recheckSince): скажите об этом в ответе. Действия (передавайте через action, с args): - check — args: { category?, facts?, role?, placedOnMarket?, lifecycleEvent?, contains?, productId?, passportId?, locale? }. Спрашивает, нужен ли типу продукта DPP. Доступно на любом плане, включая Free. Учитывается в лимите ответов по области применения для компании (~100/день, 30/мин при всплеске), НЕ в бюджете чтения/записи v1. 429 scope_answer_cap, когда дневной лимит исчерпан.…

Обнаруживает схему полей регулирования для каждой категории DPP — что должен содержать СООТВЕТСТВУЮЩИЙ паспорт в соответствии с регулирующим регламентом ЕС. Справочные данные только для чтения. Используйте их для консультаций по требованиям перед созданием продуктов/паспортов и для проверки черновика на соответствие правилам. Действия (передаются через action с args): - list — args: {}. Выводит все 13 категорий с количеством полей, количеством обязательных полей и регулирующим регламентом (название + номер + даты вступления в силу/обязательного применения). - get — args: { category }. Полная схема полей для одной категории: ключ каждого поля, метка, тип данных, является ли оно ОБЯЗАТЕЛЬНЫМ, уровень доступа (public/restricted/authority), варианты enum, границы проверки и, где известно, статья/приложение регламента, которое его предписывает. category принимает одно из значений: battery, textile, electronics, construction, steel, detergents, paints-coatings, packaging, furniture, tyres, jewelry, toys, fmcg. BATTERY — обязательность зависит от категории, поэтому одного поля required недостаточно. Определяйте в таком порядке: 1. СНАЧАЛА ОПРЕДЕЛИТЕ ОБЛАСТЬ ПРИМЕНЕНИЯ. Только аккумуляторы EV, LMT и промышленные более 2 кВтч обязаны иметь паспорт (Статья 77(1), Reg (EU) 2023/1542). Для портативных, SLI или промышленных <=2 кВтч НИ ОДНО поле не является обязательным — не перечисляйте обязательные поля для них; сообщите, что аккумулятор не входит в область применения. 2. Затем используйте requiredBy[batteryCategory], где поле содержит эту карту (required | conditional | notApplicable). 3. Если ничего не подошло, используйте required. Карта индексируется ТОЛЬКО по трём категориям, входящим в область применения, поэтому пропуск шага 1 приводит к использованию required и создаёт обязательство, которое Регламент не налагает. Также обратите внимание, что EV и LMT сообщают о состоянии здоровья через ВЗАИМОИСКЛЮЧАЮЩИЕ наборы полей — аккумулятор EV должен оставлять пустым кластер remaining-capacity, а аккумулятор LMT должен оставлять пустым stateOfCertifiedEnergy, поэтому ни один аккумулятор никогда не заполняет все поля.