Hugh KaznowskiandClaude Sonnet 5
c77404ba4e
Adds a sessions/<name>.json registry (068) so a running ottyl instance can be discovered by name; an `ottyl mcp --session <name>` subcommand (067) that starts a short-lived MCP server over stdio (via the official rmcp SDK), proxying query_logs/declare_param/declare_metric/create_dashboard/ add_panel/get_dashboard tool calls onto the existing HTTP API; and a SKILL.md (069), embedded into the binary and served at GET /SKILL.md, that documents how an agent connects to and drives a running instance. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01A1ZJ3SrayzLzVndhVq9BmS
7 lines
868 B
Plaintext
7 lines
868 B
Plaintext
Ottyl should have an CLI json-rpc mcp functionality. It should allow agents to read or count logs matching queries, create parameters, create metrics, and create dashboards and panels in the dashboards. They should also be able to read dashboards as response data.
|
|
|
|
Ottyl CLI is aware of sessions, because each session will be stored in the settings location. Since the ottyl service knows it's binding, it can write there `{port}.json` files in say `sessions/` where the settings are. Then ottyl CLI can find sessions there by name and connect to them. Each session of ottyl is named, either via cli clap params, or randomly using the petnames crate.
|
|
|
|
There should be a SKILL.md file, accessible from ottyl (so embedded like the frontend is) which explains how to interact with ottyl instances for agents. It should be clear and direct without using too many words.
|
|
|