Repository navigation
MCP: manage types, field groups and fields — and find places by name #555
Description
What you're trying to do
Set up types and their fields through an MCP client while adding things — e.g. an assistant adds two dozen network devices and cameras, notices the types have no IP address field, and should be able to add it (and fill it) in the same session.
What gets in the way today
MCP can add and update things, but has no tool for the type registry. Types, field groups and fields can only be managed in the web app. The assistant has to stop, ask a person to customise a type and add a field by hand, and then guess the key that person chose — and update_thing answers only validation: Check custom. when it guesses wrong, without saying which keys the type has.
What you'd like
MCP tools for the account's type registry, behind the same permission as the web app (registries-types.manage) and a write-scoped token:
list_types/get_type: types and field groups with their fields (key, label, kind, repeatable, required, secret), the groups a type uses, built-in or own, and what a built-in was customised into.create_type,update_type(name, icon, parent, capabilities, field groups),customise_typefor a built-in.- Field groups: create an own group, customise the built-in one (see Field groups: extend the built-in Device group, and create your own groups #554), attach or detach a group on a type.
add_field,update_field(label, options, required, sort),archive_fieldon a type or a group.
And in the existing write tools: when custom is rejected, name the offending key and list the type's valid keys, so a client can correct itself without guessing.
Related: #546 (a customised type has no name, so it can't be found by name — a get_type by id avoids that), #554 (field groups).
Activity
strausmann commentedon Nov 13, 2026
Extending this to places, which have the same gap and block ordinary work today.
What happened: an assistant was asked to add printers, servers and smart plugs to named rooms ("Office", "Laundry room", "Kitchen", …). It could not, because no MCP tool returns a place's id:
search_thingsandwhere_isreturn things only.where_is("Office")answers things whose path contains "Office", with the path as text — never the place itself or its id.list_contentsneeds aplace_idto start from; there is no way to get the location's top-level places (the location id is rejected as a place).thing_historyshows "Moved X" without the target.add_thing/move_thingtakeplace_idonly (ornew_place, which creates one — a duplicate when the room exists).So placing anything means asking a person to open each room and paste its URL.
What would fix it:
list_places— the location's place tree (id, short code, name, kind, parent), paged, with adepthlikelist_contents; called without a parent it starts at the top.find_place(query)— places by name or code, with their full path, so "Office" or "UG › Office" resolves to one id (and reports ambiguity instead of guessing).search_things/where_ismay also return matching places (marked as places), or at least the place id behind each path segment.add_thing/move_thingaccept a place path ("UG/Office") and resolve it, refusing when it is ambiguous.Same reasoning as the type tools above: the registry and the place tree are what every write tool refers to by id, so an MCP client must be able to read them.
[-]MCP: manage types, field groups and fields[/-][+]MCP: manage types, field groups and fields — and find places by name[/+]