pick.tools

Roadmap

What comes after v1, in order. No dates are promised.

After v1

  1. v1.1 Observatory. A daily probe of every remote server in the official MCP registry, beyond the catalog; a /registry page to search that long tail; a daily CC BY 4.0 snapshot with raw rows.
  2. pick.tools API keys. Keys with no rate limit and a per-key activity page; client_id becomes verified. Keys are the identity that vendor tokens are later bound to.
  3. OAuth broker. URL-mode elicitation, encrypted token storage bound to a key, and refresh jobs, so OAuth servers can be relayed. It requires registering pick.tools as an OAuth client with each vendor.
  4. Vendor claiming. Vendors who verify their domain edit their metadata, see per-tool error diagnostics and add a status badge.
  5. ClickHouse for raw events, when Postgres rollups hurt or arbitrary slicing is wanted. Call events are never changed once written, so a backfill is simple.
  6. A docs repository of its own, published on GitHub Pages. These pages move there unchanged.
  7. Open-sourcing the app. The code is written to be publishable; the decision is the maintainer's.

Not planned for v1

  • user accounts, pick.tools API keys, OAuth brokering and stored credentials
  • plain REST or OpenAPI services without a remote MCP server
  • a second datastore
  • vendor self-service: claiming a page, editing metadata
  • streaming tool results (SSE) through the relay, subscriptions/listen, and server-to-client requests such as sampling and elicitation
  • running TypeScript connector catalogs