Add log_level parameter to FastMCP errors

[daniel-tsiang]

Description

Closes #4035

Adds log_level parameter to FastMCPError and all subclasses (ToolError, ResourceError, PromptError, etc.) to control the server-side log level for expected control-flow errors.

When building multi-step LLM workflows, errors often represent normal control flow rather than bugs. For example, a tool might raise ToolError("Model not deployed, call deploy_model first") to guide the LLM's next action. These expected errors create noise in production error monitoring systems (Sentry, DataDog) that typically capture ERROR-level logs. Rather than suppressing logs entirely (losing all visibility), this lets server operators downgrade the log level so the error is still recorded but doesn't trigger alerts.

Usage

@mcp.tool
def check_model_status(model_id: str) -> dict:
  if not model_registry.is_deployed(model_id):
      raise ToolError(
          f"Model {model_id} not deployed. Call deploy_model first.",
          log_level=logging.WARNING  # Log at WARNING instead of ERROR
      )
  return model_registry.get_status(model_id)

The error still reaches the LLM client with the full message and is still logged server-side — just at the specified level instead of ERROR.

Implementation

• Added log_level: int = logging.ERROR parameter to FastMCPError.__init__
• Updated catch blocks in server.py to use logger.log(e.log_level, ..., exc_info=True) instead of logger.exception()
• Updated sampling/run.py for sampling tool errors
• Fixed pre-existing bug where function_prompt.py double-wrapped PromptError

Contribution type

• Bug fix (simple, well-scoped fix for a clearly broken behavior)
• Documentation improvement
• Enhancement (maintainers typically implement enhancements — see CONTRIBUTING.md)

Checklist

• This PR addresses an existing issue (or fixes a self-evident bug)
• I have read CONTRIBUTING.md
• I have added tests that cover my changes
• I have run uv run prek run --all-files and all checks pass
• I have self-reviewed my changes
• If I used an LLM, it followed the repo's contributing conventions (not generic output)

[claude]

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

[jlowin]

I don't think suppressing the log is the right remedy here? Perhaps allowing a custom log level override? Otherwise the server has no report that the error took place.

[daniel-tsiang]

I don't think suppressing the log is the right remedy here? Perhaps allowing a custom log level override? Otherwise the server has no report that the error took place.

@jlowin Thanks Jeremiah, great suggestion. I've amended the PR to allow a custom log level override instead. Please can you take another look?