Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
arize-ai avatar

Phoenix Server

  • 9 installs
  • 10.9k repo stars
  • Updated August 4, 2026
  • arize-ai/phoenix

phoenix-server is a Claude skill that guides backend development for the Phoenix AI observability platform using Strawberry GraphQL, async SQLAlchemy, and FastAPI.

About

This skill is a backend development guide for the Phoenix AI observability platform, built on Strawberry GraphQL, async SQLAlchemy, and FastAPI. A developer uses it when adding mutations, types, migrations, or tests in the server and db directories. It enforces hard rules such as putting side effects on Mutation rather than Query to avoid an SSRF vector, plus naming and docstring conventions.

  • Backend guide for Strawberry GraphQL, async SQLAlchemy, and FastAPI
  • Hard rule: side effects belong on Mutation not Query to avoid SSRF
  • Reference index for graphql, tests, LLM-trace tests, and DB migrations

Phoenix Server by the numbers

  • 9 all-time installs (skills.sh)
  • +4 installs in the week ending Jul 12, 2026 (Skillselion tracking)
  • Ranked #3,606 of 4,347 Backend & APIs skills by installs in the Skillselion catalog
  • Data as of Aug 5, 2026 (Skillselion catalog sync)
At a glance

phoenix-server capabilities & compatibility

Capabilities
api development · database · backend development
Works with
postgres
Use cases
api development · database · testing
From the docs

What phoenix-server says it does

Backend development guide for the Phoenix AI observability platform (Strawberry GraphQL, SQLAlchemy async, FastAPI).
SKILL.md
**Side effects belong on `Mutation`, not `Query`.**
SKILL.md
npx skills add https://github.com/arize-ai/phoenix --skill phoenix-server

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs9
repo stars10.9k
Last updatedAugust 4, 2026
Repositoryarize-ai/phoenix

What it does

Write or modify Python backend code (GraphQL mutations, types, migrations, tests) in the Phoenix server repo.

Who is it for?

Adding GraphQL mutations, types, subscriptions, migrations, or tests in the Phoenix server

Skip if: Frontend or TypeScript code (covered by other Phoenix skills)

When should I use this skill?

Writing or modifying Python server code in src/phoenix/server/, src/phoenix/db/, or tests/unit/server/

What you get

Backend changes follow the GraphQL, database, and test patterns and avoid known security pitfalls

  • GraphQL mutations, types, or subscriptions
  • database migrations
  • backend tests

By the numbers

  • 4 reference files (graphql, tests, llm-trace-tests, database)
  • 2 supported databases (PostgreSQL, SQLite)

Files

SKILL.mdMarkdownGitHub ↗

Phoenix Backend Development

Phoenix is an AI observability platform. The backend is Python: FastAPI serving a REST API and Strawberry GraphQL API over an async SQLAlchemy ORM (PostgreSQL + SQLite).

Development Guide Index

Read DEVELOPMENT.md (env setup, uv, tests, debugpy, pre-commit, REST API conventions) and CONTRIBUTING.md (PR format, conventional commits, code review expectations) if you have not already.

Everyday Commands

make dev-backend                        # backend only, no frontend build needed
uv run pytest path/to/test -n auto      # run specific tests in parallel
make test-python                        # full test suite
make graphql                            # regenerate schema after GQL changes
make format                             # format all code
make typecheck-python                   # mypy + pyright

Key Directories

src/phoenix/server/api/
  mutations/        Domain-specific mutation mixins, composed in __init__.py
  types/            GraphQL types with field resolvers
  input_types/      Strawberry @input classes with validation
  subscriptions.py  Async generator subscriptions (streaming)
  queries.py        Root query type
  context.py        Request context: db, dataloaders, auth, event queue
  dataloaders/      Batch loaders (prevent N+1 queries)
  auth.py           Permission classes (IsNotReadOnly, IsNotViewer, etc.)
  routers/          REST API endpoints (v1/)
src/phoenix/db/
  models.py         SQLAlchemy ORM models (single file)
  migrations/       Alembic migrations
tests/unit/server/api/
  mutations/        Mutation tests
  types/            Type resolver tests
  conftest.py       Fixtures: db, gql_client, test data factories

What Are You Doing?

TaskReference
Adding or modifying a mutation, type, subscription, or inputreferences/graphql-patterns.md
Writing or modifying testsreferences/test-patterns.md
Writing tests for code that emits OpenInference spans (VCR cassettes, span attribute assertions)references/llm-trace-tests.md
Adding a migration or modifying database modelsreferences/database-patterns.md

Hard Rules

  • Side effects belong on `Mutation`, not `Query`. A resolver that makes outbound

network calls, reads secrets, writes state, or accepts a user-supplied URL/host MUST be a @strawberry.mutation with permission_classes=[...]. Query fields bypass the make check-graphql-permissions CI guard and are reachable unauthenticated by default — this has been exploited as an SSRF vector. See references/graphql-patterns.md → "Query vs Mutation".

Naming

  • Avoid acronyms and single/double-letter abbreviations for local variables.

Prefer the full noun: session / project_session over ps, trace over t, example / dataset_example over de. The cost of a longer identifier is trivial; the cost of having to mentally expand an acronym while reading unfamiliar code is not.

  • Established domain acronyms used in the codebase (db, gql, otel, llm)

are fine — they're vocabulary, not abbreviations of local nouns.

Docstrings

The project rule of "default to no comments" is about inline comments, not docstrings. Public APIs should be documented.

  • Document parameters and return values on public methods of reusable classes

(clients, services, factories, builders). Use Google-style Args: / Returns: / Raises: blocks when the meaning isn't fully recoverable from the type signature. Do not strip these during refactors — semantics outlive file moves.

  • Describe behavior, not implementation. A method on a docs-search client

says "Invoke a backend tool and return its text result", not "Invoke a tool on the MCP server" — the underlying transport is an implementation detail and the docstring should survive a transport swap. Internal helpers (leading _) may reference the transport directly since their scope is bounded.

  • One-liner docstrings are fine when the name and types fully convey intent

(close(), is_backend_tool(name)). Don't pad them with restated signatures.

  • Module docstrings belong at the top of any file that exposes public

surface (a client class, a router, a service module). One sentence on what the module is for is enough.

Related skills

FAQ

Why must side effects go on Mutation, not Query?

Query fields bypass the make check-graphql-permissions CI guard and are reachable unauthenticated by default, which has been exploited as an SSRF vector, so any resolver making outbound calls must be a mutation with permission classes.

Which databases does the Phoenix backend support?

The async SQLAlchemy ORM runs on PostgreSQL and SQLite.

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.