|
| 1 | +# AGENTS.md |
| 2 | + |
| 3 | +## Purpose |
| 4 | + |
| 5 | +This file is the agent-facing guide for the `McpServer` Matomo plugin. |
| 6 | + |
| 7 | +Use it to discover the codebase quickly, make targeted changes, and extend the plugin without breaking existing MCP behavior or drifting from the current structure. |
| 8 | + |
| 9 | +This document is repo-specific. Prefer it over generic Matomo assumptions when working in this repository. |
| 10 | + |
| 11 | +## Scope And Defaults |
| 12 | + |
| 13 | +- Optimize for small, targeted changes. |
| 14 | +- Preserve existing structure and naming unless a refactor is explicitly requested. |
| 15 | +- Treat checked-in `vendor/` code as read-only unless the task is explicitly about dependency or vendor refresh. |
| 16 | +- Do not duplicate README setup/product documentation unless the change requires agent execution context. |
| 17 | +- Treat `README.md` as public-facing documentation. Keep the `## Description` section suitable for Matomo Marketplace display, and keep repository-structure or agent workflow guidance in `AGENTS.md` instead. |
| 18 | + |
| 19 | +## Repository Map |
| 20 | + |
| 21 | +### Plugin entrypoints and metadata |
| 22 | + |
| 23 | +- `API.php`: main MCP API endpoint, request validation flow, auth/error handling, and hand-off into the server. |
| 24 | +- `McpServer.php`: plugin lifecycle hooks, stylesheet registration, install/uninstall table setup. |
| 25 | +- `McpServerFactory.php`: server/container wiring and MCP server construction. |
| 26 | +- `SystemSettings.php`: plugin settings, including MCP enablement. |
| 27 | +- `plugin.json`, `composer.json`: plugin metadata and PHP dependency constraints. |
| 28 | + |
| 29 | +### MCP capability surface |
| 30 | + |
| 31 | +- `McpTools/`: user-facing MCP tools. Start here for new capabilities or changes to tool behavior. |
| 32 | +- `Schemas/`: tool output schemas grouped by domain (`Sites`, `Reports`, `Goals`, `Segments`, `Dimensions`). |
| 33 | +- `Contracts/`: shared typed records and ports. Use these when a boundary needs an explicit typed contract. |
| 34 | + |
| 35 | +### Domain and infrastructure layers |
| 36 | + |
| 37 | +- `Services/`: domain/query logic and Matomo-facing gateways, grouped by feature area. |
| 38 | +- `Support/Api/`: endpoint boundary helpers, request-id extraction, JSON-RPC error responses, and MCP endpoint rules. |
| 39 | +- `Support/`: shared pagination, normalization, logging, tooling helpers, and error mapping. |
| 40 | +- `Server/`: MCP server handler support. |
| 41 | +- `Session/`: MCP session persistence and session table management. |
| 42 | + |
| 43 | +### Verification and maintenance |
| 44 | + |
| 45 | +- `tests/Integration/`: primary coverage for externally visible behavior and cross-layer plugin behavior. |
| 46 | +- `tests/Unit/`: focused unit coverage for isolated logic. |
| 47 | +- `tests/Framework/`: shared test helpers and contract assertions. |
| 48 | +- `.github/workflows/`: CI expectations for plugin tests, PHPCS, PHPStan, and checklist gates. |
| 49 | +- `phpcs.xml`, `phpstan.neon`: local code-quality configuration for this plugin. |
| 50 | + |
| 51 | +## Where To Start |
| 52 | + |
| 53 | +### If the task touches endpoint behavior, auth, or request boundaries |
| 54 | + |
| 55 | +Start with `API.php` and `Support/Api/`. Follow the current request flow before editing: |
| 56 | + |
| 57 | +1. request format and endpoint validation |
| 58 | +2. request parsing / JSON-RPC metadata extraction |
| 59 | +3. auth and access checks |
| 60 | +4. MCP enabled/disabled behavior |
| 61 | +5. server transport hand-off |
| 62 | + |
| 63 | +Check existing integration tests before changing any of these behaviors. Start with `tests/Integration/McpApiEndpointBoundaryTest.php`. |
| 64 | + |
| 65 | +### If the task adds or changes an MCP tool |
| 66 | + |
| 67 | +Start in `McpTools/`, then trace the matching implementation in `Services/` and `Schemas/`. |
| 68 | + |
| 69 | +Preferred flow: |
| 70 | + |
| 71 | +1. tool class defines the user-facing capability |
| 72 | +2. service or gateway code fetches/transforms Matomo data |
| 73 | +3. schema defines the output contract |
| 74 | +4. tests cover the visible behavior |
| 75 | + |
| 76 | +### If the task changes domain behavior |
| 77 | + |
| 78 | +Find the domain area under `Services/Sites`, `Services/Reports`, `Services/Goals`, `Services/Segments`, `Services/Dimensions`, or `Services/System`. |
| 79 | + |
| 80 | +Before editing: |
| 81 | + |
| 82 | +- find the integration tests that currently cover the behavior |
| 83 | +- check for matching records or ports in `Contracts/` |
| 84 | +- check for supporting pagination, normalization, or error helpers in `Support/` |
| 85 | + |
| 86 | +## Extension Rules |
| 87 | + |
| 88 | +### Adding new MCP capabilities |
| 89 | + |
| 90 | +- Add user-facing capability through a tool class in `McpTools/`. |
| 91 | +- Keep Matomo/core access in focused services or gateway classes under `Services/`. |
| 92 | +- Define or update output schemas in `Schemas/`. |
| 93 | +- Use `Contracts/` only when a shared typed record or service boundary improves clarity. |
| 94 | + |
| 95 | +### Keeping boundaries clean |
| 96 | + |
| 97 | +- Do not move Matomo access logic into tool classes when it belongs in services. |
| 98 | +- Do not bypass existing support helpers if pagination, normalization, logging, or error mapping already has a home. |
| 99 | +- Prefer matching existing domain grouping and naming patterns over inventing a new layout for a small feature. |
| 100 | + |
| 101 | +### Testing expectations for new behavior |
| 102 | + |
| 103 | +- Cover externally visible behavior with integration tests first. |
| 104 | +- Add unit tests for isolated logic where they provide fast, focused regression coverage. |
| 105 | +- Do not introduce new public behavior without matching tests. |
| 106 | + |
| 107 | +## Verification Expectations |
| 108 | + |
| 109 | +### For code changes |
| 110 | + |
| 111 | +Treat all of the following as the default verification bar: |
| 112 | + |
| 113 | +- run the full plugin test suite |
| 114 | +- run targeted tests for the touched behavior when focused coverage exists |
| 115 | +- run PHPStan with this plugin's configuration |
| 116 | +- run PHPCS with this plugin's rules |
| 117 | + |
| 118 | +The full plugin suite is required for code changes to reduce the chance of breaking unrelated MCP tools or shared plugin behavior. |
| 119 | + |
| 120 | +### For docs-only changes |
| 121 | + |
| 122 | +Lighter verification is acceptable. Full plugin-suite execution is not required for product or README copy edits unless the documentation change affects engineering instructions that should be validated against the codebase. |
| 123 | + |
| 124 | +## Guardrails |
| 125 | + |
| 126 | +- Prefer small, reviewable changes over cross-cutting rewrites. |
| 127 | +- Avoid broad refactors during feature work unless explicitly requested. |
| 128 | +- Preserve existing public behavior unless the task explicitly changes it. |
| 129 | +- Keep agent guidance and implementation guidance aligned with current repo truth. |
| 130 | +- When unsure where code belongs, choose the existing nearest feature area instead of creating a new abstraction layer by default. |
0 commit comments