MCP Coding Standards and Style Guides

Without a shared style guide, MCP tool names drift fast — one server exposes get_user, another fetchUser. Consistency matters more here than in typical APIs because the LLM is choosing tool names from a list, not calling a hardcoded function.

Naming Conventions

• Tool names: snake_case, verb-first (list_repositories, not repositories)
• Resource URIs: consistent scheme prefix, e.g. db://table/id
• Descriptions: one sentence stating what the tool does and when to use it, written for the model, not the developer

Error Message Formatting

Return structured errors the model can reason about: an error code, a human-readable message, and — where useful — a suggested next tool call. Avoid stack traces in the response payload.

Community Style Guides

Several community-maintained ESLint and Ruff configs enforce these conventions automatically. Share yours in the comments if you've built one for your stack.