# OpenAPI MCP Provenance and Why Skipped Tools Matter

**Short answer:** A generated server shows exactly which operation and schema produced each tool, and surfaces the operations it skipped because their metadata was incomplete. A catalog server is opaque: you trust the author and discover weak tools at runtime. Provenance is the difference between a tool you can audit and a black box.

## What provenance gives you

Every tool traces to an operation, its operationId, and the request schema. When an agent calls a tool, you can see the exact endpoint behind it. That is the level of confidence you need for a service you own.

## Why skipped tools matter more than missing ones

A skipped tool is visible: the studio tells you an operation was not compiled, usually because it lacks an operationId or has ambiguous metadata. You can fix the contract and regenerate. A silently weak tool is worse — it exists, the agent calls it, and it fails because its parameters were guessed.

## The contrast with a catalog

| Property | Catalog server | Generated server |
| --- | --- | --- |
| Tool origin | Trust the author | Visible per tool |
| Weak tools | Found at runtime | Surfaced at build |
| Fix | Wait on the author | Edit the spec, regenerate |

## The discipline

Review the tool list and the skipped entries before pointing an agent at the server. The skipped tools are a punch list for the contract, not a defect to ignore.

This is part of the [Powerduck vs Smithery comparison](https://www.powerduck.com/blog/powerduck-vs-smithery/). Finish with [registry vs local-first](https://www.powerduck.com/blog/mcp-registry-vs-local-first-mcp/).