Fix place_family failing to find families/types and accented names on Revit 2026

[thiagokeneth]

Summary

Two independent bugs made place_family unusable on Revit 2026, both in revit_mcp/utils.py / revit_mcp/placement.py:

1. find_family_symbol_safely — any lookup returned "Family type not found"

symbol.Name is not accessible through the IronPython binding for every FamilySymbol on Revit 2026 and raises AttributeError. The whole search loop sat inside one outer try/except, so the first symbol that raised on .Name access aborted the entire search and the function returned None regardless of the actual target — place_family failed for every family, even ones that exist.

Fix: use the existing get_element_name() helper (already used elsewhere in this file, e.g. list_families, for the same reason) instead of symbol.Name, and guard each symbol individually so one bad symbol is skipped instead of failing the whole lookup.

2. Accented family/type/level names never matched

Separately, even after fix #1, any family, type, or level name containing non-ASCII characters (e.g. level_name="Nível 1") still failed with "not found", while ASCII-only names worked fine.

Root cause: incoming JSON string values (family_name, type_name, level_name) arrive at the Routes handler as Python 2 str containing raw, undecoded UTF-8 bytes rather than unicode — e.g. "Nível" arrives as the 8 raw bytes that spell N\xc3\xadvel instead of the single-codepoint unicode string u"N\xedvel". ASCII bytes are valid UTF-8 already (hence why ASCII-only names were unaffected), but comparing this raw-byte string against Revit's own element names (always proper unicode from the API) never matches.

Confirmed via a temporary debug route dumping repr() and per-character codepoints of both the incoming value and the real Revit level name: the incoming value's codepoints were exactly the UTF-8 byte sequence of the intended text (195, 173 for "í") rather than its single Unicode codepoint (237) — an un-decoded byte string, not an encoding mismatch on the Revit side.

Fix: added fix_request_string() to utils.py, which decodes these fields as UTF-8 before they're used for lookups, and applied it to family_name, type_name, and level_name in place_family.

Test plan

• Reproduced both bugs on a real Revit 2026 project via the actual MCP → Routes → Revit round trip (not just in-process scripting).
• Bug 1: place_family with family_name="M_Coluna retangular" (ASCII, exists in model) returned 404 before the fix; succeeded after.
• Bug 2: place_family with level_name="Nível 1" (exists in model) returned 404 "Level not found" even after fix 1; succeeded after fix 2, placing and then removing a test column instance to confirm.
• list_families / list_levels were unaffected by either bug (they already used get_element_name() and don't do incoming-string comparisons the same way), so this doesn't change behavior elsewhere in the extension.

🤖 Generated with Claude Code