Skill vs MCP vs API
Agent Analytics exposes one analytics surface through four real access paths:
Skillfor agent environments that already support skills and command executionMCPfor chat-native and editor-native tool useCLIfor shell-oriented agent workflowsAPIfor raw HTTP control
The product model does not change between them. Projects, analytics reads, and experiment operations stay the same; only the native entrypoint changes.
Recommended path by environment
Section titled “Recommended path by environment”| Environment | Recommended path | Why |
|---|---|---|
| Claude Code | Skill first | Keeps the workflow agent-native without requiring raw MCP |
| Claude Desktop / Cowork | Hosted MCP | Best fit for connector-style chat tools with native tool calls |
| OpenWork | Skill first | Best fit when you want workspace-local skills, automations, and optional MCP fallback in the same app |
| Cursor | Skill + CLI first | Usually lower overhead than MCP when the agent can already run commands |
| OpenAI Codex | Hosted MCP or skill + CLI | Use native tool calls and supported views, or keep a terminal workflow; see Codex |
| ChatGPT | Hosted MCP in developer mode | Account and workspace policy must allow developer mode; see ChatGPT |
| OpenClaw | Skill first | Cleanest path when OpenClaw owns the scheduled analytics job from chat |
| Instinct | CLI with detached approval | Reuse a saved session for scheduled analytics briefs; see the Instinct guide |
| Custom runtime or internal agent | API | Best fit when you own retries, parsing, and orchestration |
When to use each path
Section titled “When to use each path”Use a skill when your agent already supports skills and can execute commands in the same environment.
A skill is usually the best fit when:
- you want a guided workflow layer around common analytics tasks
- your agent already has terminal access
- you want to stay in the agent’s native loop instead of switching to tool-call-heavy MCP flows
Use MCP when your AI agent already runs inside a tool that supports connectors or MCP servers.
MCP is usually the best fit when:
- you want the install to feel native inside chat
- you want tool calls instead of shell commands
- you do not want to hand-roll auth headers or request payloads
- you want quick project or account summaries through structured tool responses
- you want agent-readable reports such as
analytics_paths, where the tool response includes both compact text and structured data
Tradeoff:
- MCP often adds more latency and token overhead than skill + CLI flows because the model has to manage more tool-call round trips and tool result payloads.
Install the hosted MCP server
Section titled “Install the hosted MCP server”- Server name: Agent Analytics
- Server URL:
https://mcp.agentanalytics.sh/mcp - Transport: Streamable HTTP
- Authentication: browser sign-in with GitHub or Google
In an MCP-compatible app, add a remote server or custom connector using the URL above. Complete the browser sign-in with the identity that owns your Agent Analytics projects. Your client must support remote Streamable HTTP and OAuth authentication; you do not need to paste an account API key into the connector.
For Claude Code, register the server with:
claude mcp add agent-analytics --transport http https://mcp.agentanalytics.sh/mcpThen open /mcp in Claude Code and complete authentication for Agent Analytics. For the connector UI walkthrough, see Claude Desktop / Cowork installation.
For Codex’s OAuth commands or ChatGPT’s developer-mode steps, use the dedicated Codex and ChatGPT guides. Interactive views require host support for MCP Apps. Local plugin testing is separate from the public OpenAI Plugins Directory, where Agent Analytics is not currently listed.
Verify the connection by asking your agent:
- “List my Agent Analytics projects.”
- “Show me a seven-day analytics overview for my project.”
If no projects appear, check that you signed in with the correct account. If you have not created a project or sent events yet, continue with First Project in 5 Minutes.
Use the CLI when your AI agent already has terminal access and is comfortable executing commands.
CLI is usually the best fit when:
- your AI agent already lives in a shell-first environment
- you want predictable command output
- you prefer command composition over tool integration
- you want lower overhead than MCP in editor-style agents like Cursor
- you want simple local auth helpers like
loginandlogoutaround the same API - you want shell-readable commands such as
pathsthat summarize entry pages, exit pages, terminal labels, and next-step analysis
For install, login flow, common commands, and CLI-to-API mapping, continue to the dedicated CLI page.
Use the API when you want strict control over requests, retries, and response parsing.
API is usually the best fit when:
- you are integrating from your own code
- you need exact HTTP-level behavior
- you are debugging auth or payload shape directly
Agent Analytics publishes auth.md discovery and user-claimed agent authentication for custom agent runtimes. Compatible agents can start from an unauthenticated API call, follow the WWW-Authenticate metadata pointer, ask the human for browser approval, then use a scoped aas_* bearer token.
Quick rule of thumb
Section titled “Quick rule of thumb”- Choose
skill + CLIfirst in shell-capable or workspace-driven environments like Claude Code, OpenWork, Cursor, or Codex. - Choose
MCPwhen the agent already lives in a connector-style chat environment and you want native tool calls. - Choose
APIwhen you need full control, custom integration, or lower-level debugging.
Paths Across Access Paths
Section titled “Paths Across Access Paths”Session paths are available through the same product surface:
- CLI:
agent-analytics paths <project> --goal <event> - MCP:
analytics_paths - API:
POST /paths
Use paths when the agent needs to connect entry pages and exit pages to goal behavior before deciding whether to run a funnel query, retention check, or experiment.
The report is intentionally bounded and session-local. It is not a long-cycle identity-stitching report.