delete_rule

Удаляет развернутое пользовательское правило оценки. Правило перестает срабатывать при будущих вызовах evaluate_output; прошлые eval_results, которые на него ссылались, сохраняются. Связанные инструменты: deploy_rule добавляет пользовательские правила, list_rules перечисляет их, evaluate_output запускает их. delete_trace занимается удалением трейсов (отдельная задача); log_trace / get_traces отвечают за ввод/вывод трейсов. delete_rule - это ДЕСТРУКТИВНЫЙ путь удаления из хранилища пользовательских правил; он НЕ затрагивает трейсы, eval_results или встроенные (не пользовательские) правила. Поведение. ДЕСТРУКТИВНО: перезаписывает ~/.iris/custom-rules.json без удаленной строки и добавляет запись `rule.delete` в журнал аудита (~/.iris/audit.log). Не идемпотентно: удаление уже удаленного правила возвращает `deleted: false` вместо повторной эмиссии строки аудита. Правило перестает срабатывать немедленно на работающем процессе. Исторические eval_results, которые ссылаются на этот rule_id, остаются в базе данных - аналитика дрейфа и аудиторский след остаются валидными. В Cloud-версии ограничено тенантом; OSS работает с LOCAL_TENANT. Ограничение по частоте: 20 запросов/мин на HTTP MCP. Формат вывода. Возвращает JSON: `{ "deleted": boolean, "rule_id": string }`. `deleted=true`, если строка удалена; `deleted=false`, если правило с таким id не существовало. Используйте, когда пользовательское правило устарело (поведение изменилось, ложные срабатывания неприемлемы, заменено лучшим правилом). Типичный процесс: list_rules → определить устаревшее → delete_rule(id). Комбинируйте с deploy_rule для замены: delete_rule(oldId) + deploy_rule(newDefinition). Чтобы временно отключить правило БЕЗ удаления, используйте тумблер на панели управления - удаление задумано как постоянное (правило исчезает; для повторного добавления требуется новый id). Не используйте для приостановки правила (тумблер на панели управления лучше сохраняет историю). Не используйте для встроенных (не пользовательских) правил - формат rule_id проверяет идентификаторы `rule-<hex>`, встроенных правил в хранилище нет. Не используйте для удаления трейса или eval_result (для трейсов используйте delete_trace; удаление eval_results не раскрыто в v0.4 - они относятся к данным…)

Delete Custom Rule

Удаляет развернутое пользовательское правило оценки. Правило перестает срабатывать при будущих вызовах evaluate_output; прошлые eval_results, которые на него ссылались, сохраняются. Связанные инструменты: deploy_rule добавляет пользовательские правила, list_rules перечисляет их, evaluate_output запускает их. delete_trace занимается удалением трейсов (отдельная задача); log_trace / get_traces отвечают за ввод/вывод трейсов. delete_rule - это ДЕСТРУКТИВНЫЙ путь удаления из хранилища пользовательских правил; он НЕ затрагивает трейсы, eval_results или встроенные (не пользовательские) правила. Поведение. ДЕСТРУКТИВНО: перезаписывает ~/.iris/custom-rules.json без удаленной строки и добавляет запись `rule.delete` в журнал аудита (~/.iris/audit.log). Не идемпотентно: удаление уже удаленного правила возвращает `deleted: false` вместо повторной эмиссии строки аудита. Правило перестает срабатывать немедленно на работающем процессе. Исторические eval_results, которые ссылаются на этот rule_id, остаются в базе данных - аналитика дрейфа и аудиторский след остаются валидными. В Cloud-версии ограничено тенантом; OSS работает с LOCAL_TENANT. Ограничение по частоте: 20 запросов/мин на HTTP MCP. Формат вывода. Возвращает JSON: `{ "deleted": boolean, "rule_id": string }`. `deleted=true`, если строка удалена; `deleted=false`, если правило с таким id не существовало. Используйте, когда пользовательское правило устарело (поведение изменилось, ложные срабатывания неприемлемы, заменено лучшим правилом). Типичный процесс: list_rules → определить устаревшее → delete_rule(id). Комбинируйте с deploy_rule для замены: delete_rule(oldId) + deploy_rule(newDefinition). Чтобы временно отключить правило БЕЗ удаления, используйте тумблер на панели управления - удаление задумано как постоянное (правило исчезает; для повторного добавления требуется новый id). Не используйте для приостановки правила (тумблер на панели управления лучше сохраняет историю). Не используйте для встроенных (не пользовательских) правил - формат rule_id проверяет идентификаторы `rule-<hex>`, встроенных правил в хранилище нет. Не используйте для удаления трейса или eval_result (для трейсов используйте delete_trace; удаление eval_results не раскрыто в v0.4 - они относятся к данным…)

Параметры

rule_idstringобязательный
Rule id to delete (format: rule-<hex>); obtained from list_rules or deploy_rule response

delete_trace

Удаляет один трейс по идентификатору. Каскадно удаляет спаны; eval_results сохраняют историю оценок с обнулённым trace_id. Смежные инструменты — log_trace создаёт трейсы, get_traces их запрашивает, evaluate_output / evaluate_with_llm_judge / verify_citations выставляют оценки. delete_rule обрабатывает удаление пользовательских правил (отдельная задача); list_rules / deploy_rule управляют жизненным циклом пользовательских правил. delete_trace — это РАЗРУШИТЕЛЬНОЕ удаление одной строки для трейсов; оно НЕ трогает eval_results (сохраняются для аудита и аналитики дрейфа), спаны удаляются каскадно автоматически. Поведение. РАЗРУШИТЕЛЬНОЕ — SQL DELETE в пределах tenant_id вызывающего. Каскадирование: спаны, принадлежащие этому трейсу, удаляются (FK ON DELETE CASCADE); eval_results, ссылавшиеся на этот трейс, получают trace_id = NULL (FK ON DELETE SET NULL), чтобы агрегированные дашборды и исторические оценки оставались валидными даже после удаления трейса. Не идемпотентно: повторное удаление уже удалённого трейса возвращает `deleted: false`. В версии v0.4 не создаёт запись в логе аудита — трейсы относятся к пользовательским данным, а не к изменениям политик. Ограничение 20 запросов/мин на HTTP MCP. Формат вывода. Возвращает JSON: `{ "deleted": boolean, "trace_id": string }`. `deleted=true` если строка была удалена; `deleted=false` если трейса с таким id не существовало (или он принадлежал другому тенанту — кросс-тенантные удаления молча игнорируются). Используйте, когда трейс записан по ошибке, содержит конфиденциальные данные, которые нужно удалить для соответствия требованиям (например, клиент реализует право на забвение по GDPR), или при очистке тестовых данных. Комбинируйте с get_traces для поиска кандидатов: запрос с фильтрами → просмотр → delete_trace(id) для каждого целевого трейса. Для массового удаления по временному окну используйте `deleteTracesOlderThan` через CLI / настройку хранения — delete_trace это хирургический путь для одной строки. Не используйте для массовой очистки СТАРЫХ данных (используйте настройку хранения с `--retention-days`). Не используйте для ПРИОСТАНОВКИ трейса — трейсы неизменяемы после сохранения, приостанавливать нечего. Не используйте для удаления eval_results — eval_results намеренно переживают удаление своего трейса…

Delete Trace

Удаляет один трейс по идентификатору. Каскадно удаляет спаны; eval_results сохраняют историю оценок с обнулённым trace_id. Смежные инструменты — log_trace создаёт трейсы, get_traces их запрашивает, evaluate_output / evaluate_with_llm_judge / verify_citations выставляют оценки. delete_rule обрабатывает удаление пользовательских правил (отдельная задача); list_rules / deploy_rule управляют жизненным циклом пользовательских правил. delete_trace — это РАЗРУШИТЕЛЬНОЕ удаление одной строки для трейсов; оно НЕ трогает eval_results (сохраняются для аудита и аналитики дрейфа), спаны удаляются каскадно автоматически. Поведение. РАЗРУШИТЕЛЬНОЕ — SQL DELETE в пределах tenant_id вызывающего. Каскадирование: спаны, принадлежащие этому трейсу, удаляются (FK ON DELETE CASCADE); eval_results, ссылавшиеся на этот трейс, получают trace_id = NULL (FK ON DELETE SET NULL), чтобы агрегированные дашборды и исторические оценки оставались валидными даже после удаления трейса. Не идемпотентно: повторное удаление уже удалённого трейса возвращает `deleted: false`. В версии v0.4 не создаёт запись в логе аудита — трейсы относятся к пользовательским данным, а не к изменениям политик. Ограничение 20 запросов/мин на HTTP MCP. Формат вывода. Возвращает JSON: `{ "deleted": boolean, "trace_id": string }`. `deleted=true` если строка была удалена; `deleted=false` если трейса с таким id не существовало (или он принадлежал другому тенанту — кросс-тенантные удаления молча игнорируются). Используйте, когда трейс записан по ошибке, содержит конфиденциальные данные, которые нужно удалить для соответствия требованиям (например, клиент реализует право на забвение по GDPR), или при очистке тестовых данных. Комбинируйте с get_traces для поиска кандидатов: запрос с фильтрами → просмотр → delete_trace(id) для каждого целевого трейса. Для массового удаления по временному окну используйте `deleteTracesOlderThan` через CLI / настройку хранения — delete_trace это хирургический путь для одной строки. Не используйте для массовой очистки СТАРЫХ данных (используйте настройку хранения с `--retention-days`). Не используйте для ПРИОСТАНОВКИ трейса — трейсы неизменяемы после сохранения, приостанавливать нечего. Не используйте для удаления eval_results — eval_results намеренно переживают удаление своего трейса…

Параметры

trace_idstringобязательный
Trace id to delete (32-hex lowercase; obtained from log_trace response or get_traces)

deploy_rule

Разверните новое пользовательское правило оценки, которое будет срабатывать при каждом будущем вызове evaluate_output для своей категории eval. Сопутствующие инструменты — list_rules перечисляет развернутые правила, delete_rule удаляет их, evaluate_output запускает. log_trace / get_traces / delete_trace управляют жизненным циклом трассировок отдельно; evaluate_with_llm_judge / verify_citations выполняют семантическую оценку (не на основе эвристических правил). deploy_rule — это WRITE-путь, который пополняет библиотеку пользовательских правил. Поведение. Записывает строку в ~/.iris/custom-rules.json (атомарная запись через временный файл + переименование) и добавляет запись `rule.deploy` в журнал аудита (~/.iris/audit.log). Правило активируется немедленно для текущего процесса и сохраняется после перезапуска. Каждый вызов создает новый rule_id; идемпотентности нет (развертывание дважды создает два правила). В облачном тарифе действует на уровне тенанта; OSS-правила принадлежат LOCAL_TENANT. Ограничение по частоте — 20 запросов/мин на HTTP MCP. Форма вывода. Возвращает JSON: `{ "rule": { "id": "rule-XXXX", "name", "description", "evalType", "severity", "definition", "enabled": true, "createdAt", "updatedAt", "version": 1, "sourceMomentId?" } }`. Возвращенное правило — каноническая сохраненная форма; сохраните `id`, если планируете обновлять или удалять его позже. Используйте, когда агент замечает повторяющийся паттерн сбоев и решает закрепить его как постоянное правило. Поле `sourceMomentId` сохраняет происхождение — аудит впоследствии сможет связать правило с моментом, который его вдохновил. Комбинируйте с evaluate_output + get_traces: 1) evaluate_output выявляет сбои; 2) get_traces отфильтровывает набор сбоев; 3) анализируете паттерн; 4) deploy_rule встраивает его в стандартный путь оценки. Не используйте для ПРОВЕРКИ правила перед фиксацией — deploy записывает сразу. Используйте конечную точку предпросмотра в панели управления (POST /api/v1/rules/custom/preview) для пробной проверки на примере вывода. Не используйте для РЕДАКТИРОВАНИЯ существующего правила — этот вызов только создает; редактирование требует отдельного механизма (появится в v0.5). Чтобы обновить правило сейчас: delete_rule, затем deploy_rule с новыми…

Deploy Custom Rule

Разверните новое пользовательское правило оценки, которое будет срабатывать при каждом будущем вызове evaluate_output для своей категории eval. Сопутствующие инструменты — list_rules перечисляет развернутые правила, delete_rule удаляет их, evaluate_output запускает. log_trace / get_traces / delete_trace управляют жизненным циклом трассировок отдельно; evaluate_with_llm_judge / verify_citations выполняют семантическую оценку (не на основе эвристических правил). deploy_rule — это WRITE-путь, который пополняет библиотеку пользовательских правил. Поведение. Записывает строку в ~/.iris/custom-rules.json (атомарная запись через временный файл + переименование) и добавляет запись `rule.deploy` в журнал аудита (~/.iris/audit.log). Правило активируется немедленно для текущего процесса и сохраняется после перезапуска. Каждый вызов создает новый rule_id; идемпотентности нет (развертывание дважды создает два правила). В облачном тарифе действует на уровне тенанта; OSS-правила принадлежат LOCAL_TENANT. Ограничение по частоте — 20 запросов/мин на HTTP MCP. Форма вывода. Возвращает JSON: `{ "rule": { "id": "rule-XXXX", "name", "description", "evalType", "severity", "definition", "enabled": true, "createdAt", "updatedAt", "version": 1, "sourceMomentId?" } }`. Возвращенное правило — каноническая сохраненная форма; сохраните `id`, если планируете обновлять или удалять его позже. Используйте, когда агент замечает повторяющийся паттерн сбоев и решает закрепить его как постоянное правило. Поле `sourceMomentId` сохраняет происхождение — аудит впоследствии сможет связать правило с моментом, который его вдохновил. Комбинируйте с evaluate_output + get_traces: 1) evaluate_output выявляет сбои; 2) get_traces отфильтровывает набор сбоев; 3) анализируете паттерн; 4) deploy_rule встраивает его в стандартный путь оценки. Не используйте для ПРОВЕРКИ правила перед фиксацией — deploy записывает сразу. Используйте конечную точку предпросмотра в панели управления (POST /api/v1/rules/custom/preview) для пробной проверки на примере вывода. Не используйте для РЕДАКТИРОВАНИЯ существующего правила — этот вызов только создает; редактирование требует отдельного механизма (появится в v0.5). Чтобы обновить правило сейчас: delete_rule, затем deploy_rule с новыми…

Параметры

namestringобязательный
Human-readable rule name (used in eval results)
descriptionstring
What this rule checks for and why it matters
evalTypeenumобязательный
Eval category this rule belongs to; determines when it fires
completenessrelevancesafetycostcustom
severityenum
Severity used for dashboard sort + audit alerts
lowmediumhighcritical
definitionobjectобязательный
Check definition (regex, length, keyword, cost, or schema)
sourceMomentIdstring
Optional Decision Moment ID the rule was derived from (preserves workflow-inversion provenance)

evaluate_outputидемпотентный

Оценивает вывод агента по настраиваемым правилам эвалюации и возвращает оценку от 0 до 1 с разбивкой по каждому правилу. Смежные инструменты: evaluate_with_llm_judge выполняет семантическую оценку на основе LLM (медленнее, стоит денег; этот инструмент эвристический, бесплатный, детерминированный), verify_citations проверяет обоснованность цитирования, log_trace записывает выполнения, get_traces их запрашивает, list_rules / deploy_rule / delete_rule управляют жизненным циклом пользовательских правил. evaluate_output — ЭТО БЫСТРЫЙ ПУТЬ для проверок длины, ключевых слов, PII, инъекций, порогов стоимости, когда правил достаточно. Поведение. Детерминированная оценка внутри процесса — одни и те же входные данные всегда дают один и тот же результат. Записывает одну строку eval_result в хранилище Iris (привязанную к trace_id, если указан; иначе без привязки). В эвристическом режиме внешних сетевых вызовов нет (в версии v0.4 добавлен eval_type llm_as_judge, который ДЕЛАЕТ вызовы LLM API; для этого см. отдельный инструмент evaluate_with_llm_judge). Ограничение по скорости: 20 запросов/мин на HTTP MCP, безлимитно на stdio. Выполняется за ~5-50 мс для оценки на основе правил. Формат вывода. Возвращает JSON: `{ "id": "<uuid>", "score": 0..1, "passed": boolean, "rule_results": [{ "ruleName", "passed", "score", "message", "skipped?" }], "suggestions": string[], "rules_evaluated": number, "rules_skipped": number, "insufficient_data": boolean }`. `insufficient_data=true` означает, что не сработало ни одно применимое правило (например, оценка безопасности только с данными стоимости). Используйте, когда нужно получить оценку качества для конкретного вывода — обычно после того, как log_trace запишет выполнение. Передайте `eval_type`, чтобы направить в нужный набор правил: `completeness` (длина, количество предложений, релевантность входному запросу), `relevance` (пересечение ключевых слов, согласованность темы), `safety` (утечка PII, инъекция промпта, маркеры галлюцинаций, обнаружение заглушек), `cost` (бюджетный порог) или `custom` (собственные правила через `custom_rules`). Не используйте, когда вывод пустой или нет применимых правил — eval_type определяет, какие правила применить, а неверные комбинации возвращают score=0 + insufficient_data=true (не ошибка, но и не…

Evaluate Output

Оценивает вывод агента по настраиваемым правилам эвалюации и возвращает оценку от 0 до 1 с разбивкой по каждому правилу. Смежные инструменты: evaluate_with_llm_judge выполняет семантическую оценку на основе LLM (медленнее, стоит денег; этот инструмент эвристический, бесплатный, детерминированный), verify_citations проверяет обоснованность цитирования, log_trace записывает выполнения, get_traces их запрашивает, list_rules / deploy_rule / delete_rule управляют жизненным циклом пользовательских правил. evaluate_output — ЭТО БЫСТРЫЙ ПУТЬ для проверок длины, ключевых слов, PII, инъекций, порогов стоимости, когда правил достаточно. Поведение. Детерминированная оценка внутри процесса — одни и те же входные данные всегда дают один и тот же результат. Записывает одну строку eval_result в хранилище Iris (привязанную к trace_id, если указан; иначе без привязки). В эвристическом режиме внешних сетевых вызовов нет (в версии v0.4 добавлен eval_type llm_as_judge, который ДЕЛАЕТ вызовы LLM API; для этого см. отдельный инструмент evaluate_with_llm_judge). Ограничение по скорости: 20 запросов/мин на HTTP MCP, безлимитно на stdio. Выполняется за ~5-50 мс для оценки на основе правил. Формат вывода. Возвращает JSON: `{ "id": "<uuid>", "score": 0..1, "passed": boolean, "rule_results": [{ "ruleName", "passed", "score", "message", "skipped?" }], "suggestions": string[], "rules_evaluated": number, "rules_skipped": number, "insufficient_data": boolean }`. `insufficient_data=true` означает, что не сработало ни одно применимое правило (например, оценка безопасности только с данными стоимости). Используйте, когда нужно получить оценку качества для конкретного вывода — обычно после того, как log_trace запишет выполнение. Передайте `eval_type`, чтобы направить в нужный набор правил: `completeness` (длина, количество предложений, релевантность входному запросу), `relevance` (пересечение ключевых слов, согласованность темы), `safety` (утечка PII, инъекция промпта, маркеры галлюцинаций, обнаружение заглушек), `cost` (бюджетный порог) или `custom` (собственные правила через `custom_rules`). Не используйте, когда вывод пустой или нет применимых правил — eval_type определяет, какие правила применить, а неверные комбинации возвращают score=0 + insufficient_data=true (не ошибка, но и не…

Параметры

outputstringобязательный
The output text to evaluate (the agent's response that gets scored against rules)
eval_typeenum
Rule bundle to apply: completeness | relevance | safety | cost | custom — picks which built-in rules fire
completenessrelevancesafetycostcustom
expectedstring
Expected output for comparison — REQUIRED when eval_type="relevance" (used as keyword-overlap target)
inputstring
Original input for context — improves relevance scoring (keyword overlap vs input)
trace_idstring
Link evaluation to a trace — surfaces this eval in the dashboard's trace drill-through
custom_rulesobject[]
Custom evaluation rules — fires REGARDLESS of eval_type; pass eval_type="custom" if you want ONLY these
cost_usdnumber
Cost in USD — only consulted when eval_type="cost" (compared against cost_threshold rules)
token_usageobject
Token usage breakdown — only consulted when eval_type="cost" (used for token-budget rules)

evaluate_with_llm_judgeвнешний мир

Оценивает вывод агента с помощью LLM в роли судьи (Anthropic или OpenAI). Возвращает калиброванную оценку от 0 до 1 с обоснованием, разбивкой по измерениям и точной стоимостью. Смежные инструменты: `evaluate_output` выполняет эвристические правила (бесплатно, детерминированно, задержка ~мс, API-ключ не нужен); этот инструмент делает семантическую оценку на базе LLM (платно, задержка 1–10 с, нужен API-ключ). `verify_citations` — специализированная форма LLM-оценки, работающая только с привязкой к цитатам. `log_trace` / `get_traces` занимаются вводом-выводом трейсов; `list_rules` / `deploy_rule` / `delete_rule` управляют жизненным циклом эвристических правил. `evaluate_with_llm_judge` — общий путь семантической оценки. Поведение. Обращается к внешнему LLM API (Anthropic или OpenAI) — каждый вызов платный, занимает 1–10 секунд, соблюдает лимит `IRIS_LLM_JUDGE_MAX_COST_USD_PER_EVAL`. Недетерминирован при температуре > 0; температура по умолчанию 0 даёт почти детерминированные оценки. Записывает одну строку `eval_result` в хранилище Iris (связанную с `trace_id`, если он передан) и сохраняет `provider response id` + задержку + количество токенов + стоимость в полезной нагрузке `rule_results`. Ограничение частоты запросов — 20 запросов в минуту через HTTP MCP; ваш LLM-провайдер тоже устанавливает свои лимиты (при 429 ошибке прозрачно повторяем вызов один раз). Формат вывода. Возвращает JSON: `{ "id": "<uuid>", "score": 0..1, "passed": boolean, "rationale": string, "dimensions": {...}, "model": string, "provider": "anthropic"|"openai", "template": string, "input_tokens": number, "output_tokens": number, "cost_usd": number, "latency_ms": number }`. `dimensions` содержит оценки по каждому измерению (например, шаблон `accuracy` возвращает `{factual_claims, citations, internal_consistency}`). Используйте, когда эвристические правила (через `evaluate_output`) слишком грубы для нужного вам сигнала качества — семантическая корректность, фактическая точность относительно эталона, верность RAG-ответа источникам, тонкие вопросы безопасности/полезности. Выберите подходящий шаблон: `accuracy` (детекция галлюцинаций), `helpfulness` (отвечает ли на запрос), `safety` (потенциальный вред — шире, чем regex для PII), `correctness` (сравнение с эталонным ответом — передайте эталон в параметре `reference`).

Evaluate With LLM Judge

Оценивает вывод агента с помощью LLM в роли судьи (Anthropic или OpenAI). Возвращает калиброванную оценку от 0 до 1 с обоснованием, разбивкой по измерениям и точной стоимостью. Смежные инструменты: `evaluate_output` выполняет эвристические правила (бесплатно, детерминированно, задержка ~мс, API-ключ не нужен); этот инструмент делает семантическую оценку на базе LLM (платно, задержка 1–10 с, нужен API-ключ). `verify_citations` — специализированная форма LLM-оценки, работающая только с привязкой к цитатам. `log_trace` / `get_traces` занимаются вводом-выводом трейсов; `list_rules` / `deploy_rule` / `delete_rule` управляют жизненным циклом эвристических правил. `evaluate_with_llm_judge` — общий путь семантической оценки. Поведение. Обращается к внешнему LLM API (Anthropic или OpenAI) — каждый вызов платный, занимает 1–10 секунд, соблюдает лимит `IRIS_LLM_JUDGE_MAX_COST_USD_PER_EVAL`. Недетерминирован при температуре > 0; температура по умолчанию 0 даёт почти детерминированные оценки. Записывает одну строку `eval_result` в хранилище Iris (связанную с `trace_id`, если он передан) и сохраняет `provider response id` + задержку + количество токенов + стоимость в полезной нагрузке `rule_results`. Ограничение частоты запросов — 20 запросов в минуту через HTTP MCP; ваш LLM-провайдер тоже устанавливает свои лимиты (при 429 ошибке прозрачно повторяем вызов один раз). Формат вывода. Возвращает JSON: `{ "id": "<uuid>", "score": 0..1, "passed": boolean, "rationale": string, "dimensions": {...}, "model": string, "provider": "anthropic"|"openai", "template": string, "input_tokens": number, "output_tokens": number, "cost_usd": number, "latency_ms": number }`. `dimensions` содержит оценки по каждому измерению (например, шаблон `accuracy` возвращает `{factual_claims, citations, internal_consistency}`). Используйте, когда эвристические правила (через `evaluate_output`) слишком грубы для нужного вам сигнала качества — семантическая корректность, фактическая точность относительно эталона, верность RAG-ответа источникам, тонкие вопросы безопасности/полезности. Выберите подходящий шаблон: `accuracy` (детекция галлюцинаций), `helpfulness` (отвечает ли на запрос), `safety` (потенциальный вред — шире, чем regex для PII), `correctness` (сравнение с эталонным ответом — передайте эталон в параметре `reference`).

Параметры

outputstringобязательный
The agent output text to evaluate
templateenumобязательный
Judge dimension: accuracy (factual correctness), helpfulness (does it address the ask), safety (harm potential), correctness (vs reference answer — requires `expected`), faithfulness (RAG grounding — requires `source_material`).
accuracyhelpfulnesssafetycorrectnessfaithfulness
modelstringобязательный
Model ID. Supported: anthropic = claude-opus-4-7 | claude-sonnet-4-6 | claude-haiku-4-5 | claude-haiku-4-5-20251001; openai = gpt-4o | gpt-4o-mini | o1-mini.
providerenum
Auto-detected from model when omitted
anthropicopenai
inputstring
User question / prompt that produced the output (improves accuracy for helpfulness/safety)
expectedstring
Reference answer (required for correctness template)
source_materialstring
Provided RAG sources (required for faithfulness template)
trace_idstring
Link this evaluation to a trace
max_cost_usdnumber
Cost cap in USD; defaults to IRIS_LLM_JUDGE_MAX_COST_USD_PER_EVAL or 0.25
max_output_tokensinteger
Judge output token cap; default 512
temperaturenumber
Sampling temperature; default 0 (deterministic)
timeout_msinteger
Per-request timeout; default 60_000

get_tracesтолько чтениеидемпотентный

Запрашивает сохранённые трассы выполнения агентов с фильтрами, пагинацией и опциональной сводкой по дашборду. Связанные инструменты: `log_trace` создаёт трассы, `delete_trace` удаляет одну трассу, `evaluate_output` / `evaluate_with_llm_judge` / `verify_citations` оценивают их, `list_rules` / `deploy_rule` / `delete_rule` управляют жизненным циклом пользовательских правил. `get_traces` — это путь READ для исторических выполнений агентов — никогда ничего не меняет. Поведение. Только чтение: не изменяет хранилище, не вызывает внешние сервисы. Идемпотентно: повторные вызовы с теми же аргументами возвращают согласованные результаты (новые трассы, добавленные после вызова, разумеется, появятся при последующих вызовах). Ограничено тенантом: запрашивает только строки тенанта, с которого вызывается (`LOCAL_TENANT` в OSS). Пагинирует результаты (лимит по умолчанию 50, максимум 1000). Ограничение по частоте: 20 запросов/мин на HTTP MCP, без ограничений на stdio. Форма вывода. Возвращает JSON: `{ "traces": [{...traceRow}], "total": number, "limit": number, "offset": number, "summary"?: { total_traces, avg_latency_ms, total_cost_usd, error_rate, eval_pass_rate, traces_per_hour, top_agents } }`. Каждая строка трассы содержит `trace_id`, `agent_name`, `framework`, `input`, `output`, `tool_calls`, `latency_ms`, `token_usage`, `cost_usd`, `metadata`, `timestamp`. `summary` включается только при `include_summary: true`. Используй, когда нужны исторические данные: расследование прошлого сбоя, расчёт тенденций качества, сравнение агентов или передача данных в задачу аналитики. Укажи `agent_name` / `framework` / `since` / `until`, чтобы сузить запрос. Задай `min_score` / `max_score` для поиска выбросов. Поставь `sort_by: "cost_usd"` + `sort_order: "desc"`, чтобы найти самые дорогие трассы. Установи `include_summary: true`, если хочешь получить агрегаты в стиле дашборда за один круговой запрос. Не используй для оценки трассы (используй `evaluate_output`). Не используй для создания трассы (используй `log_trace`). Не используй как поток живых событий — это запрос, а не подписка; опрашивай с экспоненциальной задержкой или используй SSE-эндпоинт дашборда для реального времени. Параметры. `limit` по умолчанию 50, максимум 1000 (больше возвращает 400).

Get Traces

Запрашивает сохранённые трассы выполнения агентов с фильтрами, пагинацией и опциональной сводкой по дашборду. Связанные инструменты: `log_trace` создаёт трассы, `delete_trace` удаляет одну трассу, `evaluate_output` / `evaluate_with_llm_judge` / `verify_citations` оценивают их, `list_rules` / `deploy_rule` / `delete_rule` управляют жизненным циклом пользовательских правил. `get_traces` — это путь READ для исторических выполнений агентов — никогда ничего не меняет. Поведение. Только чтение: не изменяет хранилище, не вызывает внешние сервисы. Идемпотентно: повторные вызовы с теми же аргументами возвращают согласованные результаты (новые трассы, добавленные после вызова, разумеется, появятся при последующих вызовах). Ограничено тенантом: запрашивает только строки тенанта, с которого вызывается (`LOCAL_TENANT` в OSS). Пагинирует результаты (лимит по умолчанию 50, максимум 1000). Ограничение по частоте: 20 запросов/мин на HTTP MCP, без ограничений на stdio. Форма вывода. Возвращает JSON: `{ "traces": [{...traceRow}], "total": number, "limit": number, "offset": number, "summary"?: { total_traces, avg_latency_ms, total_cost_usd, error_rate, eval_pass_rate, traces_per_hour, top_agents } }`. Каждая строка трассы содержит `trace_id`, `agent_name`, `framework`, `input`, `output`, `tool_calls`, `latency_ms`, `token_usage`, `cost_usd`, `metadata`, `timestamp`. `summary` включается только при `include_summary: true`. Используй, когда нужны исторические данные: расследование прошлого сбоя, расчёт тенденций качества, сравнение агентов или передача данных в задачу аналитики. Укажи `agent_name` / `framework` / `since` / `until`, чтобы сузить запрос. Задай `min_score` / `max_score` для поиска выбросов. Поставь `sort_by: "cost_usd"` + `sort_order: "desc"`, чтобы найти самые дорогие трассы. Установи `include_summary: true`, если хочешь получить агрегаты в стиле дашборда за один круговой запрос. Не используй для оценки трассы (используй `evaluate_output`). Не используй для создания трассы (используй `log_trace`). Не используй как поток живых событий — это запрос, а не подписка; опрашивай с экспоненциальной задержкой или используй SSE-эндпоинт дашборда для реального времени. Параметры. `limit` по умолчанию 50, максимум 1000 (больше возвращает 400).

Параметры

agent_namestring
Filter by agent name — exact match (no wildcards in v0.4)
frameworkstring
Filter by agent framework — exact match (e.g., langchain, autogen)
sincestring
ISO timestamp lower bound — return traces with timestamp >= this
untilstring
ISO timestamp upper bound — return traces with timestamp < this
min_scorenumber
Minimum eval score filter (0..1) — applied to LATEST eval per trace, not all evals
max_scorenumber
Maximum eval score filter (0..1) — applied to LATEST eval per trace
limitnumber
Results per page (default 50, max 1000 — values >1000 return 400)
offsetnumber
Zero-based pagination offset — skip first N results
sort_byenum
Sort by timestamp | latency_ms | cost_usd (default timestamp)
timestamplatency_mscost_usd
sort_orderenum
Sort order: asc | desc (default desc — most recent / highest first)
ascdesc
include_summaryboolean
Include dashboard summary stats in same response — saves a round-trip when ingesting for dashboards

list_rulesтолько чтениеидемпотентный

Перечисляет пользовательские правила оценки, развёрнутые из локального хранилища правил. Связанные инструменты — deploy_rule добавляет пользовательские правила, delete_rule удаляет их, evaluate_output прогоняет их через вывод агента. log_trace / get_traces / delete_trace работают с жизненным циклом треков отдельно. list_rules — это путь чтения для хранилища пользовательских правил; больше ничего не показывает инвентарь. Поведение. Чистое чтение ~/.iris/custom-rules.json (кеш в памяти; после запуска сервера нет чтения с диска на каждый вызов). Никаких изменений, никаких внешних сетевых запросов. В Cloud-версии ограничено тенантом; OSS возвращает все правила для единственного локального тенанта. Ограничение по частоте — 20 запр./мин на HTTP MCP, безлимитно на stdio. Возвращает результат за <5 мс. Форма вывода. Возвращает JSON: `{ "rules": [{ "id": "rule-XXXX", "name", "description?", "evalType", "severity", "definition": { type, config, weight? }, "enabled": boolean, "deployedAt": ISO timestamp, "sourceMomentId?": string }], "total": number, "enabled_count": number }`. Пустой массив + total=0, когда правил нет. Используй, когда нужно узнать, какие пользовательские правила активны прямо сейчас (перед вызовом evaluate_output, перед развёртыванием похожего правила во избежание дубликатов или при построении панели управления). Фильтруй с `eval_type`, чтобы ограничиться конкретной категорией, или `enabled_only: true`, чтобы исключить отключённые правила. Для данных треков используй get_traces; для запуска оценки — evaluate_output; list_rules используй только когда нужен ИНВЕНТАРЬ ПРАВИЛ. Не используй для подсчёта треков или оценок (это get_traces). Не используй для просмотра встроенных (не пользовательских) правил — они поставляются с бинарником iris и перечислены в docs/api-reference.md, а не в хранилище правил. Не используй для развёртывания правила (используй deploy_rule); не используй для удаления правила (используй delete_rule). Параметры. Фильтр eval_type — точное совпадение со значением поля evalType каждого правила (без подстановочных знаков). enabled_only исключает правила, которые развёрнуты, но отключены (переключаются через интерфейс списка правил на панели управления — в v0.4 нет MCP-инструмента для переключения). Оба фильтра объединяются по И, если заданы оба. Оба…

List Custom Rules

Перечисляет пользовательские правила оценки, развёрнутые из локального хранилища правил. Связанные инструменты — deploy_rule добавляет пользовательские правила, delete_rule удаляет их, evaluate_output прогоняет их через вывод агента. log_trace / get_traces / delete_trace работают с жизненным циклом треков отдельно. list_rules — это путь чтения для хранилища пользовательских правил; больше ничего не показывает инвентарь. Поведение. Чистое чтение ~/.iris/custom-rules.json (кеш в памяти; после запуска сервера нет чтения с диска на каждый вызов). Никаких изменений, никаких внешних сетевых запросов. В Cloud-версии ограничено тенантом; OSS возвращает все правила для единственного локального тенанта. Ограничение по частоте — 20 запр./мин на HTTP MCP, безлимитно на stdio. Возвращает результат за <5 мс. Форма вывода. Возвращает JSON: `{ "rules": [{ "id": "rule-XXXX", "name", "description?", "evalType", "severity", "definition": { type, config, weight? }, "enabled": boolean, "deployedAt": ISO timestamp, "sourceMomentId?": string }], "total": number, "enabled_count": number }`. Пустой массив + total=0, когда правил нет. Используй, когда нужно узнать, какие пользовательские правила активны прямо сейчас (перед вызовом evaluate_output, перед развёртыванием похожего правила во избежание дубликатов или при построении панели управления). Фильтруй с `eval_type`, чтобы ограничиться конкретной категорией, или `enabled_only: true`, чтобы исключить отключённые правила. Для данных треков используй get_traces; для запуска оценки — evaluate_output; list_rules используй только когда нужен ИНВЕНТАРЬ ПРАВИЛ. Не используй для подсчёта треков или оценок (это get_traces). Не используй для просмотра встроенных (не пользовательских) правил — они поставляются с бинарником iris и перечислены в docs/api-reference.md, а не в хранилище правил. Не используй для развёртывания правила (используй deploy_rule); не используй для удаления правила (используй delete_rule). Параметры. Фильтр eval_type — точное совпадение со значением поля evalType каждого правила (без подстановочных знаков). enabled_only исключает правила, которые развёрнуты, но отключены (переключаются через интерфейс списка правил на панели управления — в v0.4 нет MCP-инструмента для переключения). Оба фильтра объединяются по И, если заданы оба. Оба…

Параметры

eval_typeenum
Filter to rules of a specific eval category
completenessrelevancesafetycostcustom
enabled_onlyboolean
Return only enabled rules (excludes disabled ones)

log_trace

Сохраняет один трейс выполнения агента (вход, выход, спаны, вызовы инструментов, стоимость, задержку, использование токенов). Связанные инструменты — evaluate_output запускает эвристическую оценку трейса; evaluate_with_llm_judge запускает семантическую оценку на основе LLM; verify_citations проверяет привязку цитат; get_traces запрашивает сохранённые трейсы; delete_trace удаляет один трейс; list_rules / deploy_rule / delete_rule управляют пользовательскими правилами оценки. log_trace — это путь ЗАПИСИ, который фиксирует выполнение; всё остальное читает, оценивает или управляет вокруг него. Поведение. Записывает одну строку в хранилище Iris (по умолчанию SQLite; в облачном тарифе — Postgres). Когда установлен IRIS_OTEL_ENDPOINT, также запускает асинхронный экспорт в настроенный OTLP/HTTP коллектор (Jaeger, Tempo, Datadog OTLP, OTEL Collector) без гарантии доставки. Экспорт OTel работает по принципу «запустил и забыл» — его успешность не влияет на ответ инструмента; ошибки логируются, но трейс всё равно сохраняется локально. Авторизация отсутствует в режиме stdio; в режиме HTTP требуется Bearer-токен. Ограничение скорости — 20 запросов в минуту для MCP по HTTP, безлимит для stdio. Не идемпотентен: каждый вызов создаёт новый trace_id, так что повторная отправка той же полезной нагрузки создаёт дублирующий трейс. Формат вывода. Возвращает JSON-строку: `{ "trace_id": "<32 шестнадцатеричных символа>", "status": "stored" }`. trace_id — это ключ, который вы передаёте в evaluate_output или get_traces позже. Используйте, когда нужно записать выполнение агента для последующей оценки, анализа или аудита. Вызывайте ПОСЛЕ того, как агент выдал результат; затем вызывайте evaluate_output, чтобы оценить его; вызывайте get_traces, чтобы запросить исторические трейсы. Сохраняйте богатый контекст: спаны (дерево спанов), tool_calls (какие инструменты вызывались с задержкой/ошибками), token_usage, cost_usd, metadata (произвольные пары ключ-значение). Всё опционально, кроме agent_name. Не используйте, если нужен только временный лог (используйте логирование в консоль). Не используйте для обновления существующего трейса — в версии 0.4 нет пути обновления (трейсы неизменяемы после сохранения). Параметры. agent_name обязателен; всё остальное опционально. token_usage и cost_usd — это сводка…

Log Trace

Сохраняет один трейс выполнения агента (вход, выход, спаны, вызовы инструментов, стоимость, задержку, использование токенов). Связанные инструменты — evaluate_output запускает эвристическую оценку трейса; evaluate_with_llm_judge запускает семантическую оценку на основе LLM; verify_citations проверяет привязку цитат; get_traces запрашивает сохранённые трейсы; delete_trace удаляет один трейс; list_rules / deploy_rule / delete_rule управляют пользовательскими правилами оценки. log_trace — это путь ЗАПИСИ, который фиксирует выполнение; всё остальное читает, оценивает или управляет вокруг него. Поведение. Записывает одну строку в хранилище Iris (по умолчанию SQLite; в облачном тарифе — Postgres). Когда установлен IRIS_OTEL_ENDPOINT, также запускает асинхронный экспорт в настроенный OTLP/HTTP коллектор (Jaeger, Tempo, Datadog OTLP, OTEL Collector) без гарантии доставки. Экспорт OTel работает по принципу «запустил и забыл» — его успешность не влияет на ответ инструмента; ошибки логируются, но трейс всё равно сохраняется локально. Авторизация отсутствует в режиме stdio; в режиме HTTP требуется Bearer-токен. Ограничение скорости — 20 запросов в минуту для MCP по HTTP, безлимит для stdio. Не идемпотентен: каждый вызов создаёт новый trace_id, так что повторная отправка той же полезной нагрузки создаёт дублирующий трейс. Формат вывода. Возвращает JSON-строку: `{ "trace_id": "<32 шестнадцатеричных символа>", "status": "stored" }`. trace_id — это ключ, который вы передаёте в evaluate_output или get_traces позже. Используйте, когда нужно записать выполнение агента для последующей оценки, анализа или аудита. Вызывайте ПОСЛЕ того, как агент выдал результат; затем вызывайте evaluate_output, чтобы оценить его; вызывайте get_traces, чтобы запросить исторические трейсы. Сохраняйте богатый контекст: спаны (дерево спанов), tool_calls (какие инструменты вызывались с задержкой/ошибками), token_usage, cost_usd, metadata (произвольные пары ключ-значение). Всё опционально, кроме agent_name. Не используйте, если нужен только временный лог (используйте логирование в консоль). Не используйте для обновления существующего трейса — в версии 0.4 нет пути обновления (трейсы неизменяемы после сохранения). Параметры. agent_name обязателен; всё остальное опционально. token_usage и cost_usd — это сводка…

Параметры

agent_namestringобязательный
Agent name — used for filtering in get_traces (e.g., "customer-support-bot")
frameworkstring
Agent framework identifier (e.g., langchain, autogen, custom)
inputstring
Agent input text — the user prompt or upstream input that produced this output
outputstring
Agent output text — what the agent produced (pass to evaluate_output for scoring)
tool_callsobject[]
Tool calls made during execution (per-call latency, errors, input/output)
latency_msnumber
Total execution time in milliseconds (end-to-end agent latency)
token_usageobject
Token usage breakdown (prompt/completion/total — used for cost analysis)
cost_usdnumber
Total cost in USD — overrides per-span aggregation when provided (treated as authoritative)
metadataobject
Opaque key-value tags (e.g. {requestId, userId, env}) — queryable in dashboard, not via get_traces filters
spansobject[]
Detailed execution spans (hierarchical span tree with timings, attributes, events)
timestampstring
Trace timestamp (ISO 8601); defaults to now() when omitted

verify_citationsвнешний мир

Извлекает цитаты из вывода агента, загружает указанные источники и использует LLM-судью, чтобы проверить, подтверждает ли каждый источник утверждение в контексте. Возвращает вердикт по каждой цитате + общий коэффициент поддержки. Родственные инструменты: evaluate_with_llm_judge выполняет общую семантическую оценку (точность, полезность, корректность, достоверность); этот инструмент предназначен специально для проверки обоснованности цитат (действительно ли указанный источник подтверждает утверждение). Эвристика no_hallucination_markers из evaluate_output дёшево обнаруживает ВЫГЛЯДЯЩИЕ сфабрикованными цитаты (бесплатно, без загрузки); этот инструмент разрешает и проверяет их (платно, опциональная загрузка, защита от SSRF). log_trace / get_traces обрабатывают ввод-вывод трассировок. verify_citations — это путь ПРОВЕРКИ ОБОСНОВАННОСТИ — самый узкий по охвату, самый глубокий по строгости. Поведение. Трёхфазный конвейер: (1) извлечение регулярными выражениями нумерованных ссылок [N], скобок (Автор, Год), голых URL и DOI (внутри процесса, без сети); (2) защищённая от SSRF загрузка цитат по URL и DOI, с белым списком схем, блокировкой частных/link-local/cloud-metadata IP, опциональным белым списком доменов (IRIS_CITATION_DOMAINS), таймаутом 10 с, лимитом тела 5 МБ, ручным отслеживанием перенаправлений (макс. 3, с повторной проверкой), внутрипроцессным LRU-кэшем; (3) вызов LLM-судьи для каждой цитаты с вопросом "подтверждает ли этот источник это утверждение?" и вердиктом из 256 токенов. Опционально включается через allow_fetch=true или IRIS_CITATION_ALLOW_FETCH=1 — по умолчанию Iris отклоняет исходящие HTTP-запросы. Ограничение стоимости на весь вызов через max_cost_usd_total (по умолчанию $1.00) — конвейер останавливается, если лимит будет превышен. Ограничение скорости 20 запросов/мин на HTTP MCP. Записывает одну строку eval_result с тегом происхождения каждой цитаты. Формат вывода. Возвращает JSON: `{ "id": "<uuid>", "overall_score": 0..1|null, "passed": boolean, "total_citations_found": number, "total_resolved": number, "total_supported": number, "total_cost_usd": number, "citations": [{ "citation": { "raw", "kind", "identifier", "offset_start", "offset_end" }, "resolve_status": "ok"|"skipped"|"error", "resolve_error"?, "source"?: { "url", "status", "content_type",…`

Verify Citations

Извлекает цитаты из вывода агента, загружает указанные источники и использует LLM-судью, чтобы проверить, подтверждает ли каждый источник утверждение в контексте. Возвращает вердикт по каждой цитате + общий коэффициент поддержки. Родственные инструменты: evaluate_with_llm_judge выполняет общую семантическую оценку (точность, полезность, корректность, достоверность); этот инструмент предназначен специально для проверки обоснованности цитат (действительно ли указанный источник подтверждает утверждение). Эвристика no_hallucination_markers из evaluate_output дёшево обнаруживает ВЫГЛЯДЯЩИЕ сфабрикованными цитаты (бесплатно, без загрузки); этот инструмент разрешает и проверяет их (платно, опциональная загрузка, защита от SSRF). log_trace / get_traces обрабатывают ввод-вывод трассировок. verify_citations — это путь ПРОВЕРКИ ОБОСНОВАННОСТИ — самый узкий по охвату, самый глубокий по строгости. Поведение. Трёхфазный конвейер: (1) извлечение регулярными выражениями нумерованных ссылок [N], скобок (Автор, Год), голых URL и DOI (внутри процесса, без сети); (2) защищённая от SSRF загрузка цитат по URL и DOI, с белым списком схем, блокировкой частных/link-local/cloud-metadata IP, опциональным белым списком доменов (IRIS_CITATION_DOMAINS), таймаутом 10 с, лимитом тела 5 МБ, ручным отслеживанием перенаправлений (макс. 3, с повторной проверкой), внутрипроцессным LRU-кэшем; (3) вызов LLM-судьи для каждой цитаты с вопросом "подтверждает ли этот источник это утверждение?" и вердиктом из 256 токенов. Опционально включается через allow_fetch=true или IRIS_CITATION_ALLOW_FETCH=1 — по умолчанию Iris отклоняет исходящие HTTP-запросы. Ограничение стоимости на весь вызов через max_cost_usd_total (по умолчанию $1.00) — конвейер останавливается, если лимит будет превышен. Ограничение скорости 20 запросов/мин на HTTP MCP. Записывает одну строку eval_result с тегом происхождения каждой цитаты. Формат вывода. Возвращает JSON: `{ "id": "<uuid>", "overall_score": 0..1|null, "passed": boolean, "total_citations_found": number, "total_resolved": number, "total_supported": number, "total_cost_usd": number, "citations": [{ "citation": { "raw", "kind", "identifier", "offset_start", "offset_end" }, "resolve_status": "ok"|"skipped"|"error", "resolve_error"?, "source"?: { "url", "status", "content_type",…`

Параметры

outputstringобязательный
The agent output containing citations to verify
modelstringобязательный
Judge model for per-citation verification. Supported: anthropic = claude-opus-4-7 | claude-sonnet-4-6 | claude-haiku-4-5-20251001; openai = gpt-4o | gpt-4o-mini | o1-mini.
providerenum
Auto-detected from model when omitted
anthropicopenai
allow_fetchboolean
Permit outbound HTTP to resolve URLs/DOIs. Defaults to IRIS_CITATION_ALLOW_FETCH=1; false otherwise. SSRF-guarded regardless.
domain_allowliststring[]
Restrict fetches to hostnames in this list (suffix match allowed). Merged with IRIS_CITATION_DOMAINS env.
max_cost_usd_totalnumber
Cap TOTAL judge cost across all citations in this call; default $1.00
max_citationsinteger
Max citations to verify (extras skipped); default 20
per_source_timeout_msinteger
Per-URL fetch timeout; default 10_000
per_source_max_bytesinteger
Per-URL body cap; default 5MB
trace_idstring
Link verification result to a trace


Trace Logging	Hierarchical span trees with per-tool-call latency, token usage, and cost in USD. Stored in SQLite, queryable instantly.
Output Evaluation	13 built-in rules across 4 categories: completeness, relevance, safety, cost. PII detection (10 patterns: SSN, credit card, phone, email, IBAN, DOB, MRN, IP, API key, passport), prompt injection (13 patterns), stub-output detection, hallucination markers (17 hedging phrases + fabricated-citation heuristic). Add custom rules with Zod schemas.
Cost Visibility	Aggregate cost across all agents over any time window. Set budget thresholds. Get flagged when agents overspend.
Web Dashboard	Real-time dark-mode UI with trace visualization, eval results, and cost breakdowns.

iris-eval/mcp-server

Iris — The Agent Eval Standard for MCP

The Problem

What You Get

Параметры

Параметры

Параметры

Параметры

Параметры

Параметры

Параметры

Параметры

Параметры

Другие проверенные MCP-сервера

Coding-Solo/godot-mcp

Perplexity MCP

QGIS MCP

heurist-network/heurist-mesh-mcp-server

Vultr MCP

bram2w/baserow