Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
git clone --depth 1 https://github.com/drumnation/unsplash-smart-mcp-serverWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/rules/drumnation/unsplash-smart-mcp-server/functional-test-principals.rules)<a href="https://agentmods.dev/rules/drumnation/unsplash-smart-mcp-server/functional-test-principals.rules"><img src="https://agentmods.dev/badge/rules/drumnation/unsplash-smart-mcp-server/functional-test-principals.rules.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.01105 | $0.01105 |
| Opus 5 | $0.00553 | $0.00553 |
| Sonnet 5 | $0.00221 | $0.00221 |
| Haiku 4.5 | $0.00111 | $0.00111 |
Grade A, and why
functional-test-principals.rules scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 8d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 124 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Rule: Functional Test Principles
Purpose: Ensure all test suites — regardless of test framework — validate real, end-to-end or integration-level functionality. Tests must act as a backstop for the app. If they pass, the app works. If they fail, something meaningful is broken. This allows the agent to self-validate and iterate safely.
Frameworks: Mocha, Vitest, Jest, Playwright, Cypress, Storybook, etc.
The principles apply across all test environments.
Agent Behavior:
-
Test Real Use, Not Implementation
- Simulate real usage, not internals
- Validate user-visible outputs or API responses
- Never test internal method calls, hook behavior, or prop structures directly
-
Avoid Mocking
- Mock only:
- External APIs (e.g., HTTP requests)
- Uncontrollable globals (e.g., time, environment)
- Never mock internal app logic or structure just to make a test work
- Avoid testing
.mock.callsorspyOn()unless testing infrastructure-level effects
- Mock only:
-
One-to-One Principle
- If the test passes → the feature works
- If the test fails → the feature is broken, misaligned, or needs to be updated with intention
-
Tests Should Be Lightweight and Runnable Often
- Run them after every meaningful code change
- Favor a small number of high-signal tests over hundreds of shallow coverage tests
-
Use for Self-Validation
- The agent should use tests as the basis for confirming its changes are correct
- No agent-generated code should be considered complete until the relevant tests pass
-
Do Not Over-Isolate
- Avoid deep mocking that isolates a function from its context
- Prefer integration and functional tests for most features
- Unit tests should be used only for pure functions or small reusable utilities
-
Include Test Planning in Feature Design
- When writing a plan for any task or feature, include:
- What needs to be tested
- How it can be tested without mocks
- What defines success/failure
- When writing a plan for any task or feature, include:
-
Failure ≠ Delete
- If a test fails, investigate
- Fix the code if it’s a regression
- Update the test only after understanding the cause
- Never delete or bypass a test just to make the suite green
ruleType: always
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 8d ago First seen · 124 lines · 1,105 tokens per session scan A 547d26fc37a6
functional-test-principals.rules is a cursor rule published in the GitHub repository drumnation/unsplash-smart-mcp-server (63 stars, last pushed 7mo ago), licensed MIT. It adds 1,105 tokens to every session, about $0.0055 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other cursor rules, from other repositories
manual-review
The main set of rules for manual review during an active project change. It defines different kinds of checks, who performs them, how results are recorded, and when supporting evidence is required.
testing-anti-patterns
Guidelines for avoiding misleading or weak tests. They say tests should check real application behavior, use mocks only when needed for isolation, and avoid adding code to production solely for testing.
manual-review.backend
A set of rules for verifying backend-only changes and changes that use different verification channels. It separates evidence the agent can collect from checks that require a person, a production authorization, or a business decision.
screenshot-strategy
A decision guide for choosing browser tools for screenshots, exploration and repeatable checks. It explains when to use an interactive browser session and when to use Playwright, a tool for scripted browser tests.
playwright-webserver
A rule for configuring Playwright, a browser-testing tool, so its end-to-end tests can start a web server reliably in continuous integration (CI), where local environment files and tunnels may not exist.
dev-login
Dev-login routes must stay local-only while giving screenshot review and E2E a canonical way to mint test sessions.