Retrieval rules
Your MCP server searches every source on every question. A retrieval rule adds the thing search cannot work out on its own: that a particular source matters for a particular kind of request, even when the request does not mention it.
Rules are optional. A server works without them.
When you need one
Search finds passages that resemble the question. That covers most cases and fails in one specific way: when the source you want shares no words with the question you asked.
Suppose you upload brand-kit.png, which describes your logo placement and
colour palette, and then ask your agent to write a customer welcome email. The
brand kit contains the words "logo", "palette" and "spacing". Your question
contains "customer", "welcome" and "email". Nothing connects them, so the brand
kit is not returned, and your agent writes an email that ignores your brand.
A rule closes that gap by telling the server what you know and it does not.
Add a rule while building a server
Each source you add in the wizard has an Add a retrieval rule link beneath it. Describe when that source matters, and the rule is created with the server.
The rule is prepared just after the server is created, so it appears in your dashboard a few moments later. Nothing is lost by the wait: your sources are still being indexed at that point, so no request can be answered yet.
Add a rule to an existing server
- Open your server in the dashboard.
- Find Retrieval rules below Sources.
- Select Add a rule.
- Describe when the source matters and how to use it.
- Choose which source the rule is about, or leave it as any source on the server.
- Select Create rule.
Write it as one or two sentences, the way you would explain it to a colleague. Name the kinds of request it applies to, and say what you want done with the source.
This is our email brand kit. When I ask for anything customer-facing —
emails, newsletters, landing page copy — use this source and follow its
logo placement and colour palette.
Read the preview
Every rule shows a What this rule does block. Read it before relying on the rule.
· Trigger on requests mentioning: email, newsletter, campaign,
customer-facing, landing page, subject line, onboarding
· Always include up to 1 passage from brand-kit.png
· Tell the agent: "Follow the logo placement and colour palette it shows."
The preview is generated from the rule as the server will apply it, not from the sentence you typed. It is how you find out that a rule means something slightly different from what you intended.
The first line matters most. It lists the words that will trigger the rule. If a kind of request you care about is missing from that list, the rule will not fire for it. Delete the rule and write a new one naming those words directly.
What a rule can do
A rule can:
- Prefer a source, so its passages rank higher for matching requests.
- Require a source, so at least one of its passages is always returned for matching requests, even when search would not have chosen it.
- Bias toward a kind of passage, using terms like
paletteorendpoint. - Pass a short instruction to your agent about how to use the source.
- Apply only to specific tools, if you say so.
What a rule cannot do
A rule cannot:
- Change what your content says.
- Make the server answer a question your sources do not cover.
- Change who can query the server, or make a private source public.
- Stop the server reporting that a result is a weak match.
The last point is deliberate. When nothing in your sources closely matches a question, the server says so, and a rule cannot turn that off. An agent that answers confidently from unrelated passages is worse than one that tells you the answer is not there, so this is not configurable.
If you write a rule that asks for any of these, the rule is refused with an explanation rather than saved in a weakened form. If only part of your sentence asked for it, the rule is created and the dashboard shows you which part was not included.
Rules are preferences, not overrides
A preferred source still has to earn its place. Ranking is scaled, not bypassed, so a rule improves the odds that the right source is used without guaranteeing that one source answers everything.
Required passages are added to the results rather than replacing them. The best-matching passage for your question still comes first.
Limits
| Limit | Value |
|---|---|
| Rules per server | 10 |
| Required passages per rule | 3 per source |
| Instruction length | 280 characters |
| Rule description length | 600 characters |
Ordering and conflicts
Rules with a higher priority are applied first where two rules disagree about the same source. Where they agree, they merge, and preferences do not stack: two rules that both prefer the same source produce one preference, not a doubled one.
Turning a rule off
Use Disable to stop applying a rule while keeping it, or the delete icon to remove it. Both take effect on the next request.
Disconnecting a source removes the rules attached to it. A rule that refers to a source you have since disconnected stops being applied and is shown in the dashboard with an explanation, so you can delete it or write a replacement.