Debug Traces from IDE

The MCP server lives at https://api.futureagi.com/mcp and authenticates over OAuth, so there are no API keys to copy around.

claude mcp add futureagi --transport http https://api.futureagi.com/mcp

{
  "mcpServers": {
    "futureagi": {
      "url": "https://api.futureagi.com/mcp"
    }
  }
}

{
  "mcp.servers": {
    "futureagi": {
      "type": "http",
      "url": "https://api.futureagi.com/mcp"
    }
  }
}

{
  "mcpServers": {
    "futureagi": {
      "url": "https://api.futureagi.com/mcp"
    }
  }
}

{
  "mcpServers": {
    "futureagi": {
      "serverUrl": "https://api.futureagi.com/mcp"
    }
  }
}

Restart your IDE after editing the config.

You should see: for Claude Code, claude mcp list shows futureagi with ! Needs authentication. For the other IDEs, the assistant lists futureagi as an available MCP server once it reconnects. That’s expected. The OAuth handshake happens on the first tool call, in the next step.

Ask your assistant anything that needs Future AGI data, for example:

List my Future AGI projects.

This opens a browser to the consent screen. Review the permission groups and click Authorize.

You should see: the assistant returns your project list, and the browser tab confirms the connection. The token is cached, so you won’t see the consent screen again from this IDE.

Open your IDE’s chat panel and ask about your traces directly:

List the most recent traces in my support-bot project that have errors.

The assistant calls search_traces with has_error=True on that project.

You should see: a list of recent traces flagged as errored, with timestamps and a short description of each. If nothing comes back because the traces don’t carry a raw error flag, ask the assistant to try error clusters instead:

Show me error clusters for my support-bot project.

That routes to list_error_clusters, which surfaces AI-detected failure categories across the project, a signal that catches more than HTTP-level errors alone.

Pick a trace from the previous list and ask for detail:

Show me the span tree for the second trace from that list.

The assistant calls get_span_tree, which returns the parent span plus every nested LLM and tool call, with timing and inputs.

Then ask for a diagnosis:

Run error analysis on that trace.

This calls get_trace_error_analysis. You should see: a categorized finding (for example Language-only, Unsupported Claim, Tool Selection Errors, or Goal Deviation) with an impact rating (HIGH / MEDIUM / LOW) and a short quality scorecard across factual grounding, privacy and safety, instruction adherence, and optimal plan execution, explaining why the trace failed.

Zoom out from a single trace to the whole project:

Analyze all traces in my project from the last hour and group failures by category.

The assistant calls analyze_project_traces and list_error_clusters together.

You should see: a histogram of failure categories with counts, so you can tell whether the trace you just diagnosed is a one-off or part of a recurring pattern.

Once you know what’s wrong, mark the affected traces so they’re easy to find later:

Add the tag needs-policy-grounding to the failing traces, and score them on groundedness.

The assistant calls add_trace_tags to apply the tag, then create_score with the annotation_label_id of the groundedness label you created in the prerequisites to attach the score. Ask it to name the metric explicitly. submit_trace_scores is a different tool: it writes a full 1-5 quality scorecard (factual grounding, privacy and safety, instruction adherence, optimal plan execution, each with a reason) on a single trace, not a batch form of create_score.

You should see: the tag and score appear on the traces in the dashboard within a few seconds.

The same chat that read the trace can now read your code. Ask:

Based on the error analysis, draft a system-prompt patch that refuses to answer policy questions when no grounding tool is available. Show it as a diff against agent.py.

Your assistant has both the trace findings from MCP and the file from your editor, so it produces a paste-ready diff. Apply it, re-run a few queries through your agent, then ask:

Score the latest traces in my support-bot project on groundedness and tell me if they still show Unsupported Claim findings.

You should see: the assistant re-runs search_traces to pull the new traces, scores them with create_score the same way you did in the tagging step, and reports the new scores next to the ones you recorded earlier. Nothing re-scores traces automatically, and get_trace_error_analysis only returns something once Error Feed has sampled and analyzed the new traces, so treat the manual score comparison as your proof. That’s the full loop: detect, diagnose, fix, verify, all from one IDE chat thread.