AutoGineer
Generated banner for Convex Insights
Generated logo for Convex Insights

Convex Insights

ConvexOfficialPublished by Convex

  • Skill
  • Tool integration
  • Cloud and DevOps
  • Apache-2.0
  • No issues found
Download ZIP

From the author

Query a running Convex app's logs + health in natural language (official MCP): failures, slow/expensive functions, deploy causality — scoped, evidence-backed, with a dashboard deep link.
— the description by Convex

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

Convex-insights provides a structured approach for querying a running Convex application's logs and health status. By wrapping official MCP tools, it enables agents to perform read-only operational analysis, such as identifying failures, analyzing performance trends, and tracing specific function executions. The skill emphasizes a disciplined workflow: discovering identifiers first, fetching bounded data windows, performing client-side filtering, and providing actionable, verifiable answers with deep links to the Convex dashboard.

What it does

  • Retrieves and filters application logs to identify recent failures and errors.
  • Analyzes health metrics and performance insights for Convex deployments.
  • Traces specific function executions to diagnose individual request failures.
  • Correlates deployment versions with error onset to determine causality.
  • Constructs direct deep links to the Convex dashboard for human verification.
  • Routes performance and cost-related findings to specialized advisor agents.

When to use it

  • When you need to investigate why a specific function call is failing.
  • When you need to verify if a recent deployment introduced new errors.
  • When you need to summarize recent application health or performance trends.
  • When you need to provide evidence-backed operational data to a human operator.

Advantages

  • Ensures operational safety by strictly enforcing read-only access.
  • Reduces noise by aggregating log data into counts and representative samples.
  • Provides verifiable evidence through direct links to the Convex dashboard.
  • Prevents speculative querying by requiring identifier discovery before execution.

Usage examples

“Are there any failures in my production app since the last deployment?”
The agent identifies the current deployment version, fetches recent logs, filters for errors, groups them by function, and provides a summary with a dashboard link.
“Why is the getDashboardData function failing?”
The agent retrieves a recent log window, filters for the specific function, extracts the relevant request ID, and presents the stack trace and error message.

Install

  1. Download the skill as a ZIP:

    https://mp-staging.autogineer.com/agent-skills/convex/convex-insights/download

  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip convex-insights.zip -d .agents/skills

Documentation by Convex

<!-- GENERATED from convex-agents content/capabilities/convex-insights.json — do not edit by hand. -->

Query logs + health in natural language

The deployment already records what happened; the agent just has to ask well. This capability is a disciplined wrapper over the official Convex MCP's read tools (logs, insights, functionSpec, status) that turns operational questions into narrow, evidence-returning queries and hands back answers a human can one-click verify in the dashboard. The discipline is copied from the observability MCP surface that works best in the wild: discover fields before querying, three views not fifteen tools, token-frugal output, and a dashboard deep link on every answer.

Workflow

  1. GUARD: deploy-guard step 0-1 — identify + announce which deployment is being read. Reading logs/insights is read-only; never enable prod mutation flags for an insights pass.

  2. DISCOVER before you query — never guess identifiers. Use functionSpec to list the real function names and status for the deployment/version. Note the tool limits up front: logs takes only --history <n> (a COUNT, not a time window), --success, --jsonl, --prod, --deployment — there is NO server-side status/function/requestId/time filter; insights has no function filter and is cloud dev/prod + user-auth only. So you fetch a recent window and filter CLIENT-SIDE.

  3. PICK ONE OF THREE VIEWS and fetch the raw window, then filter locally:

    • failures view → logs --history <n> --jsonl, then locally keep failures + group by function + error message, returning counts + the first stack per group. Answers 'what's erroring', 'what failed after deploy'.

    • health view → insights (cloud only): the typed 72h read-limit / OCC events. Surface + rank them, but hand perf/cost ROOT-CAUSING and fixes to convex-advisor — emit those as pointer findings, do not own the perf-fix framing here.

    • trace view → logs --history <n> --jsonl then locally filter to one requestId/function to read the full execution. Answers 'why did THIS call fail'.

  4. SCOPE by fetching a bounded recent window (a sensible --history count) and filtering client-side to the function/status/requestId asked about; when the window is large, aggregate (counts by function/message) rather than dumping lines.

  5. ANSWER with (a) the one-line finding, (b) the evidence (counts + one representative stack/log line), and (c) WHEN POSSIBLE an agent-constructed dashboard deep link (dashboard.convex.dev, the deployment's Logs/Functions view) for human verification — no tool returns the link, so build it from the deployment name + function; never a raw log dump as the answer.

  6. CROSS-CHECK deploy causality when asked 'did my deploy break this': compare the failure onset (from the log timestamps) against the deployment version from status; correlate, don't assert.

  7. HAND OFF, don't fix here: a perf/cost cause → convex-advisor (which owns those fixes); a code defect → convex-reviewer/convex-authz; a live error to react to going forward → monitor/sentinel. Emit findings on the bus (specs/finding.schema.json) — primarily observability, with perf/cost as pointer findings to advisor — so a composite pass can pick them up.

Rules

  • Discover real function/field names (functionSpec/status) before filtering — never guess identifiers, never return a confusing empty result for a name the app doesn't have.

  • logs and insights have NO server-side status/function/requestId/time-window filter (logs takes only a --history COUNT; insights is cloud-only) — fetch a bounded recent window and filter CLIENT-SIDE; say so rather than implying params that don't exist.

  • One of three views per question (failures / health / trace) — don't fan out into many speculative tool calls.

  • No tool returns a dashboard link — construct it from the deployment name + function when possible for human verification; never answer with a raw log dump.

  • Read-only always: an insights pass runs no mutation and never enables prod mutation flags (deploy-guard discipline).

  • Stay a reader and defer perf/cost fixes to convex-advisor: emit primarily observability, route perf/cost as POINTER findings so advisor uniquely owns the perf-fix framing; forward-looking reaction goes to monitor/sentinel.

Files

SKILL.md

<!-- GENERATED from convex-agents content/capabilities/convex-insights.json — do not edit by hand. -->

Query logs + health in natural language

The deployment already records what happened; the agent just has to ask well. This capability is a disciplined wrapper over the official Convex MCP's read tools (logs, insights, functionSpec, status) that turns operational questions into narrow, evidence-returning queries and hands back answers a human can one-click verify in the dashboard. The discipline is copied from the observability MCP surface that works best in the wild: discover fields before querying, three views not fifteen tools, token-frugal output, and a dashboard deep link on every answer.

Workflow

  1. GUARD: deploy-guard step 0-1 — identify + announce which deployment is being read. Reading logs/insights is read-only; never enable prod mutation flags for an insights pass.

  2. DISCOVER before you query — never guess identifiers. Use functionSpec to list the real function names and status for the deployment/version. Note the tool limits up front: logs takes only --history <n> (a COUNT, not a time window), --success, --jsonl, --prod, --deployment — there is NO server-side status/function/requestId/time filter; insights has no function filter and is cloud dev/prod + user-auth only. So you fetch a recent window and filter CLIENT-SIDE.

  3. PICK ONE OF THREE VIEWS and fetch the raw window, then filter locally:

    • failures view → logs --history <n> --jsonl, then locally keep failures + group by function + error message, returning counts + the first stack per group. Answers 'what's erroring', 'what failed after deploy'.

    • health view → insights (cloud only): the typed 72h read-limit / OCC events. Surface + rank them, but hand perf/cost ROOT-CAUSING and fixes to convex-advisor — emit those as pointer findings, do not own the perf-fix framing here.

    • trace view → logs --history <n> --jsonl then locally filter to one requestId/function to read the full execution. Answers 'why did THIS call fail'.

  4. SCOPE by fetching a bounded recent window (a sensible --history count) and filtering client-side to the function/status/requestId asked about; when the window is large, aggregate (counts by function/message) rather than dumping lines.

  5. ANSWER with (a) the one-line finding, (b) the evidence (counts + one representative stack/log line), and (c) WHEN POSSIBLE an agent-constructed dashboard deep link (dashboard.convex.dev, the deployment's Logs/Functions view) for human verification — no tool returns the link, so build it from the deployment name + function; never a raw log dump as the answer.

  6. CROSS-CHECK deploy causality when asked 'did my deploy break this': compare the failure onset (from the log timestamps) against the deployment version from status; correlate, don't assert.

  7. HAND OFF, don't fix here: a perf/cost cause → convex-advisor (which owns those fixes); a code defect → convex-reviewer/convex-authz; a live error to react to going forward → monitor/sentinel. Emit findings on the bus (specs/finding.schema.json) — primarily observability, with perf/cost as pointer findings to advisor — so a composite pass can pick them up.

Rules

  • Discover real function/field names (functionSpec/status) before filtering — never guess identifiers, never return a confusing empty result for a name the app doesn't have.

  • logs and insights have NO server-side status/function/requestId/time-window filter (logs takes only a --history COUNT; insights is cloud-only) — fetch a bounded recent window and filter CLIENT-SIDE; say so rather than implying params that don't exist.

  • One of three views per question (failures / health / trace) — don't fan out into many speculative tool calls.

  • No tool returns a dashboard link — construct it from the deployment name + function when possible for human verification; never answer with a raw log dump.

  • Read-only always: an insights pass runs no mutation and never enables prod mutation flags (deploy-guard discipline).

  • Stay a reader and defer perf/cost fixes to convex-advisor: emit primarily observability, route perf/cost as POINTER findings so advisor uniquely owns the perf-fix framing; forward-looking reaction goes to monitor/sentinel.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Security

No issues found by our static scan· No issues found

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
Convex
Publisher
Convex (Official)
Source
convex/agent-skills · skills/convex-insights · commit f60629d
Licence
Apache License 2.0 (redistribution allowed)
  • LICENSE (added by AutoGineer from LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Convex.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download convex-insights.zip