[anticafeformat-dev]

Problem

Bitrix REST returns tasks.task.getFields as:

{
  "result": {
    "fields": {
      "ID": {...},
      "TITLE": {...},
      "DEADLINE": {...},
      "PRIORITY": {...},
      ...
    }
  }
}

After callApi strips the outer result, parseTaskFields receives {fields: {...}} — but it iterates the top-level entries and treats fields itself as the only field. The inner value is the real field map (a large nested object), so the existing if (!value || typeof value !== "object" || Array.isArray(value)) check passes — and the parser silently produces {fields: {ID:..., TITLE:..., ...}} with one top-level key.

The downstream effect lands in the MCP adapter createTask.ts, which calls getTaskFields() to build the allowed-field set for input validation:

const availableFields = await service.getTaskFields();
const unknownFields = Object.keys(parsed.data.fields).filter(
  (field) => !(field in availableFields)
);

availableFields ends up as {fields: {...}} — the only allowed name is fields. Any real Bitrix field passed by the caller (DEADLINE, PRIORITY, PARENT_ID, START_DATE_PLAN, etc.) hits the unknownFields branch and is rejected with Unknown task fields. This makes the create_task tool's fields parameter effectively unusable for setting deadlines or any other field beyond the four flat ones (title, description, responsible_id, group_id).

Fix

Unwrap the inner fields key when present, so iteration runs over the actual field map:

let source: Record<string, unknown> = record;
const inner = record.fields;
if (inner && typeof inner === "object" && !Array.isArray(inner)) {
  source = inner as Record<string, unknown>;
}
// ...iterate Object.entries(source) instead of Object.entries(record)

The fallback (use record directly if no fields key) preserves backward compatibility for any future Bitrix portal that returns the flat shape.

Verification

$ get_task_fields
# Before: { "fields": { "fields": { "ID": {...}, "TITLE": {...}, ... } } }
#   → top-level keys count = 1 (only "fields"), parsing accepts but yields useless map
# After:  65 real Bitrix task fields enumerated correctly
#   (DEADLINE, PRIORITY, PARENT_ID, RESPONSIBLE_ID, GROUP_ID, START_DATE_PLAN, ... all visible)

$ create_task title="..." responsible_id=1 fields={DEADLINE: "2026-05-15T18:00:00+03:00", PRIORITY: "2"}
# Before: throws { "code": -32602, "message": "Unknown task fields", "data": {"unknownFields": ["DEADLINE", "PRIORITY"]} }
# After:  { "task_id": 142685 } — Bitrix task created with deadline and priority as requested

Note

This is independent from PRs #1 (capabilities shape), #2 (tools/call result envelope), and #3 (task field expansion in select). Four orthogonal fixes that arose during real-world MCP integration deployment. Can be merged in any order.