feat(mcp): expose scheduling admin tools

[owezzy]

Summary

• add MCP scheduling tool contracts and HTTP route/client support for distributed model scheduling
• register list/get/set/delete scheduling tools with validation, dispatch tests, and REST route coverage
• document scheduling tools in assistant prompts, including safety guidance and a dedicated distributed scheduling skill

Related issue

• Closes Distributed routing: minor tuning + MCP scheduling parity follow-ups #10070

Testing

• make protogen-go
• go test ./pkg/mcp/localaitools/...
• GIT_MASTER=1 git diff --check

[localai-org-maint-bot]

There are two blocking issues on the current head:

1. The in-process LocalAI Assistant cannot use the feature this PR advertises. ListScheduling always returns an empty slice and GetScheduling / SetScheduling / DeleteScheduling always return “only available in distributed mode” (pkg/mcp/localaitools/inproc/client.go). That client is exactly what the assistant initializes in Application.start; it is still used on the distributed head. Please plumb the distributed NodeRegistry into the in-process client and implement these operations directly against it, with nil/single-node behavior kept explicit. This is required by the REST↔inproc↔HTTP parity contract in .agents/localai-assistant-mcp.md.

2. ModelSchedulingConfig is a direct alias of nodes.ModelSchedulingConfig. That exposes persistence-only state such as the database ID and reconciler cooldown through the public MCP DTO, and imports the service model into the MCP contract. Please define an explicit JSON DTO and conversion helpers instead; the local assistant guide specifically requires DTOs here and says not to expose raw service types.

The HTTP route/client work, tool registration, safety prompt, and validation direction otherwise look sensible. DCO is also currently failing because none of the six commits has the human contributor's Signed-off-by; please add your own sign-off when rewriting the commits.

[localai-org-maint-bot]

The in-process NodeRegistry plumbing and direct registry operations address the first blocker, and DCO is now green. The DTO boundary is still incomplete, though: ModelSchedulingConfig remains a field-for-field copy of the persistence model and SchedulingConfigFromNode still publishes ID, UnsatisfiableUntil, UnsatisfiableTicks, CreatedAt, and UpdatedAt. Those are the database/reconciler fields called out in the prior review; changing an alias into a struct does not stop them from leaking through the MCP contract.

Please keep only the operator-facing scheduling fields in the MCP DTO (model_name, selector/replica/spread settings, and routing thresholds) and omit the persistence/cooldown fields from the conversion. The HTTP client can decode the REST response into that narrower DTO while ignoring extra REST fields.

I also ran git diff --check successfully. The targeted go test ./pkg/mcp/localaitools/... remains blocked before these packages compile by the existing missing generated pb.DetokenizeRequest / pb.DetokenizeResponse symbols.

[localai-org-maint-bot]

The current head resolves both prior blockers: the in-process assistant now operates directly on the distributed NodeRegistry, and the explicit MCP DTO exposes only operator-facing scheduling fields. The new in-process and HTTP tests cover the scheduling paths and ensure persistence/cooldown fields do not leak.\n\nVerified at 2f9792cd: go test ./pkg/mcp/localaitools/... passes after regenerating the protobuf bindings, git diff --check passes, and the changed Go files are gofmt-clean.\n\n@mudler this is good to merge.