Related Servers

Most tools target a distinct resource+action, but several clusters blur together: get_gateways and get_services carry essentially identical descriptions, and get_task_metrics / get_task_metrics_for_task / get_task_metrics_for_workflow / get_task_metrics_for_app plus get_job_metrics / get_job_metrics_for_workflow and the several session-token-usage tools require close reading to pick correctly. start_workflow vs trigger_automation is documented as an intentional wrapper but still a likely misselection point, as are the parallel get_templates vs get_command_templates families.

The surface follows a mostly consistent snake_case verb_noun pattern (get_*, describe_*, create_*, update_*, run_*, add_*), with get_ for collections and describe_ for single detailed records used fairly predictably. Minor deviations exist where verbs and nouns shift across analogous tools (add_devices_to_group vs add_nodes_to_inventory vs add_golden_config_node, and get_services/list inconsistency in the gateway family).

At 79 tools this is far past a comfortable agent-facing surface, and the set spans ~10 distinct platform subsystems (Workflow Engine, Automation Studio, adapters/applications, gateway, devices/groups, inventories, compliance, golden config, Lifecycle Manager, agents/sessions). The breadth is real, but the pack is heavy enough that selection errors are likely and it should arguably be split into domain-scoped servers.

Read-heavy coverage is broad and metrics/session/compliance lifecycles are reasonably chained (run_compliance_plan -> get_compliance_reports_by_batch -> describe_compliance_report). However CRUD is lopsided: there is no create_workflow/update_workflow/delete_workflow, no delete for templates, device groups, golden config trees, or resources, and no job cancellation, so agents will hit dead ends on common lifecycle operations.