chore: Define (not only) AI contributions

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -3,6 +3,13 @@ description: Report a bug or issue with the Apify MCP server
 title: "[Bug]: "
 labels: ["bug","t-ai"]
 body:
+  - type: markdown
+    attributes:
+      value: |
+        Reproduce it yourself before filing, and write the report in your own words. If an AI tool
+        found it or drafted this, say how it helped and trim its output — see
+        [AI-assisted contributions](https://github.com/apify/apify-mcp-server/blob/master/CONTRIBUTING.md#ai-assisted-contributions).
+
   - type: dropdown
     id: server-type
     attributes:
@@ -45,7 +52,7 @@ body:
     id: description
     attributes:
       label: What happened?
-      description: What did you do, what went wrong, and what did you expect instead?
+      description: What did you do, what went wrong, and what did you expect instead? Does it happen every time?
       placeholder: "Describe the issue..."
     validations:
       required: true

.github/ISSUE_TEMPLATE/feature_request.yml

@@ -3,21 +3,34 @@ description: Suggest a new feature or improvement
 title: "[Feature]: "
 labels: ["enhancement"]
 body:
+  - type: markdown
+    attributes:
+      value: |
+        **Describe the problem, not the implementation.** We decide what gets built — don't send a
+        pull request for this; if we want your help, we'll ask here. Write it in your own words, see
+        [Before you write code](https://github.com/apify/apify-mcp-server/blob/master/CONTRIBUTING.md#before-you-write-code).
+
   - type: textarea
     id: problem
     attributes:
       label: Problem or motivation
-      description: What problem does this solve? Why do you need it?
+      description: >-
+        What can't you do today, and who else hits it? Be concrete — include the error,
+        the client you're using, how often it happens, or a link to where it came up.
+        If it happened in a chat, include the relevant part of the AI conversation.
+        "Users are confused" is weak; "3 users reported X in #channel" is strong.
     validations:
       required: true
 
   - type: textarea
-    id: solution
+    id: outcome
     attributes:
-      label: Proposed solution
-      description: How would you like it to work?
+      label: What would good look like?
+      description: >-
+        The outcome you need, not the implementation. If you have a concrete design in mind
+        you're welcome to add it, but the problem above is the part we need.
     validations:
-      required: true
+      required: false
 
   - type: textarea
     id: alternatives

.github/pull_request_template.md

@@ -4,6 +4,8 @@
 
 <!-- Human author: an AI draft is a draft, not a description. Before requesting review: (1) self-review your own diff in the GitHub UI, (2) check every claim below against the diff and cut what you wouldn't say yourself, (3) write "Notes for reviewers" in your own words. -->
 
+> **Outside contributors:** maintainers implement unassigned issues. Unless this is a documentation fix or a maintainer asked you to write it, close this and [open an issue](https://github.com/apify/apify-mcp-server/issues) instead. A reproduction is more useful than a patch. See [Before you write code](https://github.com/apify/apify-mcp-server/blob/master/CONTRIBUTING.md#before-you-write-code). Using AI? [Disclose it and show proof](https://github.com/apify/apify-mcp-server/blob/master/CONTRIBUTING.md#ai-assisted-contributions).
+
 ## Why
 <!-- "Closes #123". No issue? Ad-hoc is the exception, not the default — one line on the problem and why the change is needed. Evidence beats adjectives: a measurement, a failing run, a probe result. -->
 

AGENTS.md

@@ -2,6 +2,8 @@
 
 TypeScript, ES modules. Runs in two modes: **stdio** (local CLI clients, `stdio.ts`) and **HTTP Streamable** (`dev_server.ts`).
 
+**Before implementing**: work from an issue that is assigned or explicitly agreed. An open issue is not an invitation — many are stale or unrefined, and the fix isn't settled. If nobody asked for this change, open an issue instead of a PR (docs fixes excepted). Disclose AI use in the PR; never add a model as co-author. See [CONTRIBUTING.md](./CONTRIBUTING.md#before-you-write-code).
+
 ### Communication style — MANDATORY
 
 **This applies to ALL written output: code comments, commit messages, PR descriptions, issue specs**

CONTRIBUTING.md

@@ -5,6 +5,43 @@ All pull requests are subject to automated and manual review against these guide
 
 ---
 
+## Before you write code
+
+**Send us the problem, not the patch.**
+
+Generating a patch is cheap; validating the right patch takes maintainer time. A pull request with no agreed problem behind it is a proposal we must reverse-engineer from a diff, so we will close it.
+
+### 1. Open an issue
+
+Use the templates — [bug report](https://github.com/apify/apify-mcp-server/issues/new?template=bug_report.yml) or [feature request](https://github.com/apify/apify-mcp-server/issues/new?template=feature_request.yml) — and include relevant versions, configuration, and logs. They turn a report into a fix.
+
+Two things the form can't enforce:
+
+- **Evidence over adjectives.** "Users are confused" is weak; "3 users hit this on Claude Desktop, log attached" is strong.
+- **Write it yourself.** A pasted agent transcript is not an issue. Trim it to the point first.
+
+### 2. We take it from there
+
+**An open issue is not an invitation to implement it.** Some are unrefined, stale, or parked because the right fix is not settled. We decide what gets built and when — filing a good issue *is* the contribution.
+
+Two exceptions: **documentation fixes** (typos, broken links, wrong commands) go straight to a PR, and **work a maintainer invited you to do** — scope it to that issue and link it with `Closes #123`.
+
+---
+
+## AI-assisted contributions
+
+AI tools are welcome — we use them, and this repo ships [`AGENTS.md`](./AGENTS.md) for them. These rules are about accountability, and they don't replace the issue-first process above.
+
+- **Reviewers talk to you, not your agent.** Answer review comments in your own words.
+- **Disclose AI assistance.** In the issue or PR description, name the tool and what it did. Do not add a model as a co-author.
+- **Show it works.** Include a test, an `mcpc` transcript, a screenshot, or an Actor run. Green CI alone is not enough.
+- **Do not post automated AI review comments** on your PR or other people's.
+- **Verify issues yourself.** Don't file a bug an agent "found" without reproducing it, and never file a speculative security report.
+
+Contributions that ignore this are closed with a link here. Repeated low-effort submissions lead to restricted participation.
+
+---
+
 ## Branch naming
 
 The default branch is `master`. Feature branches must follow the `type/short-description` format, where `type` matches the conventional commit type:

README.md

@@ -548,14 +548,14 @@ For full details on data collection, usage, sharing, and retention, see [Apify L
 
 # 🤝 Contributing
 
-We welcome contributions to improve the Apify MCP Server! Here's how you can help:
+We welcome bug reports, feature requests, and documentation fixes. **Send us the problem, not the patch** — a precise issue with a reproduction is more useful than a pull request.
 
-- **🐛 Report issues**: Find a bug or have a feature request? [Open an issue](https://github.com/apify/apify-mcp-server/issues).
-- **🔧 Submit pull requests**: Fork the repo and submit pull requests with enhancements or fixes.
-- **📚 Documentation**: Improvements to docs and examples are always welcome.
-- **💡 Share use cases**: Contribute examples to help other users.
+- **🐛 Report a bug**: [Open an issue](https://github.com/apify/apify-mcp-server/issues) with a reproduction. The most useful thing you can send us.
+- **💡 Propose a feature**: [Open an issue](https://github.com/apify/apify-mcp-server/issues) — the problem and who hits it, not the implementation.
+- **🔧 Code**: Work only on a maintainer-invited issue. An open issue is not an invitation to pick it up; unsolicited pull requests are closed.
+- **📚 Documentation**: Typos, broken links, and wrong commands go straight to a PR.
 
-For major changes, please open an issue first to discuss your proposal and ensure it aligns with the project's goals.
+Full rules, including [AI-assisted contributions](./CONTRIBUTING.md#ai-assisted-contributions): [CONTRIBUTING.md](./CONTRIBUTING.md).
 
 # 📚 Learn more