Firebase MCP Server: Crashlytics-tools, Auth en Veilige Configuratie

Wat de Firebase Crashlytics MCP server is

Eerst de scoping, omdat de zoekterm breder is dan het product. Een Firebase MCP server zou voor elke Firebase-dienst kunnen staan. De server die TrueFoundry documenteert dekt Crashlytics. Als uw agent Firestore-documenten of Remote Config-waarden nodig heeft, is dit niet de juiste oplossing.

Model Context Protocol is de open standaard waarmee een agent tools op een extern systeem kan ontdekken en aanroepen, en een Crashlytics MCP server verandert uw crash-dataset in aanroepbare tools. Volgens de documentatie kunnen agents crash-issues, stack traces, crash-gebeurtenissen en rapporten inspecteren.

De documentatie beschrijft mogelijkheden per IAM-rol in plaats van tool-functies bij naam te noemen, dus bekijk de mogelijkheden per rol:

Die derde rij vormt de gehele beveiligingsbeslissing. De documentatie is expliciet: gebruik Viewer-rollen, tenzij agents de status van issues moeten wijzigen. Voor triage en rapportage is de gebruikersrol nooit nodig, en het toch verlenen ervan is hoe een agent een live P0 sluit omdat een prompt zei dat het de boel moest opruimen.

Het draait als een remote of hosted server, dus er is geen proces per laptop om te beheren — dezelfde vorm als andere remote MCP servers, met één verschil: de referentie is een service account-sleutel, geen OAuth-machtiging per gebruiker.

Wat agents er werkelijk mee doen

De interessante workflows koppelen meerdere leesacties aan elkaar en eindigen in een geschreven artefact.

• Crash triage en concepten voor foutrapporten opstellen. Haal de belangrijkste issues op op basis van volume, lees de stack trace van de ergste, neem steekproeven van crash-gebeurtenissen voor de apparaat- en besturingssysteemdistributie, en stel vervolgens een rapport op met de trace, de build-reeks en de getroffen populatie. De belangrijkste toepassing.
• Identificatie van het regressievenster. Het aantal crashes piekt na een release. De agent vergelijkt de aantallen per app-versie, vindt de eerste build waarin de handtekening verschijnt, en geeft u een venster van twee builds om te halveren.
• Release gate-controles. Voordat u een gefaseerde uitrol bevordert, leest u het crashvrije percentage en de belangrijkste nieuwe issues voor die cohort, waarbij alles wordt gemarkeerd dat afwezig was in de vorige build.
• Correlatie tussen verschillende systemen. Lees een stack trace en gebruik vervolgens een afzonderlijke server om in de repo naar het betreffende symbool te zoeken en een issue te openen. Crashlytics blijft alleen-lezen.

De verdeling ziet er hier ongebruikelijk uit: met Viewer-rollen is bijna alles een leesactie, wat veilig klinkt. Maar alleen-lezen is niet schadeloos. Eén crash-gebeurtenis kan een apparaat-ID, een momentopname van de app-status, een gebruikers-ID en aangepaste log-breadcrumbs bevatten die uw engineers hebben toegevoegd — en breadcrumbs zijn de plek waar persoonlijke gegevens lekken, omdat degene die ze schreef aan het debuggen was, niet bezig was met het schrijven van een databeleid. Het ophalen van honderd crash-gebeurtenissen in de context van een model is een beslissing over dataverplaatsing, niet zomaar een query.

Waarom een rechtstreekse verbinding op teamschaal misgaat

Eén engineer die dit uitvoert tegen een dev-project is prima. Het aansluiten op een gedeelde agent voor een mobiel team is dat niet.

De service account-sleutel is een gedeeld wachtwoord. De documentatie zegt dat u deze als zodanig moet behandelen. Het is een langdurig, niet-roterend bestand dat alle rollen verleent die u hebt gekoppeld aan iedereen die het bezit. Het verloopt niet en het vertelt u niet wie het heeft gebruikt.

Gedeelde referenties maken identiteit plat. Met één service account in plaats van OAuth per gebruiker krijgt elke aanroeper identieke toegang en ziet het bovenliggende auditlogboek één principal. Het kan u niet vertellen dat de release-agent die aanroep heeft gedaan voor een specifieke engineer. Die toewijzing komt van de gateway of helemaal niet.

Te brede rollen zijn het standaardpad. Het toevoegen van firebasecrashlytics.user "voor het geval dat" kost één klik en vergroot de impactradius permanent.

Crash-payloads zijn een pad voor data-exfiltratie. Er wordt niets geschreven, dus het voelt als een laag risico — dat is de valstrik. Elk antwoord van een tool stroomt in de context van een model, vervolgens in logs, traces en alles wat de agent hierna schrijft. Als breadcrumbs e-mailadressen of gebruikersidentificaties bevatten, verplaatst een niet-geredigeerde pipeline die gegevens naar een plek die niemand heeft beoordeeld. De controle die u wilt, is redactie bij de uitgang.

Niets hiervan is een argument tegen het verbinden van Crashlytics. Het is een argument voor een controle-element erin te plaatsen, en dat is wat een MCP gateway is.

Wilt u het uitproberen op uw eigen crashgegevens?

Maak een TrueFoundry-account aan, registreer uw Crashlytics MCP server en stel deze in als alleen-lezen.

Gratis aan de slag

De Firebase Crashlytics MCP server verbinden via TrueFoundry

Crashlytics staat niet in de TrueFoundry Managed MCP-catalogus. Geen tegel om op te klikken, geen door het platform beheerde referentie. Volgens de documentatie implementeert u het zelf en registreert u het.

Stap 1 — Maak de service account aan. Selecteer in de Google Cloud Console het project dat uw Firebase-project ondersteunt en maak een service account aan met de naam crashlytics-mcp. Verleen roles/firebase.viewer en roles/firebasecrashlytics.viewer, en voeg roles/firebasecrashlytics.user alleen toe als uw tools de status van issues moeten bijwerken. Maak een JSON-sleutel aan en sla deze veilig op.

Stap 2 — Implementeer de server. Voer het uit als een remote service of hosted stdio-server, waarbij de service account-JSON en het Firebase-project-ID worden geleverd als omgevingsvariabelen of door secrets ondersteunde configuratie.

Stap 3 — Registreer de server. Ga naar MCP Gateway en klik op Add Server. Omdat dit uw eigen implementatie is, kiest u Connect any Remote MCP Server of Create a Hosted STDIO-based MCP Server.

Het remote pad vraagt om een Name, een optionele Display Name, een Description, de server-URL, Collaborators en Auth Data.

Stap 4 — Voeg medewerkers toe en verifieer. Voeg de gebruikers en teams toe die de server moeten kunnen bereiken, controleer of tools verschijnen onder Tools en probeer er vervolgens een uit vanuit de Playground.

Hoe authenticatie werkelijk werkt

TrueFoundry maakt onderscheid tussen inkomende authenticatie (hoe een client zich bewijst aan de gateway) en uitgaande authenticatie (hoe de gateway zich bewijst aan uw server).

Inkomend — vier ondersteunde methoden:

Uitgaand — hier verschilt Crashlytics van op OAuth gebaseerde servers. De documentatie beschrijft service-account-referenties, geen toestemmingsstroom. Kies het authenticatietype dat overeenkomt met hoe uw server de referentie verwacht: TrueFoundry ondersteunt API Key, OAuth2, AWS SigV4 en Token Passthrough, en API Key biedt twee referentiemodi.

Shared Credentials betekent één sleutel voor iedereen — de natuurlijke pasvorm voor een service account, en de reden waarom inkomende identiteit belangrijk is. Elke aanroeper bereikt Crashlytics als dezelfde Google Cloud principal, dus het verzoekenlogboek van de gateway is de enige plek waar toewijzing per gebruiker bestaat. Met Individual Credentials kan elke gebruiker zijn eigen sleutel opgeven via het tabblad Auth Overrides, handig als u service accounts per team uitgeeft.

Virtual Account-tokens geven elk verzoek identieke toegang, dus ze kunnen geen scheiding per gebruiker bieden. En zonder toestemmingsstap wordt de toegang volledig bepaald door uw medewerkerslijst en welke tools u ingeschakeld hebt gelaten.

Als u uw implementatie in plaats daarvan voorziet van OAuth2 Authorization Code, gebruiken zelf-geregistreerde servers een andere callback dan beheerde servers. Stel de redirect URI in het portaal van uw provider in op https://<tfy-control-plane-base-url>/api/svc/v1/llm-gateway/mcp-servers/oauth2/callback. De auth.truefoundry.com callback geldt alleen voor TrueFoundry Managed MCPs, wat dit niet is.

Scoping van tools voordat u distribueert

Het tabblad Tools toont alles wat je server beschikbaar stelt en is de plek waar je bepaalt wat agents kunnen doen.

Schakelaars per tool. Schakel een tool uit en deze wordt volledig weggelaten uit tools/list — clients zien de tool nooit en deze kan niet worden aangeroepen. Dit is geen filtering op prompt-niveau. Voor Crashlytics is het patroon een dubbele beveiliging: Viewer-only rollen in Google Cloud en tools die issues aanpassen uitgeschakeld op de gateway. Zo geeft een verkeerd geconfigureerde IAM-binding een agent niet stilzwijgend schrijfbedrijf.

Enable new tools by default. Als dit is ingeschakeld, verschijnen tools die je server later toevoegt automatisch. Als dit is uitgeschakeld, zijn alleen tools beschikbaar die je expliciet hebt ingeschakeld — de verstandige standaardinstelling voor een server waaraan je blijft werken.

Bulk Action. Verandert rijen in selectievakjes met Select all, zodat je een hele reeks in één keer kunt aanpassen en opslaan.

Klik op het potloodje bij een tool om de weergave voor het model te overschrijven:

De overschrijving van de Description (tot 20.000 tekens) stuurt de toolselectie wanneer de eigen formulering van je server beknopt is, wat bij een zelfgebouwde server vaak het geval is. MCP Tool Annotations markeren een tool als Read-only of Destructive, waarmee readOnlyHint of destructiveHint wordt ingesteld. Het markeren van tools die de status van een issue wijzigen als Destructive zorgt ervoor dat het onderstaande goedkeuringsbeleid werkt.

Wie kan wat doen: rollen van medewerkers

Toegangsbeheer is gekoppeld aan gebruikers, teams of virtuele accounts op twee dimensies: welke servers een identiteit kan bereiken en welke tools deze kan aanroepen.

Met gedeelde inloggegevens upstream is de lijst met medewerkers je werkelijke toegangsgrens — iedereen op de lijst bereikt Crashlytics met de volledige rechten van het service-account. Beperk dit tot mensen die crash-payloads moeten kunnen lezen. Hetzelfde MCP access control-model als voor elke andere server in je register.

Klaar om de scope van je eerste server te bepalen?

Registreer de server, houd deze alleen-lezen en geef je mobiele team vandaag nog een triage-agent.

Start gratis op TrueFoundry

Menselijke goedkeuring voor destructieve tools

Als je firebasecrashlytics.user hebt toegewezen omdat een agent opgeloste issues moet kunnen sluiten, laat deze dan niet onbeheerd achter. Goedkeuringsbeleid houdt de aanroep aan in plaats van deze uit te voeren, maakt een verzoek aan en informeert goedkeurders. Zodra een aanroep is goedgekeurd, slagen overeenkomende aanroepen gedurende een instelbare periode, waarna een nieuwe goedkeuring vereist is.

Maak er een aan onder AI Gateway → Policies → MCP Tool Approval (gemarkeerd als Beta in de console):

Elk beleid vermeldt de servers die het beveiligt en kiest een approval scope:

Wanneer scopes elkaar overlappen, wint de meest specifieke: named > destructive > all. Validity is Once of op tijd gebaseerd in minuten. Wanneer regels conflicteren, geldt de meest restrictieve — Once wint van 10 minuten, wat weer wint van 30 minuten. Goedkeurders ontvangen meldingen via e-mail, Slack, PagerDuty of MS Teams:

Elk verzoek toont de tool-argumenten, zodat een goedkeurder ziet welk issue een agent wil aanpassen. Zolang het verzoek in behandeling is, ontvangt de aanroeper een JSON-RPC-resultaat met _meta.approval_status: "pending" in plaats van een foutmelding, zodat een goed geprogrammeerde agent het opnieuw kan proberen. Toewijzingen worden per aanvrager afgebakend. Een afwijzing blokkeert iemand niet permanent — om duurzaam te blokkeren, schakel je de tool uit of verwijder je de gebruiker.

Testen in de Playground

Test eerst handmatig. Klik op de detailpagina van de server op Try naast een tool, vul de parameters in, voer de actie uit en lees de JSON. Try is uitgeschakeld voor tools die je hebt uitgeschakeld.

Dit is de plek waar je ontdekt dat het service-account een rol mist of dat de project-ID nooit is ingesteld — én het moment om een ruwe crash-event-respons te lezen en te zien wat er in de breadcrumbs staat voordat je beslist hoeveel anonimisering nodig is.

Gebruik vanuit je IDE

Open het tabblad How To Use voor je tenant-specifieke Gateway-URL en kant-en-klare codefragmenten.

Het ondersteunt Claude Code, VS Code, Cursor, Windsurf, Codex en de Python en TypeScript MCP SDK's. Gebruik de URL van dit tabblad in plaats van deze handmatig samen te stellen — een handmatig gebouwd eindpunt is de meest voorkomende oorzaak van een client die wel verbindt, maar geen tools toont.

Wat je krijgt als het eenmaal achter de gateway staat

PII-anonimisering op tool-output. De beveiliging die hier het meest toedoet. TrueFoundry's ingebouwde PII/PHI Detection guardrail is van toepassing op vier hooks: LLM Input, LLM Output, MCP Pre Tool en MCP Post Tool. Post Tool is degene die je nodig hebt — het anonimiseert gedetecteerde entiteiten uit de tool-output voordat deze het model bereikt.

Het wordt aangedreven door Azure AI Language PII Detection, draait op door TrueFoundry beheerde infrastructuur zonder sleutels van derden en werkt alleen in mutate-modus — gedetecteerde entiteiten worden vervangen door astersikes en het verzoek gaat gewoon door. Kies de entiteitscategorieën of selecteer ze allemaal, en kies enforce of enforce_but_ignore_on_error. Configureer dit onder Guardrails.

Voor een crash-triage-agent verandert dit een ongecontroleerd datapad in een gecontroleerd pad: de agent krijgt nog steeds de stack trace en apparaatvertekening die nodig zijn, terwijl identificatiegegevens die in breadcrumbs zijn beland, onderweg worden gemaskerd.

Statistieken op tool-niveau. Het MCP Metrics-dashboard geeft een overzicht van verzoeken per seconde, latentie van P50 tot P99, het foutpercentage per fouttype en het aantal verzoeken per tool.

Dit is hoe je erachter komt dat een triage-agent tweeduizend crash-events per run ophaalt, terwijl vijftig voldoende zou zijn.

Observability over het gehele verzoek. Elke aanroep wordt getracet met identiteit van de aanroeper, toolnaam, invoerwaarden en latentie, en geëxporteerd via OpenTelemetry naar Grafana, Datadog of Prometheus. Met een gedeeld service-account upstream zijn deze traces de plek waar toewijzing per gebruiker plaatsvindt.

Lage overhead. De gateway voegt ongeveer 3–4 ms latentie toe en verwerkt 350+ RPS op een enkele vCPU.

Eén register. Triage stopt zelden bij Crashlytics. Bundel tools van meerdere servers achter één eindpunt met een Virtual MCP Server, zodat een triage-agent alleen-lezen toegang krijgt tot Crashlytics én tot de repository-tools die nodig zijn.

Toegang intrekken

Twee paden, niet uitwisselbaar.

Bij Google Cloud. De documentatie is er duidelijk over dat dit de definitieve methode is: verwijder de sleutel van het service-account in de Google Cloud Console. Dit is het authenticatiemiddel, dus het verwijderen ervan stopt alle toegang.

Bij de gateway. Tenant-beheerders kunnen opgeslagen inloggegevens wissen via het menu met de drie puntjes naast Edit:

Revoke all tokens verwijdert alle authenticatie-overschrijvingen en opgeslagen tokens voor alle gebruikers en virtuele accounts op die server. Dit wordt direct van kracht bij het volgende verzoek, wordt vastgelegd in Activity Logs en is onomkeerbaar. Alleen voor tenant-beheerders. Dit wist inloggegevens alleen bij de gateway — er verandert niets in Google Cloud, dus verwijder bij een incident ook de sleutel.

Belangrijke aandachtspunten

Het is Crashlytics, geen Firebase. Waardevol om te herhalen omdat de zoekterm misleidend is: geen Firestore, Auth, Remote Config of Hosting.

Je bent zelf eigenaar van de deployment. In tegenstelling tot catalogus-servers werkt niemand deze voor je bij — wanneer de upstream API verandert, werkt je service niet meer.

Alleen-lezen verplaatst nog steeds data. Viewer-rollen zijn niet het eindpunt van de beveiligingsdiscussie. Ze beperken wat een agent kan wijzigen, niet wat deze kan lezen en doorsturen.

Gerelateerde artikelen

• What Is an MCP Gateway: Architecture and Use Cases — de architectonische introductie
• MCP Access Control: Securing AI Agents with an MCP Gateway — machtigingen op tool- en serverniveau
• MCP Server Security Best Practices — de check-list voor beveiliging
• Virtual MCP Server Explained — tools bundelen in één eindpunt
• MCP Authentication — inkomende en uitgaande authenticatie in detail

Conclusie

Crash-triage is typisch werk dat agents zouden moeten doen. Een cluster analyseren, een stack trace koppelen aan een apparaatvertekening, de build vinden waar een patroon voor het eerst optrad, dit rapporteren — saai werk, en precies wat een model met de juiste tools goed kan.

De Crashlytics MCP-server maakt dat mogelijk, met twee kanttekeningen waar de documentatie eerlijk over is. De inloggegevens bestaan uit een gedeelde sleutel van een service-account, dus identiteit en toeschrijving moeten van de gateway komen. En alleen-lezen betekent niet risicovrij: crash-payloads bevatten apparaatidentificaties, app-status, gebruiker-ID's en breadcrumbs die zijn geschreven zonder rekening te houden met AI-pipelines. Viewer-rollen, scopen per tool en anonimisering na de tool-aanroep zorgen voor de triage-agent, zonder de wildgroei aan data.

Verbind je Crashlytics MCP-server op TrueFoundry

Gratis om te starten