Problem
External orchestration layers need to discover what a PicoClaw node can do before they can route work to it intelligently.
Right now, integrations typically have to hardcode assumptions such as:
- which profile/agent ids exist
- what tools or skill families are available
- which workspace or host the node represents
- which model/provider family it is using
- whether it is appropriate for code, research, review, automation, browser, or other task classes
That makes orchestration brittle and forces every downstream integration to invent its own side-channel configuration.
Why this matters
For Paperclip or any agent-control-plane app, discovery is what turns a remote agent from an opaque endpoint into a schedulable worker.
A control plane should be able to ask a PicoClaw node questions like:
- Which public profiles/agents are available on this node?
- What are their stable ids and human-readable names?
- What capabilities should each one advertise?
- What execution surfaces are enabled (skills, exec, mcp, browser, subagents, etc.)?
- What workspace or host scope does this node represent?
- Which model/provider family is backing this profile?
Without a native discovery endpoint, orchestration layers either guess or maintain duplicate config that drifts from the actual runtime.
Request
Please expose a machine-readable capability discovery and profile enumeration API for PicoClaw nodes intended to be orchestrated externally.
This could be included in a gateway protocol implementation or a simple documented inspection endpoint set. The important part is that the contract is stable and designed for external schedulers/orchestrators.
Desired response data
A useful minimum contract would include:
- node-level identity
- node id
- hostname / instance label
- version / protocol version
- available profiles/agents
- stable id
- display name
- default/public/private status if relevant
- advertised capabilities per profile
- code
- research
- review
- documentation
- automation
- browser
- mcp
- custom labels
- execution/runtime metadata
- enabled tool families
- workspace restriction model
- supported transport/protocol features
- model/provider family metadata (high level, not secrets)
Why this should be native
If discovery is not native, every integration ends up maintaining shadow config outside PicoClaw. That causes:
- routing mistakes
- stale assumptions after deploys
- harder onboarding for orchestration tools
- more glue code per integration
Native discovery would make PicoClaw much easier to plug into orchestration ecosystems.
Acceptance criteria
This feature would be integration-ready if an external orchestrator can:
- discover a PicoClaw node and list available profiles/agents
- determine which profile is appropriate for a task class
- detect capability changes after upgrade or config change
- identify enough runtime metadata to route work safely
- do all of this without shell access or out-of-band configuration files
Concrete use cases
- Paperclip choosing between multiple PicoClaw worker profiles
- local/LAN control planes routing code vs research vs personal-assistant tasks
- fleet dashboards that inventory PicoClaw nodes and their capabilities
- external schedulers validating whether a node supports browser, MCP, or restricted exec before assignment
Related context
This is a follow-on to #1462. Once PicoClaw is reachable as an orchestration target, native discovery is one of the biggest improvements for making real integrations robust instead of hardcoded.
Problem
External orchestration layers need to discover what a PicoClaw node can do before they can route work to it intelligently.
Right now, integrations typically have to hardcode assumptions such as:
That makes orchestration brittle and forces every downstream integration to invent its own side-channel configuration.
Why this matters
For Paperclip or any agent-control-plane app, discovery is what turns a remote agent from an opaque endpoint into a schedulable worker.
A control plane should be able to ask a PicoClaw node questions like:
Without a native discovery endpoint, orchestration layers either guess or maintain duplicate config that drifts from the actual runtime.
Request
Please expose a machine-readable capability discovery and profile enumeration API for PicoClaw nodes intended to be orchestrated externally.
This could be included in a gateway protocol implementation or a simple documented inspection endpoint set. The important part is that the contract is stable and designed for external schedulers/orchestrators.
Desired response data
A useful minimum contract would include:
Why this should be native
If discovery is not native, every integration ends up maintaining shadow config outside PicoClaw. That causes:
Native discovery would make PicoClaw much easier to plug into orchestration ecosystems.
Acceptance criteria
This feature would be integration-ready if an external orchestrator can:
Concrete use cases
Related context
This is a follow-on to #1462. Once PicoClaw is reachable as an orchestration target, native discovery is one of the biggest improvements for making real integrations robust instead of hardcoded.