floot

Get Logs

get_logs

Read-only

Your FIRST step when debugging any runtime problem — a 500, a failed request, a blank page, or 'it doesn't work' from the user. Call this before theorizing from an error message alone. Reads the project's runtime logs. source 'server' (default): the dev backend's request logs from the last hour — method, URL, status, duration, and per-request server log lines (pass log_reference_id from a previous listing for one request's full logs); includes background jobs (queueTask/scheduled/failure). source 'browser': console output AND client-side network requests (each fetch as ⇄ METHOD url → status, with the error body for failed/4xx/5xx ones — the client-side view server logs miss, e.g. CORS/timeouts/third-party calls) captured from the user's open editor session. A browser network line's ref=<id> is a log_reference_id you can pass back with source 'server' for that request's full server logs. Empty if no editor is open. source 'background': not log lines but the live state of background work, for the preview AND the published app — the schedules actually deployed (scheduled jobs, recurring and delayed queueTask) with their next run, the runs in progress right now, and the runs that were long or cut off at the 15-minute limit in the last 7 days. Use it to answer 'is that job still running?', 'did it time out?' and 'can anything start it again?' (limit and log_reference_id are ignored). Sources 'server' and 'browser' are NOT CloudWatch: entries live ~1 hour and cover the dev backend + live session only — for the PUBLISHED app's logs, use run_code_in_vm's _floot.getProdBackendLogs (details: get_guides('prod-backend-logs')).

Input Schema

Name	Required	Description	Default
`limit`	No
`source`	No
`projectId`	Yes
`log_reference_id`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 11, 2026

changedInput schema / properties / source / enum

Previous value: -[
-  "server",
-  "browser"
-]New value: +[
+  "server",
+  "browser",
+  "background"
+]

First observedAug 27, 2026

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnly/non-destructive; the description adds that entries live ~1 hour, cover only the dev backend and live session, are empty if no editor is open, that limit/log_reference_id are ignored for 'background', and that background only covers the last 7 days with a 15-minute cutoff. This is behavior context beyond the structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the critical 'first step' guidance and organized by source mode with clear labels. It is dense and long, but every section maps to a real branch of behavior; minor redundancy in the surrounding prose keeps it from a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-param read tool with no output schema, nothing an agent needs is missing: it covers when to use, the three modes, the cross-source reference flow, retention limits, and where to go for published-app logs. Complete enough to invoke correctly and route away when appropriate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must carry parameter meaning — and it does: it defines each source value in detail, explains the log_reference_id round-trip (ref=<id> from browser to server), notes default for 'server', and states which params are ignored for 'background'. This fully compensates for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (reads) and resource (project runtime logs), and precisely delineates the three source modes with concrete content examples (method/URL/status; console + network; live background state). It is clearly distinguishable from siblings like get_job_status and run_code_in_vm.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly frames this as the FIRST step when debugging runtime problems, gives concrete triggers (500, blank page, 'doesn't work'), and names alternatives: use run_code_in_vm's _floot.getProdBackendLogs for published app logs, and get_guides('prod-backend-logs'). It even states the constraint that these sources are NOT CloudWatch.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All floot tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?