What can you do with this server?

The Opik MCP Server is a Model Context Protocol implementation that provides a unified interface for managing Opik resources through various transport mechanisms: * Prompt Management: Create, list, update, delete prompts, and manage versions * Project/Workspace Management: Create, list, update, and delete projects * Trace Management: List traces, retrieve details, and access statistics * Metrics: Query metrics data with filtering options * Server Information: Retrieve configuration details * Contextual Help: Access help topics and examples

Which integrations are available for this server?

Used for configuration through environment variables in a .env file Hosts the repository and provides licensing information Provides a Makefile for common operations like testing and starting the server Used as the runtime environment for the MCP server Implements pre-commit hooks to ensure code quality Provides community support through the linked Slack community Provides TypeScript language support for the MCP server implementation

How do I use Opik MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Opik MCP Server list my recent prompts" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

de en es ja ko ru zh

Opik MCP Server

by comet-ml

Overview Schema Related Servers Score Discussions

Python

Hybrid

Opik MCP Server

The official Model Context Protocol (MCP) server for Opik, the open-source LLM observability and evaluation platform, built by Comet. Plug your AI host (Claude Code, Cursor, VS Code Copilot, MCP Inspector) directly into your Opik workspace: read traces, log scores, save prompt versions, and ask Ollie, Opik's in-product AI assistant, investigative questions, all from the chat.

Built for LLM engineers who already run Opik and want to drive it from the same AI assistant they code with.

Migrating from the old npx opik-mcp? The TypeScript server is deprecated and sunsets on 2026-11-15. Swap npx -y opik-mcp for uvx opik-mcp@latest in your MCP client config. Full guide: legacy/typescript/MIGRATION.md.

You:    "Why did the experiment 'gpt-4o-rerank-v3' regress on factuality?"
Claude: → ask_ollie → reads experiment + traces → "Three traces failed because…"

You:    "Score trace 7f2e… 0.9 on helpfulness with reason 'great recovery'."
Claude: → write(score.create) → done

Install

opik-mcp is a Python package (requires Python 3.13+). The recommended way to run it is uvx, which fetches and runs the latest published version on demand — no global install, no virtualenv juggling.

Install uv once:

curl -LsSf https://astral.sh/uv/install.sh | sh   # macOS / Linux
# or: brew install uv

You'll need two things from your Opik workspace:

OPIK_API_KEY — get it from comet.com/api/my/settings/.
OPIK_WORKSPACE — your workspace name (lowercase, as it appears in the URL). E.g. https://www.comet.com/acme-ai/... → OPIK_WORKSPACE=acme-ai. COMET_WORKSPACE is accepted as a deprecated alias.

Cloud, with an API key: set it unless your account default is the one you want. Left out, the server sends default, which Comet resolves to your account's default workspace. That works, but if you actually work in a named workspace you will be pointed at a different one with nothing to tell you — your reads come back from the wrong place rather than failing.
Cloud, over OAuth: leave it unset. The workspace comes from the token you authorized, and the server ignores this setting entirely.
Local / open source: leave it unset. Open source Opik has a single workspace named default and no way to create others, which is exactly what the fallback gives you.
Self-hosted Comet: set it. Unlike open source, these deployments have real named workspaces, and the same silent-wrong-workspace risk applies.
Whichever applies, make sure the value is actually substituted. Snippets in the wild ship placeholders like <your-workspace> or ${input:OPIK_WORKSPACE}; pasted as-is, those are not workspace names. The server now refuses them outright rather than letting the backend answer with an auth error that explains nothing.

Claude Code

Add the server with one command:

claude mcp add --transport stdio opik-mcp \
  --env OPIK_API_KEY=<your-key> \
  --env OPIK_WORKSPACE=<your-workspace> \
  -- uvx opik-mcp

Or edit ~/.claude.json directly:

{
  "mcpServers": {
    "opik-mcp": {
      "type": "stdio",
      "command": "uvx",
      "args": ["opik-mcp"],
      "env": {
        "OPIK_API_KEY": "<your-key>",
        "OPIK_WORKSPACE": "<your-workspace>"
      }
    }
  }
}

Restart Claude Code. Verify with /mcp — opik-mcp should appear as connected. Then, in the chat, ask: "list my Opik projects" — Claude will call the list tool and you'll see your workspace's projects.

Cursor

Edit ~/.cursor/mcp.json (global) or .cursor/mcp.json (project), or open Cmd+Shift+J → Features → Model Context Protocol:

{
  "mcpServers": {
    "opik-mcp": {
      "type": "stdio",
      "command": "uvx",
      "args": ["opik-mcp"],
      "env": {
        "OPIK_API_KEY": "<your-key>",
        "OPIK_WORKSPACE": "<your-workspace>"
      }
    }
  }
}

Reload Cursor; the green dot next to opik-mcp in the MCP panel confirms the connection. Ask in chat: "list my Opik projects".

Cursor 60s timeout. Cursor enforces a hard tool-call timeout that doesn't reset on progress notifications. Long ask_ollie turns will fail on Cursor. See Known host limits.

VS Code Copilot

.vscode/mcp.json in your workspace (or User Settings JSON):

{
  "servers": {
    "opik-mcp": {
      "type": "stdio",
      "command": "uvx",
      "args": ["opik-mcp"],
      "env": {
        "OPIK_API_KEY": "<your-key>",
        "OPIK_WORKSPACE": "<your-workspace>"
      }
    }
  }
}

Reload the window; the Copilot Chat MCP indicator shows opik-mcp once the server is reachable. Ask in chat: "list my Opik projects".

MCP Inspector (manual testing)

OPIK_API_KEY=<your-key> OPIK_WORKSPACE=<your-workspace> \
  npx @modelcontextprotocol/inspector uvx opik-mcp

Self-hosted Opik

Add COMET_URL_OVERRIDE (and OPIK_URL if Opik lives at a non-default path) to the same env block in your host config:

{
  "mcpServers": {
    "opik-mcp": {
      "type": "stdio",
      "command": "uvx",
      "args": ["opik-mcp"],
      "env": {
        "OPIK_API_KEY": "<your-key>",
        "OPIK_WORKSPACE": "<your-workspace>",
        "COMET_URL_OVERRIDE": "https://opik.your-company.com",
        "OPIK_MCP_ANALYTICS_SOURCE": ""
      }
    }
  }
}

Omit OPIK_WORKSPACE on an open-source deployment, where default is the only workspace; keep it on a self-hosted Comet, which has real named ones.

ask_ollie and run_experiment are available on Comet Cloud only — on self-hosted those calls will fail at dispatch, so use read / list / write directly. Setting OPIK_MCP_ANALYTICS_SOURCE="" opts your install out of the cloud-Comet source label on telemetry events.

Related MCP server: dap-mcp

Tools

opik-mcp exposes a small, outcome-oriented surface — six tools that cover the full lifecycle (read → annotate → curate → author → iterate).

Tool	Purpose
`read`	Universal read by id / name / `opik://` URI
`list`	Universal list with optional name filter + pagination
`ask_ollie`	Investigate / synthesize via the Opik in-product assistant
`write`	Universal write — log traces/spans, score, comment, save prompts, manage test suites & experiments
`schema`	Introspect write-operation schemas (used by the LLM to construct valid payloads)
`run_experiment`	Run an evaluation experiment end-to-end via Ollie

`read`

One tool for any "show me X" question. Takes an entity_type plus an id (UUID or, for nameable types, a name) or a full opik:// URI. Composite reads (trace, prompt) inline their children so a single call returns the full picture.

Supported entities: project, trace, span, test_suite, experiment, prompt. Name-based lookup is available for project, experiment, prompt, test_suite (slower — two API calls — and may return multiple matches).

read(entity_type="trace", id="7f2e3c8a-…")
read(entity_type="project", id="demo")          # name lookup
read(entity_type="trace", id="opik://traces/7f2e3c8a-…")

`list`

Browse a collection with optional name filter and pagination. Project-scoped types (trace, test_suite_item, prompt_version) require their parent UUID.

list(entity_type="experiment", page=1, size=25)
list(entity_type="experiment", name="rerank")          # name substring filter
list(entity_type="trace", project_id="<project-uuid>") # traces of one project

`ask_ollie`

For investigative questions, cross-entity synthesis, or anything that needs Opik domain expertise. Ollie has direct read access to your workspace and can execute writes (scores, comments, test-suite items, prompt versions) mid-stream when asked.

ask_ollie(query="Why are spans in project 'demo' slower this week than last?")
ask_ollie(query="Compare experiments A and B on factuality. Score the bottom 5 traces of A 0.2 with reason.")

Returns the assistant's final text plus a thread_id. Pass it back on follow-ups to preserve context — Ollie has no memory across threads.

YOLO mode (default). Writes Ollie performs mid-stream execute without a per-action confirmation. Each auto-approval is logged as a JSON audit row on the opik_mcp.audit Python logger. To require confirmation instead, set OPIK_MCP_AUTO_APPROVE=disabled — Ollie's confirm requests then surface as typed errors you can manually re-issue.

Available on Comet Cloud only.

`write`

Universal write dispatcher. Pass operation + data and the dispatcher validates the payload, applies the right REST verb, and returns the backend response.

Operations:

Operation	What it does
`trace.create`	Log a single trace (or a batch). Parent for spans / scores / comments.
`trace.update`	Finalize or amend an existing trace.
`span.create`	Log a span on an existing trace (or a batch).
`score.create`	Attach a numeric feedback score to a trace, span, or thread.
`comment.create`	Attach a free-text comment to a trace, span, or thread.
`prompt_version.save`	Save a new prompt version (creates the prompt by name if missing).
`test_suite.create`	Create an evaluation test suite.
`test_suite_item.upsert`	Upsert items into a test suite (always the envelope shape).
`experiment.create`	Create an experiment scoped to a test suite.
`experiment_item.create`	Attach trace + dataset_item rows to an experiment.

write(operation="score.create", data={
  "target": "trace",
  "target_id": "7f2e3c8a-…",
  "name": "helpfulness",
  "value": 0.9,
  "reason": "great recovery"
})

`schema`

Inspect the exact JSON shape and required fields of any write operation before you call it — useful when you're not sure what data should look like. Returns the schema, OAuth scope, and one validated example. Pure lookup, no backend call.

schema(operation="score.create")
schema(operation="prompt_version.save")

`run_experiment`

Run an evaluation experiment end-to-end via Ollie. Takes a single experiment_config dict that mirrors Opik's experiment shape (prompt, test suite, scorers); Ollie executes the run and writes results back as an Opik experiment.

run_experiment(experiment_config={
  "test_suite_name": "qa-eval-v2",
  "prompt_name": "welcome-msg",
  # … see `schema(operation="experiment.create")` for the full shape
})

Available on Comet Cloud only.

Configuration

Every setting is an environment variable. Required ones in bold.

Identity / endpoint

Variable	Default	Notes
`OPIK_API_KEY`	—	Required for `ask_ollie` and any authenticated read/write.
`OPIK_WORKSPACE`	unset	Workspace name. On cloud with an API key, unset sends `default`, which resolves to your account's default workspace — set it explicitly if you work in a different one, or reads come from the wrong workspace silently. Leave unset over OAuth (the token carries it) and on local/OSS (`default` is the only workspace there).
`COMET_WORKSPACE`	—	Deprecated alias for `OPIK_WORKSPACE` (backward compat). `OPIK_WORKSPACE` wins if both are set.
`COMET_WORKSPACE_ID`	unset	Optional workspace UUID. Stamped into analytics events when set, and takes precedence over the resolved one. Rarely needed — OAuth installs get the UUID from the token automatically.
`COMET_URL_OVERRIDE`	`https://www.comet.com`	Set to your self-hosted Comet host, or `https://dev.comet.com` for staging.
`OPIK_URL`	derived from `COMET_URL_OVERRIDE` + `/opik/api`	Override only if Opik lives on a different host/path than the Comet UI.
`OPIK_DEFAULT_PROJECT_NAME`	unset	When set, the per-session `instructions` blob tells the LLM to pass this as `project_name` on every tool call unless the user names a different project.

Server / transport

Variable	Default	Notes
`OPIK_MCP_TRANSPORT`	`stdio`	`stdio` for host-launched, `streamable-http` to listen on a port.
`OPIK_MCP_HOST`	`127.0.0.1`	uvicorn bind host (`streamable-http` only).
`OPIK_MCP_PORT`	`8080`	uvicorn bind port (`streamable-http` only).
`OPIK_MCP_RELOAD`	`false`	`true` to enable uvicorn `--reload` (dev only).
`OPIK_MCP_AS_URL`	unset	OAuth Authorization Server URL, advertised in `/.well-known/oauth-protected-resource` (RFC 9728) and used as the proxy target for AS-discovery probes. Required for MCP hosts to bootstrap the OAuth dance over HTTP.
`OPIK_MCP_RESOURCE_URI`	unset	Canonical public URI of this server, advertised as `resource` in the protected-resource metadata and used to derive the `WWW-Authenticate` hint.
`OPIK_MCP_LOG_LEVEL`	`INFO`	stderr logger threshold.

Choosing a transport

opik-mcp performs no local credential validation on HTTP transport: any well-formed Authorization: Bearer … (an Opik API key or an opik_mcp_at_… OAuth access token) is forwarded verbatim to opik-backend, which is the single point of auth enforcement. Pick the transport by deployment shape:

Scenario	Transport
MCP client and Opik on the same machine (local OSS install)	stdio (recommended — simplest, no port, no OAuth setup)
Local MCP client → remote Opik (Comet cloud / self-hosted)	stdio with `OPIK_API_KEY`, or HTTP with OAuth (`OPIK_MCP_AS_URL` pointing at the backend)
Hosted opik-mcp behind the same edge as opik-backend	HTTP — bearers are validated by the backend per request

Note for local OSS installs: the OSS backend does not authenticate requests, so an HTTP opik-mcp in front of it is as open as the OSS REST API itself. Keep the default 127.0.0.1 bind (and prefer stdio) on shared networks.

Ollie / long calls

Variable	Default	Notes
`OPIK_MCP_AUTO_APPROVE`	`enabled`	`disabled` to require a per-action approval before Ollie's mid-stream writes proceed. On hosts that advertise the MCP `elicitation` capability the user sees a yes/no prompt; on dumber hosts the request surfaces as a typed error you can manually re-issue.
`OPIK_MCP_ELICIT_TIMEOUT_SECONDS`	`60`	How long Ollie's mid-stream confirmation prompt may wait for the user before being treated as a cancel. `0` disables the bound (debug only).
`OPIK_MCP_POD_READY_TIMEOUT_S`	`120`	Ollie pod cold-start poll cap.
`OPIK_MCP_POD_READY_INTERVAL_S`	`2`	Cold-start poll interval.
`OPIK_MCP_HEARTBEAT_INTERVAL_S`	`15.0`	Watchdog cadence — emits a `notifications/progress` tick when the pod is silent, keeping host timeouts at bay.
`OPIK_MCP_STREAM_IDLE_TIMEOUT_S`	`300.0`	Hard ceiling on pod silence before `ask_ollie` aborts. `0` disables (debug only).

Telemetry

Anonymous usage events (event type + timing only — no query content). A SHA-256 digest of your API key is included so support can find your account; the raw key never leaves the process. Opt out: OPIK_MCP_ANALYTICS_ENABLED=false.

Variable	Default	Notes
`OPIK_MCP_ANALYTICS_ENABLED`	`true`	Set to `false` to disable all telemetry.
`OPIK_MCP_ANALYTICS_URL`	`https://stats.comet.com/notify/event/`	Override for staging.
`OPIK_MCP_ANALYTICS_ENVIRONMENT`	`prod`	Tag on every event (`prod` / `staging` / `dev`).
`OPIK_MCP_ANALYTICS_SOURCE`	`comet.com`	Receiver uses this to mark `on_prem=False`. On-prem installs should override to `""` or their own domain.
`OPIK_MCP_ANALYTICS_CONNECT_TIMEOUT_S`	`5.0`	HTTP connect timeout.
`OPIK_MCP_ANALYTICS_TOTAL_TIMEOUT_S`	`10.0`	HTTP total request timeout.

Known host limits

The MCP spec lets hosts reset their tool-call timeout on notifications/progress — opik-mcp emits one per Ollie SSE event plus a 15-second watchdog heartbeat. Reality is uneven:

Claude Code — no documented tool-call timeout; heartbeat keeps the call alive until message_end. Recommended.
Cursor — hard 60s timeout that does not reset on progress (upstream bug). Long Ollie turns will fail. Keep ask_ollie queries focused.
MCP Inspector — MAX_TOTAL_TIMEOUT bounds total duration (default 60s). Raise it in the Inspector UI for long operations.

If a call gets stuck, set OPIK_MCP_LOG_LEVEL=DEBUG — heartbeat failures (usually host disconnects) are logged on opik_mcp.ask_ollie at debug level.

Troubleshooting

OPIK_API_KEY is required to use ask_ollie — the var isn't reaching the server process. In Claude Code / Cursor / VS Code, env vars only apply when inside the env block of the MCP server config, not your shell. Restart the host after editing.

ask_ollie returns "pod not ready" after 2 minutes — the Ollie pod cold-start exceeded OPIK_MCP_POD_READY_TIMEOUT_S. Retry — the second call usually hits a warm pod.

ask_ollie / run_experiment fails with a dispatch error on self-hosted Opik — those tools are available on Comet Cloud only. Use read / list / write directly on self-hosted.

Cursor call times out at 60s — Cursor's known bug, not opik-mcp. Either shorten the Ollie query, or run the same operation on Claude Code which has no hard cap.

Development

git clone git@github.com:comet-ml/opik-mcp.git
cd opik-mcp
make install        # uv sync --extra dev
make check          # lint + typecheck + test
make run-dev        # uvicorn with --reload + DEBUG logs
make inspect        # MCP Inspector against the running server

Common targets:

Target	What it does
`make install`	`uv sync --extra dev`
`make run`	Run the MCP server (stdio by default).
`make run-dev`	Run with DEBUG logging + uvicorn `--reload`.
`make dev`	Run via `mcp dev` (Inspector dev-mode wrapper).
`make inspect`	Launch MCP Inspector against a running server.
`make test`	`uv run pytest -q`.
`make test-live`	Live end-to-end against `dev.comet.com` (set `OPIK_API_KEY` + `OPIK_WORKSPACE`).
`make lint`	`ruff check` + format check.
`make format`	`ruff format` + `ruff check --fix`.
`make typecheck`	`mypy`.
`make check`	`lint + typecheck + test`.

Repo layout:

opik-mcp/
├── src/opik_mcp/        ← server, tools, ask_ollie, analytics
├── tests/               ← pytest suites
├── scripts/             ← live-BE smoke + MCP-session smoke
├── legacy/typescript/   ← deprecated v2 TS server
├── pyproject.toml
└── Makefile

Get help

Open an issue for bugs and feature requests
Opik docs for SDK / backend documentation
Comet community Slack for questions

Upgrading from v2? The legacy TypeScript server still ships on npm as opik-mcp@^2 (npx -y opik-mcp); source is preserved under legacy/typescript/. See legacy/typescript/DEPRECATED.md for the support policy.

License

Apache-2.0.

Available Tools

19 tools

create-projectC

Create a new project/workspace

ParametersJSON Schema

Name	Required	Description
`description`	No	Description of the project
`name`	Yes	Name of the project
`workspaceName`	No	Workspace name to use instead of the default

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Create') but doesn't cover critical aspects like required permissions, whether the creation is idempotent, what happens on conflicts, or the expected response format. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.

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

Conciseness5/5

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

The description is a single, efficient sentence with zero wasted words—it directly states the tool's purpose without unnecessary elaboration. It's appropriately sized and front-loaded, making it easy to parse quickly.

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

Completeness2/5

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

Given that this is a mutation tool ('Create') with no annotations and no output schema, the description is insufficient. It doesn't explain what a 'project' or 'workspace' entails in this system, how to handle errors, or what the tool returns upon success, leaving the agent with incomplete context for effective use.

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

Parameters3/5

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

The description adds no parameter-specific information beyond what's already in the input schema, which has 100% coverage with clear descriptions for all three parameters. This meets the baseline of 3, as the schema adequately documents the parameters, but the description doesn't provide additional context like examples or usage notes.

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

Purpose4/5

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

The description 'Create a new project/workspace' clearly states the verb ('Create') and resource ('project/workspace'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'create-prompt' or explain what differentiates a 'project' from a 'workspace' in this context, which prevents a perfect score.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'update-project' or 'list-projects', nor does it mention prerequisites or constraints. While the verb 'Create' implies it's for new entities, there's no explicit comparison to siblings or context for usage decisions.

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

create-promptC

Create a new prompt

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Name of the prompt

TDQS

C2.3/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. 'Create a new prompt' implies a write/mutation operation but provides no details about permissions needed, whether creation is idempotent, what happens on conflicts, or what the response contains. This leaves significant behavioral gaps for a creation tool.

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

Conciseness5/5

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

The description is extremely concise at just three words. While it's under-specified in content, it's not verbose or poorly structured. Every word earns its place in this minimal description.

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

Completeness2/5

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

For a creation tool with no annotations and no output schema, the description is inadequate. It doesn't explain what a 'prompt' is in this context, what fields beyond 'name' might be set by default, what the creation response looks like, or how this differs from similar tools. The description fails to provide necessary context for effective tool use.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents the single 'name' parameter. The description adds no additional parameter context beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no parameter information in the description.

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

Purpose2/5

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

The description 'Create a new prompt' is a tautology that restates the tool name without adding specificity. It doesn't distinguish this tool from sibling tools like 'create-prompt-version' or explain what kind of prompt is being created. The purpose is minimally stated but lacks meaningful differentiation.

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

Usage Guidelines1/5

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

No guidance is provided about when to use this tool versus alternatives like 'create-prompt-version' or 'update-prompt'. There's no mention of prerequisites, constraints, or appropriate contexts for invoking this creation tool versus other prompt-related operations.

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

create-prompt-versionC

Create a new version of a prompt

ParametersJSON Schema

Name	Required	Description
`commit_message`	Yes	Commit message for the prompt version
`name`	Yes	Name of the original prompt
`template`	Yes	Template content for the prompt version

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool creates a new version but doesn't explain what that entails—whether it's a write operation, requires specific permissions, affects existing prompts, or has side effects like triggering notifications. For a mutation tool with zero annotation coverage, this lack of detail is a significant gap in transparency.

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

Conciseness5/5

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action ('Create a new version'), making it easy to parse quickly. Every word earns its place, and there's no redundancy or fluff.

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

Completeness2/5

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

Given the complexity of a versioning operation (a mutation with potential side effects), no annotations, and no output schema, the description is incomplete. It doesn't cover behavioral aspects like permissions, idempotency, or error handling, nor does it hint at return values. For a tool that modifies data, this leaves critical gaps for an AI agent to understand its full context.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema fully documents the three parameters (name, template, commit_message). The description adds no additional meaning beyond what's in the schema, such as explaining how 'name' relates to the original prompt or what 'commit_message' is used for. With high schema coverage, a baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't need to.

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

Purpose4/5

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

The description clearly states the action ('Create') and resource ('new version of a prompt'), making the purpose immediately understandable. It distinguishes from siblings like 'create-prompt' (which creates a new prompt rather than a version) and 'update-prompt' (which might modify an existing prompt without versioning). However, it doesn't specify what constitutes a 'version' (e.g., whether it's a snapshot, revision, or branch), leaving some ambiguity.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing prompt), compare to siblings like 'update-prompt' or 'create-prompt', or indicate scenarios where versioning is appropriate (e.g., for tracking changes, experimentation, or deployment). Without this, users must infer usage from the tool name alone.

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

delete-projectC

Delete a project

ParametersJSON Schema

Name	Required	Description	Default
`projectId`	Yes	ID of the project to delete
`workspaceName`	No	Workspace name to use instead of the default

TDQS

C2.1/5.0

Behavior1/5

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

With no annotations provided, the description carries full burden but discloses nothing beyond the basic action. It fails to address critical behavioral traits: whether deletion is permanent or reversible, required permissions, side effects (e.g., on associated data), error conditions, or response format. For a destructive operation, this lack of transparency is severe.

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

Conciseness5/5

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

The description is extremely concise with a single sentence, 'Delete a project', which is front-loaded and wastes no words. While under-specified, it efficiently communicates the core action without redundancy or fluff.

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

Completeness2/5

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

Given the tool's complexity (destructive operation with 2 parameters), lack of annotations, and no output schema, the description is incomplete. It does not compensate for missing behavioral context, usage guidelines, or output expectations, leaving significant gaps for an AI agent to understand and invoke the tool safely.

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

Parameters3/5

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

Schema description coverage is 100%, with clear parameter documentation in the schema itself. The description adds no parameter semantics beyond what the schema provides, such as explaining 'projectId' format or 'workspaceName' usage. However, the baseline score of 3 is appropriate since the schema adequately covers parameters.

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

Purpose2/5

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

The description 'Delete a project' is a tautology that restates the tool name without adding meaningful context. It specifies the verb 'Delete' and resource 'project', but lacks distinction from sibling tools like 'delete-prompt' or details about what deletion entails. This minimal statement fails to clarify scope or differentiate from alternatives.

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

Usage Guidelines1/5

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

No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites (e.g., project existence), exclusions (e.g., irreversible effects), or comparisons to sibling tools like 'update-project' or 'list-projects'. The description offers no context for decision-making.

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

delete-promptC

Delete a prompt

ParametersJSON Schema

Name	Required	Description	Default
`promptId`	Yes	ID of the prompt to delete

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action is destructive ('Delete') but doesn't elaborate on consequences (e.g., permanent deletion, no undo), permissions required, or error conditions. This is a significant gap for a mutation tool with zero annotation coverage.

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

Conciseness5/5

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

The description is extremely concise at three words, front-loading the essential action and resource without any wasted text. Every word earns its place, making it easy to parse quickly.

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

Completeness2/5

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

Given the tool's destructive nature, no annotations, and no output schema, the description is incomplete. It lacks critical information about behavioral traits (e.g., irreversibility), error handling, or what happens post-deletion. For a deletion tool, this leaves significant gaps in understanding.

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

Parameters3/5

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

The description adds no parameter semantics beyond what the schema provides. Since schema description coverage is 100% (the 'promptId' parameter is fully documented in the schema), the baseline score is 3. The description doesn't compensate with additional context like format examples or constraints.

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

Purpose4/5

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

The description clearly states the action ('Delete') and the resource ('a prompt'), making the tool's purpose immediately understandable. It distinguishes itself from siblings like 'delete-project' by specifying the resource type, though it doesn't explicitly contrast with other deletion tools. The description avoids tautology by not merely restating the name.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a prompt ID), exclusions (e.g., cannot delete if in use), or sibling tools like 'delete-project' for different resources. Usage is implied by the action but lacks explicit context.

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

get-metricsC

Get metrics data

ParametersJSON Schema

Name	Required	Description
`endDate`	No	End date in ISO format (YYYY-MM-DD)
`metricName`	No	Optional metric name to filter
`projectId`	No	Optional project ID to filter metrics
`projectName`	No	Optional project name to filter metrics
`startDate`	No	Start date in ISO format (YYYY-MM-DD)

TDQS

C2/5.0

Behavior1/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure but fails completely. 'Get metrics data' reveals nothing about whether this is a read-only operation, whether it requires authentication, what rate limits might apply, what format the data returns in, or any other behavioral characteristics. For a data retrieval tool with zero annotation coverage, this is a critical gap that leaves the agent with no understanding of how the tool behaves.

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

Conciseness5/5

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

The description is extremely concise at just three words. While this represents severe under-specification in terms of content, from a pure conciseness perspective it contains zero wasted words and is front-loaded with the core action. Every word earns its place, even though that place is inadequate for proper tool understanding.

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

Completeness1/5

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

Given a 5-parameter tool with no annotations and no output schema, the description 'Get metrics data' is completely inadequate. It provides no information about what metrics are available, what system they come from, what the return format looks like, or any behavioral characteristics. For a data retrieval tool of this complexity, the description fails to provide the minimal contextual information needed for an agent to use it effectively.

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

Parameters3/5

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

The schema description coverage is 100%, meaning all 5 parameters are well-documented in the input schema itself. The description adds absolutely no additional parameter information beyond what's already in the schema. According to the scoring rules, when schema coverage is high (>80%), the baseline score is 3 even with no parameter information in the description, which applies here.

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

Purpose2/5

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

The description 'Get metrics data' is a tautology that essentially restates the tool name 'get-metrics'. It provides no specific information about what kind of metrics, from what system, or what scope. While it includes a verb ('Get') and resource ('metrics data'), it lacks any distinguishing details that would help differentiate it from potential sibling tools or clarify its specific function beyond the obvious.

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

Usage Guidelines1/5

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

The description provides absolutely no guidance on when to use this tool versus alternatives. There are no mentions of prerequisites, appropriate contexts, or comparisons to sibling tools like 'get-trace-stats' or 'get-trace-by-id' that might handle similar data. The agent receives no help in determining when this specific metrics retrieval tool is appropriate versus other data-fetching tools in the server.

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

get-opik-examplesC

Get examples of how to use Opik Comet's API for specific tasks

ParametersJSON Schema

Name	Required	Description	Default
`task`	Yes	The task to get examples for (e.g., 'create prompt', 'analyze traces', 'monitor costs')

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves examples but doesn't describe what the output looks like (e.g., format, structure), whether it's a read-only operation, or any limitations like rate limits or authentication needs. This leaves significant gaps for an AI agent to understand how to handle the tool's behavior.

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

Conciseness5/5

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

The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly, which is ideal for conciseness.

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

Completeness2/5

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

Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., code snippets, documentation), how examples are structured, or any behavioral traits. For a tool with no structured data beyond the input schema, the description should provide more context to help an AI agent use it effectively.

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

Parameters3/5

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

The input schema has 100% description coverage, with the 'task' parameter clearly documented. The description doesn't add any additional meaning beyond what the schema provides, such as explaining the semantics of example tasks or providing usage context. With high schema coverage, the baseline score of 3 is appropriate, as the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the tool's purpose with a specific verb ('Get') and resource ('examples of how to use Opik Comet's API'), making it easy to understand what the tool does. However, it doesn't explicitly differentiate from sibling tools like 'get-opik-help' or 'get-opik-tracing-info', which might provide related but different information.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when it's appropriate (e.g., for learning API usage) or when not to use it (e.g., for direct API calls), nor does it reference sibling tools like 'get-opik-help' that might serve similar purposes.

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

get-opik-helpB

Get contextual help about Opik Comet's capabilities

ParametersJSON Schema

Name	Required	Description	Default
`subtopic`	No	Optional subtopic for more specific help
`topic`	Yes	The topic to get help about (prompts, projects, traces, metrics, or general)

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves help information, implying a read-only operation, but doesn't mention any behavioral traits like rate limits, authentication needs, or what the output format might be. This is a significant gap for a tool with no annotation coverage.

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

Conciseness5/5

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

The description is a single, efficient sentence that directly states the tool's purpose without any unnecessary words. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly.

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

Completeness3/5

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

Given the tool's low complexity (2 parameters, no output schema, no annotations), the description is minimally adequate but incomplete. It explains what the tool does but lacks details on behavioral aspects and usage context, which are important for an agent to operate effectively without annotations.

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

Parameters3/5

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

The input schema has 100% description coverage, clearly documenting both parameters ('topic' and 'subtopic') with their types and purposes. The description adds no additional meaning beyond what the schema provides, so it meets the baseline of 3 where the schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the verb 'Get' and the resource 'contextual help about Opik Comet's capabilities', making the purpose understandable. However, it doesn't specifically differentiate from sibling tools like 'get-opik-examples' or 'get-opik-tracing-info', which also provide information about Opik Comet but focus on different aspects.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives such as 'get-opik-examples' or 'get-opik-tracing-info'. It lacks explicit context, exclusions, or prerequisites, leaving the agent to infer usage based on the tool name alone.

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

get-opik-tracing-infoC

Get information about Opik's tracing capabilities and how to use them

ParametersJSON Schema

Name	Required	Description	Default
`topic`	No	Optional specific tracing topic to get information about (e.g., 'spans', 'distributed', 'multimodal', 'annotations')

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but only states what the tool does without disclosing behavioral traits. It doesn't cover aspects like whether it's a read-only operation, potential rate limits, authentication needs, or output format, which are critical for an agent to use it effectively.

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?

The description is a single, clear sentence that efficiently conveys the tool's purpose without unnecessary words. It's front-loaded and appropriately sized, though it could be slightly more structured by including brief usage hints.

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

Completeness3/5

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

Given the tool's low complexity (one optional parameter, no output schema, no annotations), the description is minimally complete but lacks depth. It explains what the tool does but doesn't provide enough context about behavior or usage relative to siblings, making it adequate but with clear gaps for an agent.

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

Parameters3/5

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

The input schema has 100% description coverage, clearly documenting the optional 'topic' parameter with examples. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline of 3 for adequate but not enhanced coverage.

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

Purpose4/5

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

The description clearly states the verb 'Get' and the resource 'information about Opik's tracing capabilities and how to use them', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-trace-by-id' or 'get-trace-stats', which also deal with tracing information but focus on specific data rather than general capabilities.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention scenarios like needing overviews versus detailed data, or how it differs from siblings such as 'get-opik-help' or 'get-opik-examples', leaving the agent to infer usage from context alone.

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

get-project-by-idC

Get a single project by ID

ParametersJSON Schema

Name	Required	Description	Default
`projectId`	Yes	ID of the project to fetch
`workspaceName`	No	Workspace name to use instead of the default

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. While 'Get' implies a read operation, it doesn't specify whether this requires authentication, what happens if the project doesn't exist, or any rate limits. The description lacks crucial behavioral context that would help an agent understand how to handle errors or what to expect from the operation.

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

Conciseness5/5

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

The description is extremely concise at just 6 words, front-loading the essential information with zero wasted words. Every word earns its place by communicating the core functionality without unnecessary elaboration.

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

Completeness2/5

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

For a read operation with 2 parameters and no output schema, the description is insufficiently complete. It doesn't explain what information the tool returns about projects, how to handle the optional workspaceName parameter, or what format the response takes. With no annotations and no output schema, the agent lacks crucial information about the tool's behavior and outputs.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already fully documents both parameters (projectId and workspaceName). The description adds no additional parameter information beyond what's in the schema. According to scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.

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

Purpose4/5

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

The description clearly states the action ('Get') and resource ('a single project by ID'), making the purpose immediately understandable. It distinguishes from sibling tools like 'list-projects' by specifying retrieval of a single item rather than a collection. However, it doesn't explicitly differentiate from 'get-prompt-by-id' or 'get-trace-by-id' which follow similar patterns.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to prefer this over 'list-projects' for single-item retrieval, or how it relates to other 'get-by-id' tools for different resource types. There's also no information about prerequisites or contextual constraints.

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

get-prompt-by-idC

Get a single prompt by ID

ParametersJSON Schema

Name	Required	Description	Default
`promptId`	Yes	ID of the prompt to fetch

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden but only states the basic action without disclosing behavioral traits. It doesn't mention if this is a read-only operation, what happens with invalid IDs (e.g., errors), authentication needs, rate limits, or return format, leaving significant gaps in transparency.

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

Conciseness5/5

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

The description is extremely concise with a single sentence that directly states the tool's purpose, making it front-loaded and free of unnecessary words. Every part of the sentence earns its place by clearly conveying the core functionality.

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

Completeness2/5

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

Given the complexity of a retrieval tool with no annotations and no output schema, the description is incomplete. It doesn't explain what data is returned (e.g., prompt content, metadata), error handling, or how it fits into the broader context of prompt management, failing to compensate for the lack of structured data.

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

Parameters3/5

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

The description adds no meaning beyond the input schema, which has 100% coverage and fully documents the 'promptId' parameter. With high schema coverage, the baseline is 3, as the schema handles parameter documentation adequately without extra detail from the description.

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

Purpose4/5

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

The description clearly states the verb 'Get' and the resource 'a single prompt by ID', making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get-project-by-id' or 'list-prompts', which would require mentioning it retrieves individual prompt details rather than projects or lists.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives such as 'list-prompts' for browsing or 'get-project-by-id' for related resources. It lacks context about prerequisites like needing a valid prompt ID or exclusions for non-existent IDs, leaving usage unclear.

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

get-server-infoB

Get information about the Opik server configuration

ParametersJSON Schema

Name	Required	Description	Default
`random_string`	No	Dummy parameter for no-parameter tools

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden. It states it 'gets' information, implying a read-only operation, but doesn't disclose behavioral traits such as authentication needs, rate limits, response format, or potential side effects. This leaves significant gaps for a tool with no annotation coverage.

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

Conciseness5/5

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

The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.

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

Completeness2/5

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

Given no annotations and no output schema, the description is incomplete. It lacks details on what specific server configuration information is returned, how it's structured, or any behavioral context. For a tool in a set with many siblings, more completeness is needed to guide effective use.

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

Parameters4/5

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

The input schema has 1 parameter with 100% coverage, describing it as a 'Dummy parameter for no-parameter tools'. The description adds no parameter information, which is acceptable since the schema fully documents the parameter, and the tool effectively has 0 functional parameters. Baseline is 3, but the dummy nature justifies a higher score for clarity.

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

Purpose4/5

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

The description clearly states the verb 'Get' and resource 'information about the Opik server configuration', making the purpose specific and understandable. However, it doesn't differentiate from sibling tools like 'get-metrics' or 'get-opik-tracing-info', which also retrieve server-related information, so it misses full sibling distinction.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get-metrics' and 'get-opik-tracing-info' that might retrieve overlapping or related server data, there's no indication of context, prerequisites, or exclusions for tool selection.

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

get-trace-by-idC

Get a single trace by ID

ParametersJSON Schema

Name	Required	Description	Default
`traceId`	Yes	ID of the trace to fetch
`workspaceName`	No	Workspace name to use instead of the default

TDQS

C2.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it's a read operation ('get'), but doesn't cover aspects like error handling (e.g., what happens if the trace ID doesn't exist), rate limits, authentication requirements, or response format. For a tool with no annotation coverage, this leaves significant gaps in understanding its behavior.

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

Conciseness5/5

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

The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose ('Get a single trace by ID'), making it immediately understandable. Every part of the sentence contributes directly to clarifying the tool's function.

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

Completeness2/5

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

Given no annotations and no output schema, the description is incomplete for a tool with 2 parameters. It lacks details on behavioral traits (e.g., error cases, permissions), return values, and usage context. While the schema covers parameters well, the overall context for safe and effective use is insufficient, especially for a read operation that might involve workspace-specific data.

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

Parameters3/5

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

Schema description coverage is 100%, with clear descriptions for both parameters: 'traceId' as the ID to fetch and 'workspaceName' as an optional override. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate.

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

Purpose4/5

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

The description 'Get a single trace by ID' clearly states the action (get) and resource (trace), with specificity about retrieving by ID. It distinguishes from siblings like 'list-traces' (multiple) and 'get-trace-stats' (statistics), though it doesn't explicitly name them. The purpose is unambiguous but lacks explicit sibling differentiation.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose it over 'list-traces' for multiple traces or 'get-trace-stats' for aggregated data, nor does it specify prerequisites like authentication or workspace context. Usage is implied by the name but not explicitly stated.

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

get-trace-statsC

Get statistics for traces

ParametersJSON Schema

Name	Required	Description
`endDate`	No	End date in ISO format (YYYY-MM-DD)
`projectId`	No	Project ID to filter traces
`projectName`	No	Project name to filter traces
`startDate`	No	Start date in ISO format (YYYY-MM-DD)
`workspaceName`	No	Workspace name to use instead of the default

TDQS

C2.7/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden but only states it 'gets' statistics without disclosing behavioral traits like read-only nature, potential rate limits, authentication needs, or what happens if parameters are omitted. It fails to compensate for the lack of annotations.

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

Conciseness5/5

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

The description is a single, efficient sentence with zero waste. It's appropriately sized and front-loaded, making it easy to parse quickly without unnecessary elaboration.

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

Completeness2/5

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

Given the tool's complexity (5 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain what statistics are returned, how they're formatted, or error conditions, leaving significant gaps for the agent to infer behavior.

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

Parameters3/5

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

Schema description coverage is 100%, so parameters are fully documented in the schema. The description adds no meaning beyond the schema, such as explaining how parameters interact or default behaviors. Baseline 3 is appropriate as the schema does the heavy lifting.

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

Purpose3/5

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

The description 'Get statistics for traces' states a clear verb ('Get') and resource ('statistics for traces'), but it's vague about what specific statistics are retrieved and doesn't distinguish from sibling tools like 'get-metrics' or 'get-trace-by-id'. It provides basic purpose but lacks specificity.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like 'get-metrics' or 'list-traces'. The description doesn't mention prerequisites, exclusions, or context for usage, leaving the agent without direction on tool selection.

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

list-projectsC

Get a list of projects/workspaces

ParametersJSON Schema

Name	Required	Description
`page`	Yes	Page number for pagination
`size`	Yes	Number of items per page
`sortBy`	No	Sort projects by this field
`sortOrder`	No	Sort order (asc or desc)
`workspaceName`	No	Workspace name to use instead of the default

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states it 'gets a list' which implies a read operation, but doesn't mention pagination behavior (implied by parameters), rate limits, authentication requirements, or what the return format looks like. For a tool with 5 parameters and no output schema, this leaves significant behavioral aspects undocumented.

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

Conciseness5/5

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

The description is extremely concise at just 5 words, front-loading the core purpose with zero wasted words. Every element ('Get', 'list', 'projects/workspaces') earns its place. No structural issues or unnecessary elaboration.

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

Completeness2/5

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

For a tool with 5 parameters, no annotations, and no output schema, the description is insufficiently complete. It doesn't explain what a 'project' or 'workspace' represents in this context, doesn't describe the return format, and provides no behavioral context. The agent would need to infer too much from just the schema parameters.

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

Parameters3/5

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

Schema description coverage is 100%, so all parameters are documented in the schema. The description adds no additional parameter information beyond what's already in the schema descriptions. It doesn't explain relationships between parameters (e.g., how 'workspaceName' interacts with the list) or provide usage examples. Baseline 3 is appropriate when schema does the heavy lifting.

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

Purpose4/5

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

The description clearly states the action ('Get a list') and resource ('projects/workspaces'), making the purpose immediately understandable. However, it doesn't distinguish between 'projects' and 'workspaces' or clarify if they're synonymous, and it doesn't differentiate from sibling tools like 'get-project-by-id' or 'list-prompts' which serve different but related purposes.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose 'list-projects' over 'get-project-by-id' for retrieving specific projects, or 'list-prompts' for different resource types. There are no prerequisites, exclusions, or context for usage decisions.

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

list-promptsC

Get a list of Opik prompts

ParametersJSON Schema

Name	Required	Description	Default
`page`	Yes	Page number for pagination
`size`	Yes	Number of items per page

TDQS

C2.9/5.0

Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool retrieves a list but doesn't mention pagination behavior (implied by parameters), rate limits, authentication needs, or what the return format looks like (no output schema). This leaves significant gaps for an agent to understand how the tool behaves.

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

Conciseness5/5

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

The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and appropriately sized for a simple list operation, making it easy for an agent to parse quickly.

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

Completeness2/5

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

For a list tool with 2 required parameters, no annotations, and no output schema, the description is insufficient. It doesn't explain pagination requirements, return format, or error conditions. Given the complexity (simple but with required params) and lack of structured data, more context is needed for the agent to use this tool effectively.

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

Parameters3/5

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

Schema description coverage is 100%, with both parameters ('page' and 'size') clearly documented in the schema. The description adds no additional parameter semantics beyond implying list retrieval, so it meets the baseline score of 3 where the schema does the heavy lifting.

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

Purpose4/5

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

The description 'Get a list of Opik prompts' clearly states the verb ('Get') and resource ('Opik prompts'), making the purpose immediately understandable. However, it doesn't distinguish this tool from its sibling 'list-projects' or 'list-traces' beyond the resource type, nor does it specify scope (e.g., all prompts vs. filtered).

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like 'get-prompt-by-id' for retrieving a specific prompt, or 'create-prompt' for adding new prompts. There's no mention of prerequisites, typical use cases, or limitations that would help an agent choose appropriately.

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

list-tracesC

Get a list of traces

ParametersJSON Schema

Name	Required	Description
`page`	Yes	Page number for pagination
`projectId`	No	Project ID to filter traces
`projectName`	No	Project name to filter traces
`size`	Yes	Number of items per page
`workspaceName`	No	Workspace name to use instead of the default

TDQS

C2.7/5.0

Behavior2/5

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

With no annotations, the description carries full burden but only states the action without disclosing behavioral traits. It doesn't mention if this is a read-only operation, pagination behavior, rate limits, authentication needs, or what the output looks like (e.g., list format, error handling). This leaves significant gaps for a tool with 5 parameters.

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

Conciseness5/5

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

The description is a single, clear sentence with no wasted words. It's front-loaded and efficiently conveys the core action, making it easy to parse quickly without unnecessary detail.

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

Completeness2/5

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

Given the tool's complexity (5 parameters, no output schema, no annotations), the description is incomplete. It doesn't explain the return values, pagination implications, or how filtering parameters interact, leaving the agent with insufficient context to use the tool effectively beyond basic invocation.

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

Parameters3/5

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

Schema description coverage is 100%, so parameters like 'page', 'size', 'projectId' are well-documented in the schema. The description adds no additional meaning beyond 'list of traces', such as explaining how filtering works or parameter interactions, meeting the baseline for high schema coverage.

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

Purpose3/5

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

The description 'Get a list of traces' states the basic action (get/list) and resource (traces), making the purpose understandable. However, it's vague about what 'traces' are (e.g., execution traces, logging traces) and doesn't distinguish from siblings like 'get-trace-by-id' or 'get-trace-stats', missing specificity for a 4-5 score.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like 'get-trace-by-id' for single traces or 'get-trace-stats' for aggregated data. The description lacks context about filtering capabilities or typical use cases, offering minimal help for selection.

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

update-projectC

Update a project

ParametersJSON Schema

Name	Required	Description
`description`	No	New project description
`name`	No	New project name
`projectId`	Yes	ID of the project to update
`workspaceName`	No	Workspace name to use instead of the default

TDQS

C2.7/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. 'Update a project' implies a mutation operation but doesn't disclose behavioral traits like required permissions, whether changes are reversible, rate limits, or what happens to unspecified fields. It lacks critical context for a write operation.

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

Conciseness5/5

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

The description is extremely concise with a single sentence, 'Update a project', which is front-loaded and wastes no words. It efficiently communicates the core action, though this brevity contributes to gaps in other dimensions.

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

Completeness2/5

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

Given the tool's complexity as a mutation with 4 parameters and no annotations or output schema, the description is incomplete. It doesn't cover behavioral aspects, usage context, or return values, leaving significant gaps for an AI agent to understand and invoke it correctly.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all parameters (projectId, name, description, workspaceName). The description adds no meaning beyond what the schema provides, such as explaining interdependencies or default behaviors. Baseline 3 is appropriate when schema does the heavy lifting.

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

Purpose3/5

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

The description 'Update a project' states the verb and resource but is vague about what aspects can be updated. It distinguishes from siblings like 'create-project' and 'delete-project' by specifying 'update', but doesn't clarify scope compared to 'update-prompt' or differentiate from partial updates vs full replacements.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives is provided. The description doesn't mention prerequisites (e.g., needing an existing project), exclusions, or comparisons to siblings like 'get-project-by-id' for read operations or 'list-projects' for discovery.

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

update-promptC

Update a prompt

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	New name for the prompt
`promptId`	Yes	ID of the prompt to update

TDQS

C2.1/5.0

Behavior1/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure but offers none. It doesn't indicate whether this is a read-only or destructive operation, what permissions are required, whether changes are reversible, what happens on success/failure, or any rate limits. For a mutation tool with zero annotation coverage, this complete lack of behavioral information is inadequate and potentially misleading.

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

Conciseness5/5

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

The description is maximally concise at just three words, with zero wasted language. Every word earns its place by identifying the core action and resource. While this conciseness comes at the expense of completeness, the structure is front-loaded and efficient from a pure brevity perspective.

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

Completeness2/5

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

Given that this is a mutation tool with no annotations and no output schema, the description is severely incomplete. It doesn't explain what 'updating' entails beyond the name parameter, what happens to other prompt attributes, what the tool returns, or any error conditions. For a tool that modifies data, this minimal description leaves critical gaps in understanding its behavior and outcomes.

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

Parameters3/5

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

The schema description coverage is 100%, with both parameters ('promptId' and 'name') clearly documented in the schema. The description adds no additional parameter information beyond what the schema already provides. According to scoring rules, when schema coverage is high (>80%), the baseline score is 3 even with no parameter information in the description, which applies here.

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

Purpose2/5

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

The description 'Update a prompt' is a tautology that restates the tool name without adding meaningful context. While it correctly identifies the verb ('update') and resource ('prompt'), it fails to specify what aspects of a prompt can be updated or distinguish this tool from sibling tools like 'update-project'. This minimal statement provides no differentiation or specificity beyond the name itself.

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

Usage Guidelines1/5

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

The description provides absolutely no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing prompt ID), exclusions, or relationships to sibling tools like 'create-prompt', 'delete-prompt', or 'get-prompt-by-id'. Without any context about appropriate usage scenarios, the agent has no basis for making informed decisions about tool selection.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.1/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose targeting specific resources (projects, prompts, traces, metrics, help) and actions (create, get, list, update, delete). There is no overlap or ambiguity between tools, making it easy for an agent to select the right one for any operation.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with hyphens (e.g., create-project, get-project-by-id, list-projects). The naming is uniform across all 19 tools, using clear verbs like create, get, list, update, and delete paired with specific nouns.

Tool Count4/5

With 19 tools, the count is slightly high but reasonable for a comprehensive server covering projects, prompts, traces, metrics, and help. It feels well-scoped for the Opik domain, though it borders on being heavy compared to typical 3-15 tool ranges.

Completeness5/5

The tool set provides complete CRUD/lifecycle coverage for projects and prompts (create, get, list, update, delete), with additional tools for traces, metrics, and help. There are no obvious gaps; agents can perform all core operations without dead ends in this domain.

Maintenance

ActivityActive

ResponsivenessUnresponsive

Resources

Need Help?

Reddit Discussion

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp COAuth
com.wix
A Model Context Protocol server for Wix AI tools
Developer Tools Content Management Systems App Automation
216
Studex MCP Server
io.github.itshivams
Model Context Protocol server for Studex tools, notifications, and profile integrations
Developer Tools
1
hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
Apideck MCP A
dev.apideck.mcp
Model Context Protocol server for the Apideck Unified API. Connect any MCP-compatible agent framework to 100+ accounting systems, HRIS platforms, file storage providers, and more through one integration. More information https://www.apideck.com/mcp-server
Developer Tools
42

Related MCP Servers

MCP Server
RAG Systems Databases File Systems
GobinFan
F
license
B
quality
D
maintenance
Implements the Model Context Protocol (MCP) to provide AI models with a standardized interface for connecting to external data sources and tools like file systems, databases, or APIs.
Updated a year ago (2025-05-05 08:18 UTC)
1
153
dap-mcp
Developer Tools Code Execution
KashunCheng
A
license
Not graded
quality
C
maintenance
An implementation of the Model Context Protocol (MCP) that enables interaction with debug adapters, allowing language models to control debuggers, set breakpoints, evaluate expressions, and navigate source code during debugging sessions.
Updated a year ago (2025-09-24 00:19 UTC)
40
AGPL 3.0
MCP Python Server
Code Execution
jatindera
F
license
Not graded
quality
D
maintenance
A Python-based implementation of the Model Context Protocol that enables communication between a model context management server and client through a request-response architecture.
Updated a year ago (2025-03-28 03:07 UTC)
Python MCP Server Template
HappyPathway
-
license
Not graded
quality
D
maintenance
A standardized foundation for building Model Context Protocol servers that integrate with VS Code, using Python with stdio transport for seamless AI tool integration.
Updated a year ago (2025-04-25 18:42 UTC)

Appeared in Searches

Exploring the Concept of Multi-Agentic Systems

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/comet-ml/opik-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server