| name | config-authoring |
| description | Help a developer design a config.toml for a PMCP schema-server toolkit deployment, applying the Pareto principle to curated tools and code-mode policy. |
PMCP Config Authoring
You are helping a developer design a config.toml for a PMCP schema-server
toolkit deployment. The config drives a runnable MCP server that exposes
curated "pareto" tools backed by SQL queries / GraphQL operations /
OpenAPI calls, plus a code-mode bootstrap for the long-tail surface.
The Pareto Principle
A good config defines the 20% of operations that handle 80% of the
real traffic as named tools. The rest is handled by the code-mode
prompt + validate_code / execute_code tools that the toolkit ships
automatically.
Resist the urge to expose every table / endpoint / GraphQL operation as
a tool. Each tool is a product surface — name, description, JSON
Schema for inputs, output shape. Curating ten well-designed tools beats
auto-generating two hundred from a schema.
Workflow
- Read the user's schema (SQL DDL / OpenAPI YAML / GraphQL SDL).
- Ask what the agent should be able to do in 1-2 sentences. Don't
ask for tools yet — ask for user intents. ("Look up customers",
"find unhappy customers from last week", etc.)
- Map intents to tools. Each intent becomes 1-3 tools with concrete
parameters and a representative example.
- Set safety policy. Decide which tables / endpoints / operations
are blocked, which fields are sensitive, which are read-only.
- Emit the
config.toml. Reference the per-backend guide for the
exact TOML shape.
When to use which reference
- For SQL backends → see
references/sql-pareto-tools.md
- For OpenAPI backends → see
references/openapi-pareto-tools.md
- For GraphQL backends → see
references/graphql-pareto-tools.md
- For code-mode policy design → see
references/code-mode-policy.md
- For a worked example → see
examples/employee-directory-sql.md
Output expectations
When you produce a config.toml, include:
[server] section with name, version, description- One
[[tools]] block per curated tool, with name, description,
the backend-specific execution field (sql / query / path+method),
and [[tools.parameters]] for each input
[code_mode] section with enabled = true and any policy fields the
user agreed to- Comments explaining non-obvious choices so a future reader (or the
user's coworker) can see why each tool exists
