Inspect a running Flutter app: HTTP traffic, logs, exceptions and queries. Debug only.
Copy the AI prompt to install this server into Claude Code, Cursor, or another agent β or use 1-click editor setup below.
One-click editor setup isnβt available for this listing yet β we donβt have a confirmed install command, and weβd rather show nothing than point your editor at the wrong package or host. Follow the projectβs own setup instructions, linked above.
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.
Documentation Β· pub.dev Β· Issues
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 12 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. Debug-only; kDebugMode 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.
| Feature | Description | |
|---|---|---|
| π | 10 Watchers | LogWatcher, ExceptionWatcher, DumpWatcher, FramePerfWatcher, plus 6 Magic-specific adapters covering HTTP, models, cache, events, gates, and DB queries |
| π€ | 10 MCP Tools | telescope_requests, telescope_tail, telescope_exceptions, telescope_events, telescope_gates, telescope_dumps, telescope_queries, telescope_caches, telescope_frames, telescope_clear |
| π₯ | 10 CLI Commands | telescope:install, telescope:tail, telescope:requests, telescope:queries, telescope:caches, telescope:events, telescope:gates, telescope:dumps, telescope:frames, telescope:clear |
| π | Adapter Contract | TelescopeHttpAdapter (abstract, 3-method shape) for plugging any HTTP client; ships DioHttpAdapter for vanilla Dio |
| π | 10 Record Types | Immutable: HttpRequestRecord, LogRecordEntry, ExceptionRecord, MagicModelRecord, MagicCacheRecord, EventRecord, GateRecord, DumpRecord, QueryRecord, FramePerfRecord |
| π‘ | VM Service Extensions | 12 extensions: ext.telescope.requests, .console, .exceptions, .events, .gates, .dumps, .queries, .caches, .frames, .clear, .pause, .resume |
| β¨ | Magic Integration | MagicTelescopeIntegration.install() wires Http facade adapter + model/cache/event/gate watchers in one call (ships in the magic_devtools dev_dependency) |
| π | Debug-only Gate | Consumer wraps install inside if (kDebugMode); release builds tree-shake the entire telescope branch on all platforms |
| π | Idempotent Install | Every registerExtension call routes through registerExtensionIdempotent; hot-restart safe, no ArgumentError on re-registration |
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.
main.dartInstall Telescope before Magic.init() (or before runApp for plain Flutter). Wrap every install call in kDebugMode so the entire tooling branch is tree-shaken in release builds.
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 9 telescope_* MCP tools are visible to Claude Code and other MCP clients:
No reviews yet β be the first to share how this listing worked for you.
Showcase your server listing on GitHub or your project documentation. Embed this dynamic SVG badge to highlight official listing status and live engagement.
[](https://allmcps.com/mcp/fluttersdk-telescope)<a href="https://allmcps.com/mcp/fluttersdk-telescope"><img src="https://allmcps.com/api/badge/fluttersdk-telescope?style=directory" alt="FlutterSDK Telescope on AllMCPs" /></a>