
FlutterSDK Telescope
io.github.fluttersdkPublished by GitHub account fluttersdkv0.0.5Updated Oct 24, 2026
Inspect a running Flutter app: HTTP traffic, logs, exceptions and queries. Debug only.
Overview
Lets an AI coding agent read runtime telemetry from a running Flutter app — HTTP requests, logs, exceptions, DB queries, cache and events — via 10 telescope…
- What you can do
- Read HTTP request records with method, URL, status, duration and headers
- Read log output and debugPrint dumps, filtered by level, logger or limit
- Read uncaught exceptions with type, message and stack trace
- Read DB queries with SQL, bindings and timing, plus cache hit/miss/put/forget operations
- Read in-app events, Gate authorization checks and per-frame performance timings
- Clear all ring buffers between debugging iterations
- When to use it
- Useful when debugging a Flutter app with an AI coding agent and you want the agent to pull stack traces, failing HTTP responses and query timings itself instead of you copying them from the console. It is a development-only inspector, not a production monitoring tool.
- Requirements
- A local Flutter project with the fluttersdk_telescope package added and TelescopePlugin.install() wired in main.dart under a debug-mode guard. A running Flutter app is required, since all tools go through VM Service extensions. The MCP client is configured to launch the project's local artisan binary with the mcp:serve argument. No account, API key or network service is needed.
Installation
In SourceWeft
- Open FlutterSDK Telescope in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
Telescope
Passive runtime inspector for Flutter. Read by humans, queried by AI agents.
HTTP, logs, exceptions, debugPrint, DB queries, and Magic events captured over VM Service extensions, surfaced as telescope:* CLI commands and as 10 MCP tools for Claude Code.
[pub package] [CI] [License: MIT] [pub points] [GitHub stars]
Documentation · pub.dev · Issues
Why Telescope?
Stop pasting stack traces into Claude. Let your agent read them itself.
Debugging a running Flutter app has always required a mix of print statements, custom logging sinks, and network proxies that each tell a different slice of the story. When something breaks, you stitch together log files, Charles captures, and Flutter DevTools windows to reconstruct what happened. The AI workflow is worse: you copy the stack trace out of the console, paste it into Claude Code, copy the failing HTTP response, paste it back, repeat.
Telescope closes that loop. Passive watchers and 14 VM Service extensions register at startup. Every HTTP request, log line, exception, debugPrint call, DB query, and Magic-framework lifecycle event lands in a ring buffer. CLI commands (telescope:tail, telescope:requests) stream the buffers for humans; 10 MCP tools (telescope_requests, telescope_exceptions, telescope_tail, ...) expose the same buffers to AI coding agents like Claude Code, Cursor, and Codex. No copy-paste, no screenshots, no SaaS account. Development-only; a kDebugMode or !kReleaseMode guard at the call site tree-shakes the entire subsystem on release builds.
The install command scaffolds the consumer artisan harness if it is missing, runs plugin:install fluttersdk_telescope, and patches lib/main.dart so TelescopePlugin.install() runs before Magic.init() (or before runApp on vanilla Flutter). Everything is gated under kDebugMode; release builds tree-shake the entire subsystem.
After install, the consumer gets the artisan fast-cli at ./bin/fsa (native AOT, ~110ms warm startup) for every subsequent telescope command. dart run fluttersdk_telescope <cmd> keeps working as a slower (~3s cold) fallback.
Features
Quick Start
Option A (recommended): one-shot install
Add the dependency, then let telescope bootstrap itself via its own CLI entry point. No prior fluttersdk_artisan wiring is required; telescope's binary carries the artisan substrate so the install works from a fresh consumer:
The command scaffolds the consumer artisan harness if it's missing (bin/dispatcher.dart + lib/app/_plugins.g.dart), runs plugin:install fluttersdk_telescope, and patches lib/main.dart so TelescopePlugin.install() runs before Magic.init() (or before runApp on vanilla Flutter). Idempotent; safe to re-run.
For everyday repeat usage, the consumer's ./bin/fsa (artisan native AOT binary built during install) gives ~110ms warm startup:
dart run fluttersdk_telescope <cmd> remains a slower (~3s cold) fallback that always works without the AOT bundle.
Option B: manual wiring
1. Add the dependency
2. Install in main.dart
Install Telescope before Magic.init() (or before runApp for plain Flutter). Wrap every install call in a mode guard at the call site so the entire tooling branch is tree-shaken in release builds: kDebugMode, which is what telescope:install writes, or !kReleaseMode, which also keeps profile builds (what a performance measurement needs, and what magic_devtools uses).
3. Register the Artisan provider (MCP tools)
In the consumer's bin/dispatcher.dart (generated by dart run fluttersdk_artisan install), telescope is auto-discovered through lib/app/_plugins.g.dart after plugin:install fluttersdk_telescope. If you are wiring providers by hand, add FluttersdkTelescopeArtisanProvider() to the baseProviders list so the 10 telescope_* MCP tools are visible to Claude Code and other MCP clients:
Watchers
MCP Tools
Exposed via TelescopeArtisanProvider when the consumer registers it (auto-wired by telescope:install through lib/app/_plugins.g.dart + bin/dispatcher.dart). All tools route through ext.telescope.* VM Service extensions and require a running Flutter app.
CLI Commands
Registered via TelescopeArtisanProvider.commands(). After telescope:install you can invoke any command three ways: through the consumer's fast-cli (./bin/fsa <command>, recommended), through telescope's standalone bin (dart run fluttersdk_telescope <command>), or through the consumer dispatcher fallback (dart run fluttersdk_artisan <command>).
followCursor, the pure Dart loop behind both --follow flags, is exported from package:fluttersdk_telescope/cli.dart.
Examples
example/
Vanilla Flutter app (no Magic framework) that exercises every framework-agnostic capture surface: HTTP traffic via the Telescope Dio interceptor, log output via package:logging, uncaught exceptions via ExceptionWatcher, and debugPrint output via DumpWatcher. Demonstrates the minimal install pattern and the in-app overlay dashboard.
Architecture
Telescope is subsystem-first under lib/src/, every directory owns a single concern:
Boot flow:
Every concrete watcher and record type is a final class. The two adapter contracts (TelescopeWatcher, TelescopeHttpAdapter) are abstract class with frozen 3-method signatures (name, install, uninstall). Magic-side glue (MagicHttpFacadeAdapter, MagicModelWatcher, etc.) depends on these contracts; any signature change requires a coordinated bump across both repos.
Compared to
AI Agent Integration
Telescope is the first Flutter MCP server focused on runtime observability (HTTP, exceptions, queries, cache) rather than UI automation. The 10 telescope_* tools give Claude Code, Cursor, Codex, or any MCP-compatible agent direct read access to every runtime buffer: inspect HTTP traffic without a proxy, read logs without grepping output, catch exceptions without scrolling DevTools.
One-line .mcp.json install
telescope:install auto-writes .mcp.json for you. Or wire it manually for any MCP-compatible client:
After this, restart your MCP client. The 10 telescope_* tools (plus the substrate's artisan_* tools) surface automatically in /mcp.
Before / after
Typical agent session
For agents that read structured project context at attach time, the canonical entry point is llms.txt at the repo root (also published at https://fluttersdk.com/telescope/llms.txt). It enumerates the watcher surface, the VM extension catalog, and every MCP tool input schema in agent-readable form.
Documentation
Full docs with live examples at fluttersdk.com/telescope.
Contributing
The baseline is 497 tests green. New behavior ships with the matching test (red, green, refactor). dart format lib/ test/ bin/ must produce no diff and dart analyze must report zero issues across lib/, test/, and bin/.
Before opening a pull request, also run:
Report a bug · Request a feature
Inspiration
Telescope is inspired by Laravel Telescope, the elegant developer-tools assistant for Laravel that records every request, exception, log, query, cache hit, and event into a queryable timeline. The same pattern, ported to Flutter, with two additions that make sense for 2026: a CLI-first surface for terminal-native developers and a 10-tool MCP server so AI coding agents can read the timeline directly.
Part of the Magic SDK suite
Telescope is one of seven packages in the FlutterSDK Magic suite, a Laravel-inspired Flutter ecosystem:
- magic — Laravel-style framework (facades, ORM, providers, controllers, routing)
- wind — Tailwind-style className UI primitives for Flutter
- fluttersdk_artisan — Pure Dart CLI + MCP substrate that telescope extends
- fluttersdk_dusk — E2E gesture / snapshot driver via VM extensions
- fluttersdk_telescope (this package) — Runtime observability via VM extensions + MCP
- magic_tinker — Connected REPL into the running app
- magic_starter — Auth / profile / teams scaffolding
License
MIT, see LICENSE for details.
Built with care by FlutterSDK
If Telescope saves you debugging time, give it a star, it helps others discover it.
Source: README.md at commit 558dca5
Tools
0Version history
1- v0.0.5LatestSep 16, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts
