fastmcp 2.13.2__tar.gz → 2.14.0__tar.gz

fastmcp-2.14.0/.github/workflows/martian-test-failure.yml

@@ -0,0 +1,182 @@
+name: Marvin Test Failure Analysis
+
+on:
+  workflow_run:
+    workflows: ["Tests", "Run static analysis"]
+    types:
+      - completed
+
+concurrency:
+  group: marvin-test-failure-${{ github.event.workflow_run.head_branch }}
+  cancel-in-progress: true
+
+jobs:
+  martian-test-failure:
+    # Only run if the test workflow failed
+    if: ${{ github.event.workflow_run.conclusion == 'failure' }}
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+      pull-requests: write
+      issues: read
+      id-token: write
+      actions: read # Required for Claude to read CI results
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v6
+        with:
+          fetch-depth: 1
+
+      - name: Generate Marvin App token
+        id: marvin-token
+        uses: actions/create-github-app-token@v2
+        with:
+          app-id: ${{ secrets.MARVIN_APP_ID }}
+          private-key: ${{ secrets.MARVIN_APP_PRIVATE_KEY }}
+
+      - name: Set up Python 3.10
+        uses: actions/setup-python@v6
+        with:
+          python-version: "3.10"
+
+      # Install UV package manager
+      - name: Install UV
+        uses: astral-sh/setup-uv@v7
+
+      # Install dependencies
+      - name: Install dependencies
+        run: uv sync --all-packages --group dev
+
+      - name: Set analysis prompt
+        id: analysis-prompt
+        run: |
+          cat >> $GITHUB_OUTPUT << 'EOF'
+          PROMPT<<PROMPT_END
+          You're a test failure analysis assistant for FastMCP, a Python framework for building Model Context Protocol servers and clients.
+
+          # Your Task
+          A GitHub Actions workflow has failed. Your job is to:
+          1. Analyze the test failure(s) to understand what went wrong
+          2. Identify the root cause of the failure(s)
+          3. Suggest a clear, actionable solution to fix the failure(s)
+
+          # Getting Started
+          1. Call the generate_agents_md tool to get a high-level summary of the project
+          2. Get the pull request associated with this workflow run from the GitHub repository: ${{ github.repository }}
+             - The workflow run ID is: ${{ github.event.workflow_run.id }}
+             - The workflow run was triggered by: ${{ github.event.workflow_run.event }}
+             - Use GitHub MCP tools to get PR details and workflow run information
+          3. Use the GitHub MCP tools to fetch job logs and failure information:
+             - Use get_workflow_run to get details about the failed workflow
+             - Use list_workflow_jobs to see which jobs failed
+             - Use get_job_logs with failed_only=true to get logs for failed jobs
+             - Use summarize_run_log_failures to get an AI summary of what failed
+          4. Analyze the failures to understand the root cause
+          5. Search the codebase for relevant files, tests, and implementations
+
+          # Your Response
+          Post a comment on the pull request with your analysis. Your comment should include:
+
+          ## Test Failure Analysis
+
+          **Summary**: A brief 1-2 sentence summary of what failed.
+
+          **Root Cause**: A clear explanation of why the tests failed, based on your analysis of the logs and code.
+
+          **Suggested Solution**: Specific, actionable steps to fix the failure(s). Include:
+          - Which files need to be modified
+          - What changes are needed
+          - Why these changes will fix the issue
+
+          <details>
+          <summary>Detailed Analysis</summary>
+
+          Include here:
+          - Relevant log excerpts showing the failure
+          - Code snippets that are causing the issue
+          - Any related issues or PRs that might be relevant
+          </details>
+
+          <details>
+          <summary>Related Files</summary>
+
+          List files that are relevant to the failure with brief explanations of their relevance.
+          </details>
+
+          # Important Guidelines
+          - Be concise and actionable - developers want to quickly understand and fix the issue. Provide
+            additional context, references, etc in collapsible details blocks to ensure that the comment you're adding
+            is short and easy to read but additional information is a click away.
+          - Focus on facts from the logs and code, not speculation
+          - If you can't determine the root cause, say so clearly
+          - If your only suggestion is a bad suggestion (disable the test, change the timeout, etc), indicate that you've run out of ideas and
+            that they probably don't want to do that.
+          - Provide specific file names, line numbers, and code references when possible
+          - You can run make commands (e.g., `make lint`, `make typecheck`, `make sync`) to build, test, or lint the code
+          - You can also run git commands (e.g., `git status`, `git log`, `git diff`) to inspect the repository
+          - You can use WebSearch and WebFetch to research errors, stack traces, or related issues
+          - For bash commands, you are limited to make and git commands only
+
+          # CRITICAL: ANGRY USERS
+          **IMPORTANT**: If the user is angry with you, the triage bot, don't respond. Just exit immediately without further action.
+            If at any point in the conversation the user has asked you to stop replying to the thread, just exit immediately.
+
+          If you are posting the same suggestion as you have previously made, do not post the suggestion again.
+
+          # IMPORTANT: EDIT YOUR COMMENT
+          Do not post a new comment every time you triage a failing workflow. If a previous comment has been posted by you (marvin)
+          in a previous triage, edit that comment do not add a new comment for each failure. Be sure to include a note that you've edited
+          your comment to reflect the latest analysis. Don't worry about keeping the old content around, there's comment history for 
+          that.
+
+          # Problems Encountered
+          If you encounter any problems during your analysis (e.g., unable to fetch logs, tools not working), document them clearly so the team knows what limitations you faced.
+          PROMPT_END
+          EOF
+
+      - name: Setup GitHub MCP Server
+        run: |
+          mkdir -p /tmp/mcp-config
+          cat > /tmp/mcp-config/mcp-servers.json << 'EOF'
+          {
+            "mcpServers": {
+              "repository-summary": {
+                "type": "http",
+                "url": "https://agents-md-generator.fastmcp.app/mcp"
+              },
+              "code-search": {
+                "type": "http",
+                "url": "https://public-code-search.fastmcp.app/mcp"
+              },
+              "github-research": {
+                "type": "stdio",
+                "command": "uvx",
+                "args": [
+                  "github-research-mcp"
+                ],
+                "env": {
+                  "DISABLE_SUMMARIES": "true",
+                  "GITHUB_PERSONAL_ACCESS_TOKEN": "${{ secrets.GITHUB_TOKEN }}"
+                }
+              }
+            }
+          }
+          EOF
+
+      - name: Run Claude Code
+        id: claude
+        uses: anthropics/claude-code-action@v1
+        with:
+          github_token: ${{ steps.marvin-token.outputs.token }}
+          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY_FOR_CI }}
+          bot_name: "Marvin Context Protocol"
+
+          claude_code_oauth_token: ${{ secrets.CLAUDE_CODE_OAUTH_TOKEN }}
+
+          additional_permissions: |
+            actions: read
+
+          prompt: ${{ steps.analysis-prompt.outputs.PROMPT }}
+          claude_args: |
+            --allowed-tools mcp__repository-summary,mcp__code-search,mcp__github-research,WebSearch,WebFetch,Bash(make:*,git:*)
+            --mcp-config /tmp/mcp-config/mcp-servers.json

fastmcp-2.14.0/.github/workflows/run-tests.yml

@@ -0,0 +1,112 @@
+name: Tests
+
+env:
+  # enable colored output
+  PY_COLORS: 1
+
+on:
+  push:
+    branches: ["main"]
+    paths:
+      - "src/**"
+      - "tests/**"
+      - "uv.lock"
+      - "pyproject.toml"
+      - ".github/workflows/**"
+
+  # run on all pull requests because these checks are required and will block merges otherwise
+  pull_request:
+
+  workflow_dispatch:
+
+permissions:
+  contents: read
+
+jobs:
+  run_tests:
+    name: "Run tests: Python ${{ matrix.python-version }} on ${{ matrix.os }}"
+    runs-on: ${{ matrix.os }}
+    strategy:
+      matrix:
+        os: [ubuntu-latest, windows-latest]
+        python-version: ["3.10"]
+      fail-fast: false
+    timeout-minutes: 10
+
+    steps:
+      - uses: actions/checkout@v6
+
+      - name: Install uv
+        uses: astral-sh/setup-uv@v7
+        with:
+          enable-cache: true
+          cache-dependency-glob: "uv.lock"
+          python-version: ${{ matrix.python-version }}
+
+      - name: Install FastMCP
+        # run with upgrade to always test against the latest compatible versions
+        run: uv sync --upgrade
+
+      - name: Run tests (excluding integration and client_process)
+        run: |
+          if [ "${{ matrix.os }}" == "windows-latest" ]; then
+            uv run pytest --inline-snapshot=disable tests -m "not integration and not client_process"
+          else
+            uv run pytest --inline-snapshot=disable tests -m "not integration and not client_process" --numprocesses auto --maxprocesses 4 --dist worksteal
+          fi
+        shell: bash
+
+      - name: Run client process tests separately
+        run: uv run pytest --inline-snapshot=disable tests -m "client_process" -x
+
+  run_tests_lowest_direct:
+    name: "Run tests with lowest-direct dependencies"
+    runs-on: ubuntu-latest
+    timeout-minutes: 10
+
+    steps:
+      - uses: actions/checkout@v6
+
+      - name: Install uv
+        uses: astral-sh/setup-uv@v7
+        with:
+          enable-cache: true
+          cache-dependency-glob: "uv.lock"
+          python-version: "3.10"
+
+      - name: Install FastMCP with lowest-direct resolution
+        # run with lowest-direct to test against the minimum allowed dependency versions
+        run: uv sync --resolution lowest-direct
+
+      - name: Run tests (excluding integration and client_process)
+        run: uv run --resolution lowest-direct pytest --inline-snapshot=disable tests -m "not integration and not client_process" --numprocesses auto --maxprocesses 4 --dist worksteal
+
+      - name: Run client process tests separately
+        run: uv run --resolution lowest-direct pytest --inline-snapshot=disable tests -m "client_process" -x
+
+  run_integration_tests:
+    name: "Run integration tests"
+    runs-on: ubuntu-latest
+    timeout-minutes: 10
+
+    steps:
+      - uses: actions/checkout@v6
+
+      - name: Install uv
+        uses: astral-sh/setup-uv@v7
+        with:
+          enable-cache: true
+          cache-dependency-glob: "uv.lock"
+          python-version: "3.10"
+
+      - name: Install FastMCP
+        # run with upgrade to always test against the latest compatible versions
+        run: uv sync --upgrade
+
+      - name: Run integration tests
+        # use longer per-test timeout for remote API calls (default is 5s)
+        run: uv run pytest tests -m "integration" --timeout=30 --numprocesses auto --maxprocesses 2 --dist worksteal
+        env:
+          FASTMCP_GITHUB_TOKEN: ${{ secrets.FASTMCP_GITHUB_TOKEN }}
+          FASTMCP_TEST_AUTH_GITHUB_CLIENT_ID: ${{ secrets.FASTMCP_TEST_AUTH_GITHUB_CLIENT_ID }}
+          FASTMCP_TEST_AUTH_GITHUB_CLIENT_SECRET: ${{ secrets.FASTMCP_TEST_AUTH_GITHUB_CLIENT_SECRET }}

fastmcp-2.14.0/.gitignore

@@ -0,0 +1,77 @@
+# Python-generated files
+__pycache__/
+*.py[cod]
+*$py.class
+build/
+dist/
+wheels/
+*.egg-info/
+*.egg
+MANIFEST
+.pytest_cache/
+.coverage
+htmlcov/
+.tox/
+nosetests.xml
+coverage.xml
+*.cover
+
+# Virtual environments
+.venv
+venv/
+env/
+ENV/
+.env
+
+# System files
+.DS_Store
+
+# Version file
+src/fastmcp/_version.py
+
+# Editors and IDEs
+.cursorrules
+.vscode/
+.idea/
+*.swp
+*.swo
+*~
+.project
+.pydevproject
+.settings/
+
+# Jupyter Notebook
+.ipynb_checkpoints
+
+# Type checking
+.mypy_cache/
+.dmypy.json
+dmypy.json
+.pyre/
+.pytype/
+
+# Local development
+.python-version
+.envrc
+.envrc.private
+.direnv/
+
+# Logs and databases
+*.log
+*.sqlite
+*.db
+*.ddb
+
+# Claude worktree management
+.claude-wt/worktrees
+
+# Agents
+/PLAN.md
+/TODO.md
+/STATUS.md
+
+# Common FastMCP test files
+/test.py
+/server.py
+/client.py
+/test.json

fastmcp-2.14.0/.pre-commit-config.yaml

@@ -0,0 +1,48 @@
+fail_fast: false
+
+repos:
+  - repo: https://github.com/abravalheri/validate-pyproject
+    rev: v0.24.1
+    hooks:
+      - id: validate-pyproject
+
+  - repo: https://github.com/pre-commit/mirrors-prettier
+    rev: v3.1.0
+    hooks:
+      - id: prettier
+        types_or: [yaml, json5]
+
+  - repo: https://github.com/astral-sh/ruff-pre-commit
+    # Ruff version.
+    rev: v0.12.1
+    hooks:
+      # Run the linter.
+      - id: ruff-check
+        args: [--fix, --exit-non-zero-on-fix]
+      # Run the formatter.
+      - id: ruff-format
+
+  - repo: local
+    hooks:
+      - id: ty
+        name: ty check
+        entry: uv run --isolated ty check
+        language: system
+        types: [python]
+        files: ^src/|^tests/
+        pass_filenames: false
+        require_serial: true
+
+  - repo: https://github.com/pre-commit/pre-commit-hooks
+    rev: v6.0.0
+    hooks:
+      - id: no-commit-to-branch
+        name: prevent commits to main
+        args: [--branch, main]
+
+  - repo: https://github.com/codespell-project/codespell
+    rev: v2.4.1
+    hooks:
+      - id: codespell # See pyproject.toml for args
+        additional_dependencies:
+          - tomli

fastmcp-2.14.0/AGENTS.md

@@ -0,0 +1,266 @@
+# FastMCP Development Guidelines
+
+> **Audience**: LLM-driven engineering agents and human developers
+
+FastMCP is a comprehensive Python framework (Python ≥3.10) for building Model Context Protocol (MCP) servers and clients. This is the actively maintained v2.0 providing a complete toolkit for the MCP ecosystem.
+
+## Required Development Workflow
+
+**CRITICAL**: Always run these commands in sequence before committing:
+
+```bash
+uv sync                              # Install dependencies
+uv run prek run --all-files          # Ruff + Prettier + ty
+uv run pytest                        # Run full test suite
+```
+
+**All three must pass** - this is enforced by CI. Alternative: `just build && just typecheck && just test`
+
+**Tests must pass and lint/typing must be clean before committing.**
+
+## Repository Structure
+
+| Path               | Purpose                                                                             |
+| ------------------ | ----------------------------------------------------------------------------------- |
+| `src/fastmcp/`     | Library source code (Python ≥ 3.10)                                                 |
+| `├─server/`        | Server implementation, `FastMCP`, auth, networking                                  |
+| `│  ├─auth/`       | Authentication providers (Google, GitHub, Azure, AWS, WorkOS, Auth0, JWT, and more) |
+| `│  └─middleware/` | Error handling, logging, rate limiting                                              |
+| `├─client/`        | High-level client SDK + transports                                                  |
+| `│  └─auth/`       | Client authentication (Bearer, OAuth)                                               |
+| `├─tools/`         | Tool implementations + `ToolManager`                                                |
+| `├─resources/`     | Resources, templates + `ResourceManager`                                            |
+| `├─prompts/`       | Prompt templates + `PromptManager`                                                  |
+| `├─cli/`           | FastMCP CLI commands (`run`, `dev`, `install`)                                      |
+| `├─contrib/`       | Community contributions (bulk caller, mixins)                                       |
+| `├─experimental/`  | Experimental features (sampling handlers)                                           |
+| `└─utilities/`     | Shared utilities (logging, JSON schema, HTTP)                                       |
+| `tests/`           | Comprehensive pytest suite with markers                                             |
+| `docs/`            | Mintlify documentation (published to gofastmcp.com)                                 |
+| `examples/`        | Runnable demo servers (echo, smart_home, atproto)                                   |
+
+## Core MCP Objects
+
+When modifying MCP functionality, changes typically need to be applied across all object types:
+
+- **Tools** (`src/tools/` + `ToolManager`)
+- **Resources** (`src/resources/` + `ResourceManager`)
+- **Resource Templates** (`src/resources/` + `ResourceManager`)
+- **Prompts** (`src/prompts/` + `PromptManager`)
+
+## Writing Style
+
+- Be brief and to the point. Do not regurgitate information that can easily be gleaned from the code, except to guide the reader to where the code is located.
+- **NEVER** use "This isn't..." or "not just..." constructions. State what something IS directly. Avoid defensive writing patterns like:
+  - "This isn't X, it's Y" or "Not just X, but Y" → Just say "This is Y"
+  - "Not just about X" → State the actual purpose
+  - "We're not doing X, we're doing Y" → Just explain what you're doing
+  - Any variation of explaining what something isn't before what it is
+
+## Testing Best Practices
+
+### Testing Standards
+
+- Every test: atomic, self-contained, single functionality
+- Use parameterization for multiple examples of same functionality
+- Use separate tests for different functionality pieces
+- **ALWAYS** Put imports at the top of the file, not in the test body
+- **NEVER** add `@pytest.mark.asyncio` to tests - `asyncio_mode = "auto"` is set globally
+- **ALWAYS** run pytest after significant changes
+
+### Inline Snapshots
+
+FastMCP uses `inline-snapshot` for testing complex data structures. On first run with empty `snapshot()`, pytest will auto-populate the expected value when running `pytest --inline-snapshot=create`. To update snapshots after intentional changes, run `pytest --inline-snapshot=fix`. This is particularly useful for testing JSON schemas and API responses.
+
+### Always Use In-Memory Transport
+
+Pass FastMCP servers directly to clients for testing:
+
+```python
+mcp = FastMCP("TestServer")
+
+@mcp.tool
+def greet(name: str) -> str:
+    return f"Hello, {name}!"
+
+# Direct connection - no network complexity
+async with Client(mcp) as client:
+    result = await client.call_tool("greet", {"name": "World"})
+```
+
+Only use HTTP transport when explicitly testing network features:
+
+```python
+# Network testing only
+async with Client(transport=StreamableHttpTransport(server_url)) as client:
+    result = await client.ping()
+```
+
+## Development Rules
+
+### Git & CI
+
+- Prek hooks are required (run automatically on commits)
+- Never amend commits to fix prek failures
+- Apply PR labels: bugs/breaking/enhancements/features
+- Improvements = enhancements (not features) unless specified
+- **NEVER** force-push on collaborative repos
+- **ALWAYS** run prek before PRs
+- **NEVER** create a release, comment on an issue, or open a PR unless specifically instructed to do so.
+
+### Commit Messages and Agent Attribution
+
+- **Agents NOT acting on behalf of @jlowin MUST identify themselves** (e.g., "🤖 Generated with Claude Code" in commits/PRs)
+- Keep commit messages brief - ideally just headlines, not detailed messages
+- Focus on what changed, not how or why
+- Always read issue comments for follow-up information (treat maintainers as authoritative)
+
+### PR Messages - Required Structure
+
+- 1-2 paragraphs: problem/tension + solution (PRs are documentation!)
+- Focused code example showing key capability
+- **Avoid:** bullet summaries, exhaustive change lists, verbose closes/fixes, marketing language
+- **Do:** Be opinionated about why change matters, show before/after scenarios
+- Minor fixes: keep body short and concise
+- No "test plan" sections or testing summaries
+
+### Code Standards
+
+- Python ≥ 3.10 with full type annotations
+- Follow existing patterns and maintain consistency
+- **Prioritize readable, understandable code** - clarity over cleverness
+- Avoid obfuscated or confusing patterns even if they're shorter
+- Use `# type: ignore[attr-defined]` in tests for MCP results instead of type assertions
+- Each feature needs corresponding tests
+
+### Documentation
+
+- Uses Mintlify framework
+- Files must be in docs.json to be included
+- Never modify `docs/python-sdk/**` (auto-generated)
+- **Core Principle:** A feature doesn't exist unless it is documented!
+
+### Documentation Guidelines
+
+- **Code Examples:** Explain before showing code, make blocks fully runnable (include imports)
+- **Structure:** Headers form navigation guide, logical H2/H3 hierarchy
+- **Content:** User-focused sections, motivate features (why) before mechanics (how)
+- **Style:** Prose over code comments for important information
+
+## Code Review Guidelines
+
+### Philosophy
+
+Code review is about maintaining a healthy codebase while helping contributors succeed. The burden of proof is on the PR to demonstrate it adds value in the intended way. Your job is to help it get there through actionable feedback.
+
+**Critical**: A perfectly written PR that adds unwanted functionality must still be rejected. The code must advance the codebase in the intended direction, not just be well-written. When rejecting, provide clear guidance on how to align with project goals.
+
+Be friendly and welcoming while maintaining high standards. Call out what works well - this reinforces good patterns. When code needs improvement, be specific about why and how to fix it. Remember that PRs serve as documentation for future developers.
+
+### Focus On
+
+- **Does this advance the codebase in the intended direction?** (Even perfect code for unwanted features should be rejected)
+- **API design and naming clarity** - Identify confusing patterns (e.g., parameter values that contradict defaults) or non-idiomatic code (mutable defaults, etc.). Contributed code will need to be maintained indefinitely, and by someone other than the author (unless the author is a maintainer).
+- **Suggest specific improvements**, not generic "add more tests" comments
+- **Think about API ergonomics and learning curve** from a user perspective
+
+### For Agent Reviewers
+
+- **Read the full context**: Always examine related files, tests, and documentation before reviewing
+- **Check against established patterns**: Look for consistency with existing codebase conventions
+- **Verify functionality claims**: Don't just read code - understand what it actually does
+- **Consider edge cases**: Think through error conditions and boundary scenarios
+
+### Avoid
+
+- Generic feedback without specifics
+- Hypothetical problems unlikely to occur
+- Nitpicking organizational choices without strong reason
+- Summarizing what the PR already describes
+- Star ratings or excessive emojis
+- Bikeshedding style preferences when functionality is correct
+- Requesting changes without suggesting solutions
+- Focusing on personal coding style over project conventions
+
+### Tone
+
+- Acknowledge good decisions ("This API design is clean")
+- Be direct but respectful
+- Explain impact ("This will confuse users because...")
+- Remember: Someone else maintains this code forever
+
+### Decision Framework
+
+Before approving, ask yourself:
+
+1. Does this PR achieve its stated purpose?
+2. Is that purpose aligned with where the codebase should go?
+3. Would I be comfortable maintaining this code?
+4. Have I actually understood what it does, not just what it claims?
+5. Does this change introduce technical debt?
+
+If something needs work, your review should help it get there through specific, actionable feedback. If it's solving the wrong problem, say so clearly.
+
+### Review Comment Examples
+
+**Good Review Comments:**
+
+❌ "Add more tests"  
+✅ "The `handle_timeout` method needs tests for the edge case where timeout=0"
+
+❌ "This API is confusing"  
+✅ "The parameter name `data` is ambiguous - consider `message_content` to match the MCP specification"
+
+❌ "This could be better"  
+✅ "This approach works but creates a circular dependency. Consider moving the validation to `utils/validators.py`"
+
+### Review Checklist
+
+Before approving, verify:
+
+- [ ] All required development workflow steps completed (uv sync, prek, pytest)
+- [ ] Changes align with repository patterns and conventions
+- [ ] API changes are documented and backwards-compatible where possible
+- [ ] Error handling follows project patterns (specific exception types)
+- [ ] Tests cover new functionality and edge cases
+
+## Key Tools & Commands
+
+### Environment Setup
+
+```bash
+git clone <repo>
+cd fastmcp
+uv sync                    # Installs all deps including dev tools
+```
+
+### Validation Commands (Run Frequently)
+
+- **Linting**: `uv run ruff check` (or with `--fix`)
+- **Type Checking**: `uv run ty check`
+- **All Checks**: `uv run prek run --all-files`
+
+### Testing
+
+- **Standard**: `uv run pytest`
+- **Integration**: `uv run pytest -m "integration"`
+- **Excluding markers**: `uv run pytest -m "not integration and not client_process"`
+
+### CLI Usage
+
+- **Run server**: `uv run fastmcp run server.py`
+- **Inspect server**: `uv run fastmcp inspect server.py`
+
+## Critical Patterns
+
+### Error Handling
+
+- Never use bare `except` - be specific with exception types
+- Use `# type: ignore[attr-defined]` in tests for MCP results
+
+### Build Issues (Common Solutions)
+
+1. **Dependencies**: Always `uv sync` first
+2. **Prek fails**: Run `uv run prek run --all-files` to see failures
+3. **Type errors**: Use `uv run ty check` directly, check `pyproject.toml` config
+4. **Test timeouts**: Default 5s - optimize or mark as integration tests