Merged
Conversation
* feat(SMI-1187): replace mcp-tail with CF Observability API for runtime logs Remove the mcp-tail worker and Analytics Engine pipeline, replacing it with direct queries to the CF Workers Observability Telemetry API. Enable `observability` metadata on WfP dispatch worker scripts so CF natively captures their logs. Web UI deferred to follow-up PR. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * chore: generated openapi.json for Stainless preview --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
Contributor
Author
|
🧪 Testing To try out this version of the SDK, run: Expires at: Fri, 27 Mar 2026 13:56:55 GMT |
…ponse (#1587) ## Summary The public API's `formatServerResponse()` was missing `eventTopics`, `resources`, and `prompts` fields. These capabilities are stored in the database and already rendered correctly in the web app (which uses direct DB queries), but were not exposed via the public registry API or Stainless SDK. This change adds these three nullable array fields to `ServerResponseSchema` and updates `formatServerResponse()` to include them. The fix is purely additive and backwards-compatible. ## Changes - **`apps/api/src/routes/servers/server-router.ts`**: Added `resources`, `prompts`, and `eventTopics` to `ServerResponseSchema` (Zod schema + OpenAPI) - **`apps/api/src/routes/servers/helpers.ts`**: Added the same three fields to `formatServerResponse()` return value, mapping only the necessary fields Both the list (`/servers/:namespace`) and detail (`/:namespace/:server`) endpoints call `formatServerResponse()`, so they both inherit the fix automatically. ## Test Plan - Pre-push checks passed (build and formatting) - No errors in the modified files from TypeScript compilation - Additive change with no breaking modifications to existing fields
stainless-app
bot
force-pushed
the
release-please--branches--main--changes--next--components--api
branch
from
9393a74 to
dcb5b00
Compare
…591) * feat(SMI-1187): add search param and lower default limit for runtime logs Add text search (needle) support to the logs API so agents can filter log messages server-side. Also reduce the default limit from 50 to 20 to keep agent context windows manageable. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> * chore: generated openapi.json for Stainless preview --------- Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com> Co-authored-by: github-actions[bot] <github-actions[bot]@users.noreply.github.com>
stainless-app
bot
force-pushed
the
release-please--branches--main--changes--next--components--api
branch
from
dcb5b00 to
19290a7
Compare
## Summary
- Add event polling to Connect API — when no webhook callback URL is provided, Connect automatically queues MCP server events for polling
- Events use queue semantics: polling atomically returns and deletes events (evict-on-poll)
- Add unlisted docs page for design partners covering both event polling and webhook callback modes
## How It Works
Connect's job is to translate stateful MCP servers into stateless APIs. Some MCP servers support WHHTTP (webhook HTTP), which allows them to send server-to-client messages — notifications, log messages, sampling requests — via HTTP POST to a callback URL.
Connect always offers the WHHTTP extension during initialization. Most servers (especially those hosted outside Smithery) are plain Streamable HTTP servers and simply ignore it. Servers that accept WHHTTP will POST events to the callback URL Connect provides.
When a server does support WHHTTP, events are delivered through one of two modes:
1. **Event polling** (default) — no webhook URL provided → Connect generates an internal ingest URL, queues events, and the client polls `GET /:connectionId/events` to consume them
2. **Webhook callback** — `unstableCallbackUrl` provided → events are forwarded directly to the client's URL
For servers that don't support WHHTTP, there are no server-to-client events — the events endpoint will always return `{ data: [], done: true }`.
### Evict-on-poll
Polling uses queue semantics — each `GET` atomically returns and deletes events via `DELETE ... RETURNING`. No separate acknowledge endpoint, no iterators. Simple request/response:
```json
GET /connect/:ns/:connId/events?limit=100
{ "data": [{ "id": 1, "payload": {...}, "createdAt": "..." }], "done": true }
```
When `done` is `true`, the queue is empty — back off and retry later.
### Per-connection cap
Each connection stores up to 1,000 events. When the cap is reached, oldest events are evicted (FIFO) on ingest to make room. This prevents unbounded growth without requiring client-side management.
## Files Changed
### New
- **`packages/db-ps/src/schema/connect-events.ts`** — `connect_events` table (bigserial id, namespace_id, connection_id, jsonb payload, timestamp). Composite FK to `connect_connections` with CASCADE delete. Index on `(namespace_id, connection_id, id)`.
- **`apps/connect/src/routes/events.ts`** — Ingest endpoint (POST, called by MCP servers via WHHTTP) and poll endpoint (GET, called by clients).
- **`apps/docs/use/connect-events.mdx`** — Unlisted docs page covering both event polling and webhook callback modes with code examples and sequence diagrams.
- **`packages/db-ps/src/migrations/0032_luxuriant_timeslip.sql`** — Migration for `connect_events` table.
### Modified
- **`apps/connect/src/routes/connections.ts`** — When no `unstableCallbackUrl` is provided, auto-generates an internal ingest URL so WHHTTP is always offered to the MCP server.
- **`apps/connect/src/schemas.ts`** — Added `EventSchema`, `EventsPollQuerySchema`, `EventsPollResponseSchema`.
- **`packages/db-ps/src/schema/index.ts`** — Export new table.
## Test plan
- [ ] Create connection without `unstableCallbackUrl` → verify internal webhook URL is generated and WHHTTP is offered
- [ ] Create connection with `unstableCallbackUrl` → verify webhook mode works as before
- [ ] POST JSON-RPC message to ingest endpoint → verify 202 and event is stored
- [ ] POST events up to cap (1,000) → verify oldest events are evicted on overflow
- [ ] GET events → verify events returned and deleted atomically
- [ ] GET events when empty → verify `{ data: [], done: true }`
- [ ] Delete connection → verify events cascade-deleted via FK
- [ ] Run migration: `pnpm db:migrate` in `packages/db-ps`
🤖 Generated with [Claude Code](https://claude.com/claude-code)
stainless-app
bot
force-pushed
the
release-please--branches--main--changes--next--components--api
branch
from
19290a7 to
96f3883
Compare
calclavia
deleted the
release-please--branches--main--changes--next--components--api
branch
Contributor
Author
|
🤖 Release is at https://github.com/smithery-ai/typescript-api/releases/tag/v0.52.0 🌻 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Automated Release PR
0.52.0 (2026-02-25)
Full Changelog: v0.51.0...v0.52.0
Features
This pull request is managed by Stainless's GitHub App.
The semver version number is based on included commit messages. Alternatively, you can manually set the version number in the title of this pull request.
For a better experience, it is recommended to use either rebase-merge or squash-merge when merging this pull request.
🔗 Stainless website
📚 Read the docs
🙋 Reach out for help or questions