Return the platform-wide component definitions that describe what each component type looks like: filePath, and a "data" block with modelName, itemType, componentAlias, isDefaultMonitored, nameProperty, the field "schema" (which property names a component of that type carries, and their types), and componentManagement. Use this when you need to know what fields a component type has or how it is defined — for instance to interpret an unfamiliar component. Its "schema" is the INVENTORY schema and carries no metric property names, so do NOT use it to find values for a metric tool's "properties" argument: a live contract run on 2026-07-30 grepped the whole payload and found zero occurrences of any metric type group. Use lumics_get_metric_summary for that instead (spec section 12.5 M6). This endpoint IS the source for a metric itemType, which is built as the filePath module/group path plus "data.itemType" joined by "_" — for example /components/snmp/common/Cpu.yml with itemType "cpu" gives "snmp_common_cpu". This is Lumics platform metadata, not tenant data: it is the same for every company, describes every type the product supports rather than the types this tenant uses, and takes no company id. It is also large, and it accepts no limit — if you only need a valid component type key for this tenant, call lumics_list_component_types instead, which is much smaller. Pass "fields" (e.g. ["filePath"]) to keep the response manageable.

Return the Lumics user this server authenticates as, together with the company that user belongs to — the company id, name, IANA timezone and active flag. This is the tool that bootstraps the rest of the server: LUMICS_COMPANY_ID is optional, and when the operator has not set it the company-scoped tools (devices, collectors, components, IPAM, company metrics) are not registered at all, so this may be almost the only tool you can see. In that state, call this tool, then tell the operator to set LUMICS_COMPANY_ID to the "company.id" value it returns and restart the server — passing the id as a companyId argument will not help, because those tools are absent rather than failing. It is also the cheapest way to check that the configured credential works at all. Takes no arguments and changes nothing.