Architecture / Automation
Cookidoo MCP or browser automation?
Both are useful, but for different jobs: use stable, validated MCP tools for supported operations and a signed-in browser for observing behavior that is not understood yet.
Short answer
Prefer Cookidoo MCP whenever a supported tool exists. Its inputs, outputs, validation, error handling, and tests are designed for the task. Use a browser to discover an unsupported network contract or review visual state, then move repeatable work into the tested service.
Side by side
Choose based on the kind of uncertainty
| Question | Cookidoo MCP | Browser automation |
|---|---|---|
| Best at | Known recipe, planning, shopping-list, image, and guided-cooking operations | Exploring an unsupported screen or changed request |
| Input | Explicit IDs, dates, booleans, and validated JSON | Visible controls, page state, and UI text |
| Output | Structured or deliberately formatted data | Rendered page state and captured network behavior |
| Regression signal | Unit tests plus scheduled live API contracts | A UI flow can fail after layout or label changes |
| Visual context | Limited to API data and supported image upload | Strong: can inspect illustrations, editor state, and visual confirmations |
| Normal role | Repeatable account workflow | Research, unsupported work, or human-facing review |
Simple rule
Use the narrowest reliable interface
- If a Cookidoo MCP tool already performs the operation, use it.
- If the tool fails, inspect the exact error and relevant contract test before opening a browser.
- If the operation is unsupported or the API contract has changed, use an authenticated browser to observe the real request.
- Implement the confirmed request in
cookidoo_service.py, expose a small MCP tool, and add tests. - Return to the MCP for normal use.
This keeps repeated operations explicit, testable, and easier for another AI or maintainer to understand.
Example
How image upload moved from browser research to an MCP tool
An external image URL was rejected because Cookidoo accepts a customer-recipe image key, not an arbitrary URL. Browser network observation revealed a signed upload flow: request a short-lived signature, upload the normalized image to Cookidoo’s Cloudinary account, then PATCH the returned key into the private recipe.
That flow is now implemented as upload_custom_recipe_image, normalizes supported local images to JPEG, enforces the documented 10 MB limit, and is covered by tests. The browser is no longer needed for routine image attachment.
What does not change
Every write still needs discipline
A purpose-built API is less ambiguous, but it is not permission to make broad changes. For recipes and calendars, resolve the exact target, read current state where relevant, show the intended change, apply the smallest write, and verify the result.
Direct answers
Frequently asked questions
Does Cookidoo MCP replace the Cookidoo website?
No. Cookidoo MCP provides purpose-built actions for supported automation. The website remains useful for browsing, visual review, and unsupported account operations.
When should an AI use a browser with Cookidoo?
Use an authenticated browser to investigate an unsupported operation or changed API contract. Once understood, implement and test it in the service instead of leaving browser automation as the normal workflow.
Is an MCP tool automatically safe?
No. A typed tool reduces ambiguity, but writes still require an exact target, current-state read, scoped change, validation, and verification.
Authored by the Cookidoo MCP maintainers. Architecture guidance reflects the repository’s canonical API-first rule and current tool coverage as of 29 July 2026.